Re: [jcl] mocks

[Torsten Curdt]

dependencies should be declared against the API and not the
implementation.

Sure ...but that API jar also includes implementations.
Can anyone explain why?

IMO the biggest mistake made with JCL was that the API

upon it is positively wrong since that will mess up dependency
management graphs.

jar is not runnable. creating a new NoOp jar and declaring a dependency

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

the api jar is now used not only as the basic JCL dependency but also
for complex classloader configurations. it's actually a special jar

this was the second fatal mistake in the development of JCL


(i've taken a look before at creating such a beast and found it
difficult.)

arranged to allow JCL to be deployed in various classloader setups. IMO what's really needed is not a NoOp jar but a jar that's runs containing definitions of the core API (Log and LogFactory) without anything else.

Yepp! ...but why is that difficult?

but that actually satisfy your downstream users?


cause problems with any application using JCL. the possible known
classloading configurations would need to be analysed carefully or the
presence of NoOp in the classloader hierarchy may well cause problems.

logging calls (if that's what your downstream customers really want).

FWIW distributing a combined library with a NoOp implementation may well IMO it would be more robust to use byte code enhancement to swallow all

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.

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?

unfortunately, as far as i can tell, a proper implementation is not
possible without breaking backwards compatibility.

thanks to hard work by simon and brian, the current JCL is known to be
much better than any before. we have a matrix of possible classloader
configurations and those which the specifications allow to be solvable
appear to work ok now.

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

i can make time for JCL but i really need some more eyes on what is a
difficult problem.

volunteers?

Be sure I'll be happy to help ...just not sure how much time I
can devote in the next few weeks.

cheers
--
Torsten

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