softwareCobbler / luceedebug

line debugger for lucee
GNU Lesser General Public License v2.1
44 stars 15 forks source link

Logging & Shaded Jar #24

Open jamiejackson opened 1 year ago

jamiejackson commented 1 year ago

While troubleshooting, I wanted some extra logging in the Agent, so I thought I'd implement a logger. I was having trouble at integration time (missing classes) and I realized that the packaging process was stripping out the logging libraries.

I didn't spend a lot of time trying to figure out the gradle tasks, but I didn't grok the packaging tasks and how the shaded vs non-shaded jar placement was intended to work. (It kinda looked like the intention was to ultimately place the shaded jar, but maybe not?)

So two questions:

softwareCobbler commented 1 year ago

Yeah a logger would be cool, probably would offer some mild perf improvements over the many System.out.println calls that are currently in there.

The shaded jar is because we add ourselves to the classpath, and probably the luceedebug.* package won't conflict with anybody, but com.google.* or whatever will. So we shade the dependencies; hence there is really only a shaded jar, no notion of a "slim build".

Ostensibly adding anything to the gradle dependencies as an implementation dependency (as in, not a compile dependency, and maybe there's other non-implementation dependency types too) should automagically get included/shaded as appropriate, and then Just Work at runtime.

Adding additional java files to any package other than coreinject shouldn't offer any friction; adding java files to coreinject will compile fine but then has a reasonable chance of running into classloader issues as it fights with OSGi at runtime. This sort of mimics Lucee's own architecture, in the difference between "loader" and "core" (hence the name coreinject).

jamiejackson commented 1 year ago

Okay, that's what I thought the intention was, based on comments. However, the symptom I had seemed to point to the logging libs being stripped out, despite having had them specified as implementation dependencies.

When I get a chance, I'm going to sanity-check that it's the shaded jar (not the slim jar) that ultimately gets placed in the build directory.