commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: [jcl] mocks
Date Mon, 12 Dec 2005 23:39:17 GMT
>> Can anyone explain why?
> history :(

Uh ...that kind of explanation ;)

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


> 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


>>> 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
> alone in your classpath and have some reasonable behaviour when you  
> call
> getLog (for example, discarding all logs) rather than exploding in  
> a fit
> of runtime exceptions.

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
> resolution would lead to assuming that Y depends on NoOpLog,  
> JCL_API and
> X. maven 2, gump and other systems use this kind of thing.


> 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
> library (using the logging) to compile time static binding. JCL 1.x  
> uses dynamic binding.
> 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.

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...



View raw message