Re: [jcl] mocks

[Torsten Curdt]

Can anyone explain why?

history :(

Uh ...that kind of explanation ;)

the jar serves two functions which should have been kept separate:

Totally!

1 to act as the API which other projects should compile against
2 as a jar which contains a subset of the implementation classes
carefully chosen to allow the classloader magic to work correctly in
certain classloader configurations

IMO these are mutually antagonistic aims

+1

IMO the biggest mistake made with JCL was that the API
jar is not runnable. creating a new NoOp jar and declaring a
dependency
upon it is positively wrong since that will mess up dependency
management graphs.

Runnable?

perhaps non-explosive or fail-safe would have been a more accurate
description of what i meant. you should be able to include the API jar

of runtime exceptions.

alone in your classpath and have some reasonable behaviour when you call getLog (for example, discarding all logs) rather than exploding in a fit

Ah! ...yes!

Messing up the dep graph? Can you elaborate
...don't get it.

X depends on JCL_API, but Y depends on NoOpLog and Y.

You mean Y depends on NoOpLog and X

transitive

X. maven 2, gump and other systems use this kind of thing.

resolution would lead to assuming that Y depends on NoOpLog, JCL_API and

Sure

not sure how
good the provides-implementation-of logic is yet...

Ah ...I see what you mean

But isn't depending on anything other than the API
jar the big flaw? In theory you should never have
that dependency and then everything should be fine.
X depends on JCL_API and Y would also depend on JCL_API.

IMHO it's much cleaner if the JCL API dependency could be used safely by

itself. in other words, if the basic API jar had some reasonable
behaviour (for example, discarding all log messages) when used alone.

I think that's the mock I have in mind.

Removing logging via bytecode modifications would be another
option ...but I am not sure how feasible it is. It's definitely
more complicated to remove than to add things at that level.

IIRC Chris Nokleberg created something that did just this

Found his blog entry ...will give that a try. That
would be awesome!

this is ceki's preferred solution.

I think agree with him here.

i prefer dynamic binding

May I ask why? ...or point to the thread in the archive.
I am sure you explained that before ;)

(run an
enhancer against the library in question which does the same job).

What do you mean by that?

sorry: should have said that i prefer byte-code enhancement of the


the idea is that you static bind a particular library to a particular
logging implementation by running an enhancer. so, if you want a
library to log to log4j, you run the log4j enhancer on the jar.

library (using the logging) to compile time static binding. JCL 1.x uses dynamic binding.

That's sound like more effort than just throwing in a certain jar.

a main advantage of static binding is that it's easy to explain and to
configure. but there are some things which compile time static binding
can't do that dynamic binding can. in particular, you can set up
configurations with jars loaded by top level classloaders and still
allow applications to have separate configurations. this seems like it
was really important back in the servlet days when one target was
commercial hosters of web applications...

you can do tricks with an enhancers that can't be done at compile time.

Hm... need to think about that

Yes, that's great ...but I still have an urge for a JCL2

so does everyone but 1.1 is a prerequisite: we need to ship something
that fixes everything that can be fixed. isolating the problematic use
cases is important since it means that we can be sure that what comes
next addresses them...

Sure!

cheers
--
Rorsten

PGP.sig
Description: This is a digitally signed message part