You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2005/12/10 22:42:42 UTC
[jcl] mocks
As some projects are not really happy with the JCL
dependency it would be nice to have a simple and
small mock jar ...just to justify the dependency.
Any objections to add this to the JCL codebase
and build system? ...or should that be hosted
somewhere else?
cheers
--
Torsten
nudge: what about the release?
RE: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-12-13 at 10:00 -0500, James Carman wrote:
> For bytecode engineering, are you suggesting that we use something like
> CGLIB at runtime or actually manipulate bytecode at compile time? I would
> definitely be against introducing CGLIB (or the like) as a runtime
> requirement. And, I really don't like having to "enhance" classes at
> compile time either. That's why I prefer Hibernate over JDO. It's a real
> pain having to add that step into my build process.
i've used JDO for the last couple of years at work which is probably why
i learned to like enhancement ;)
but i suspect that i've failed to explain myself well (no surprise
there, then ;). i think that the future is a minimal specification with
various toolkits and implementations which address various specific
problems.
dynamic manipulation might be solution for some frameworks with custom
classloaders.
enhancement could be used to address hostile classloader environments
static compile-time binding could be used when that's easiest.
JCL works ok in pure servlet environments and dynamic binding has some
advantages in those situations.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
On 13.12.2005, at 16:00, James Carman wrote:
> For bytecode engineering, are you suggesting that we use something
> like
> CGLIB at runtime
I'd -1 that one as well! ... KISS - keep it simple and stupid!
...which is not exactly what the current JCL is like and why
so many people complained in the past. It's also what should
be the focus for the next version.
cheers
--
Torsten
RE: [jcl] mocks
Posted by James Carman <ja...@carmanconsulting.com>.
For bytecode engineering, are you suggesting that we use something like
CGLIB at runtime or actually manipulate bytecode at compile time? I would
definitely be against introducing CGLIB (or the like) as a runtime
requirement. And, I really don't like having to "enhance" classes at
compile time either. That's why I prefer Hibernate over JDO. It's a real
pain having to add that step into my build process.
-----Original Message-----
From: robert burrell donkin [mailto:robertburrelldonkin@blueyonder.co.uk]
Sent: Tuesday, December 13, 2005 5:46 AM
To: Jakarta Commons Developers List
Subject: Re: [jcl] mocks
On Tue, 2005-12-13 at 00:39 +0100, Torsten Curdt wrote:
<snip>
> > not sure how
> > good the provides-implementation-of logic is yet...
>
> Ah ...I see what you mean
IMHO the future is a pure specification with a null implementation. to
enable logging you drop any compliant implementation into the
appropriate place on the classpath or use bytecode engineering to rewire
the class. the implementation could be a dynamic binder like JCL or a
static binder like SLF4J.
also, need to enable IoC so that frameworks can more easily adapt
libraries. but need to discuss this with ceki and the other folks from
logging as well as the people here...
> 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.
but because the API also serves as a special implementation which allows
clever people to do clever things (like containers and web applications
all sharing the same logging library but each can be configured as if
each is in total isolation) the API jar has a habit of blowing up with a
load of runtime exception when used by those who are not experts in Java
2 web application classloading or when placed J2EE containers with
broken classloadering strategies.
AIUI this was an intentional part of the original design (for various
reasons to do with specification compliance and security wories). 1.1
takes a softer, more pragmatic approach.
> > 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.
IMO that's not really a mock: since the vast majority of people will
never want or need to look at logs for well tested deep libraries, it's
actually probably the best default implementation. that's why i've
favour the term 'null API'.
> >> 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!
it's pretty easy to use byte code engineering to directly rewire JCL
calls to call instead the favoured log system. this is a performant
solution.
> >>> 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.
throwing in jars sounds very easy until you start thinking about the use
cases that (mostly used to) break JCL. there are a lot of nasty
classloaders out there in the wild. many of these will cause
difficulties for static binding too.
> > 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
for example: you want to use library X which uses JCL in a J2EE
application. you want the application to be portable across containers
and the core distribution reusable for web and ejb. your application
uses Log4J (say). the J2EE classloader specification is broken and every
container has it's own system. it is not uncommon for JCL to be found in
container or even system classloaders. this is a very hostile
environment whether you're using static compilation or dynamic binding.
if you enhance library X so that ever call made to JCL instead results
in a direct call to Log4J not only do you have better performance but
also you don't need to worry about J2EE classloading.
but it's not really a case of having to choose.
static compilation time binding has advantages for stand alone
applications. dynamic binding works well for servlets. byte-code
enhancement is good for J2EE. that's why i think a specification and
multiple implementations is the complete solution.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-12-13 at 00:39 +0100, Torsten Curdt wrote:
<snip>
> > not sure how
> > good the provides-implementation-of logic is yet...
>
> Ah ...I see what you mean
IMHO the future is a pure specification with a null implementation. to
enable logging you drop any compliant implementation into the
appropriate place on the classpath or use bytecode engineering to rewire
the class. the implementation could be a dynamic binder like JCL or a
static binder like SLF4J.
also, need to enable IoC so that frameworks can more easily adapt
libraries. but need to discuss this with ceki and the other folks from
logging as well as the people here...
> 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.
but because the API also serves as a special implementation which allows
clever people to do clever things (like containers and web applications
all sharing the same logging library but each can be configured as if
each is in total isolation) the API jar has a habit of blowing up with a
load of runtime exception when used by those who are not experts in Java
2 web application classloading or when placed J2EE containers with
broken classloadering strategies.
AIUI this was an intentional part of the original design (for various
reasons to do with specification compliance and security wories). 1.1
takes a softer, more pragmatic approach.
> > 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.
IMO that's not really a mock: since the vast majority of people will
never want or need to look at logs for well tested deep libraries, it's
actually probably the best default implementation. that's why i've
favour the term 'null API'.
> >> 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!
it's pretty easy to use byte code engineering to directly rewire JCL
calls to call instead the favoured log system. this is a performant
solution.
> >>> 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.
throwing in jars sounds very easy until you start thinking about the use
cases that (mostly used to) break JCL. there are a lot of nasty
classloaders out there in the wild. many of these will cause
difficulties for static binding too.
> > 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
for example: you want to use library X which uses JCL in a J2EE
application. you want the application to be portable across containers
and the core distribution reusable for web and ejb. your application
uses Log4J (say). the J2EE classloader specification is broken and every
container has it's own system. it is not uncommon for JCL to be found in
container or even system classloaders. this is a very hostile
environment whether you're using static compilation or dynamic binding.
if you enhance library X so that ever call made to JCL instead results
in a direct call to Log4J not only do you have better performance but
also you don't need to worry about J2EE classloading.
but it's not really a case of having to choose.
static compilation time binding has advantages for stand alone
applications. dynamic binding works well for servlets. byte-code
enhancement is good for J2EE. that's why i think a specification and
multiple implementations is the complete solution.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
>> 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
> 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.
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
> 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...
Sure!
cheers
--
Rorsten
Re: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 21:48 +0100, Torsten Curdt wrote:
> > dependencies should be declared against the API and not the
> > implementation.
>
> Sure ...but that API jar also includes implementations.
> Can anyone explain why?
history :(
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.
> Messing up the dep graph? Can you elaborate
> ...don't get it.
X depends on JCL_API, but Y depends on NoOpLog and Y. 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...
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.
then both X and Y could safely depend on the API jar.
> > 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
> > arranged to allow JCL to be deployed in various classloader setups.
> > IMO
> > this was the second fatal mistake in the development of JCL
> >
> > 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.
> > (i've taken a look before at creating such a beast and found it
> > difficult.)
>
> Yepp! ...but why is that difficult?
the tricks used to satisfy the java 2 and servlet specifications gave
rise to some nasty runtime couplings.
JCL used to assume that (unless the user specified an alternative
implementation) if LogFactoryImpl cannot be loaded then an exception
must be thrown since something was seriously wrong. i think that there's
a chance that this is no longer with case with the latest code but i'd
need to sit down and analysis the code...
the risk must also be considered of the API jar being loaded by a high
level container classloader and preventing the careful classloader
tricks working correctly.
> > but that actually satisfy your downstream users?
> >
> > FWIW distributing a combined library with a NoOp implementation may
> > well
> > 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.
> > IMO it would be more robust to use byte code enhancement to swallow
> > all
> > logging calls (if that's what your downstream customers really want).
>
> 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
> > 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.
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.
but different approaches to binding could be (in some ways) complementary.
> > 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
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...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
> 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
> 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? 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
> arranged to allow JCL to be deployed in various classloader setups.
> IMO
> this was the second fatal mistake in the development of JCL
>
> 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.
> (i've taken a look before at creating such a beast and found it
> difficult.)
Yepp! ...but why is that difficult?
> but that actually satisfy your downstream users?
>
> FWIW distributing a combined library with a NoOp implementation may
> well
> 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.
> IMO it would be more robust to use byte code enhancement to swallow
> all
> logging calls (if that's what your downstream customers really want).
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
Re: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 07:53 +0100, Torsten Curdt wrote:
> >> Basically all it holds is the Log interface and
> >> the LogFactory providing an Log implementation
> >> that is doing nothing.
> >
> > The existing jar already provides NoOpLog.jar. Providing a
> > commons-logging.properties file, or setting the appropriate system
> > property, ensures that no-op logging is used (the default is SimpleLog
> > that just writes to stdout).
>
> What "NoOpLog.jar"? I know there is a NoOpLog implementation
> but that's not the point. Some people just don't want the
> dependency.
dependencies should be declared against the API and not the
implementation. 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.
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
arranged to allow JCL to be deployed in various classloader setups. IMO
this was the second fatal mistake in the development of JCL.
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.
(i've taken a look before at creating such a beast and found it
difficult.)
but that actually satisfy your downstream users?
FWIW distributing a combined library with a NoOp implementation may well
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.
IMO it would be more robust to use byte code enhancement to swallow all
logging calls (if that's what your downstream customers really want).
> And they also don't want to care about a property
> file. Instead of everyone providing this mini-jar it would be
> nice to have it with JCL IMO.
>
> Even better I like the idea of having a static selection of the
> underlying log system. So having several jars
>
> commons-logging-[version]-log4j.jar
> commons-logging-[version]-noop.jar
> ...
>
> would be a good alternative. Like that.
this is ceki's preferred solution. i prefer dynamic binding (run an
enhancer against the library in question which does the same job).
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.
this does not address the fundamental problems but i think these are
better understood now:
1 the J2EE classloader specification is broken, very broken. for
political reasons, it's not going to be fixed anytime soon. JCL was
coded in the servlet era by folks who are acknowledged experts in the
servlet and java 2 specifications. JCL would have worked fine if
everyone followed the Java 2 and servlet classloading specifications.
unfortunately, since the J2EE specification is broken, JCL cannot work
correctly. this cannot be fixed until the specification and every
container is fixed. static binding (whether done with different jars or
using byte code enhancement) does not have this limitation.
2 the very popularity of JCL is a major problem. with knowledge and
correct configuration, the latest JCL will fail to work in a vanishingly
small number of real life situations. unfortunately, very few users have
the knowledge of classloaders required to fix broken configurations and
the popularity of JCL means that the jar has a habit of findings it's
way into very difficult classloaders (for example, system classloaders).
these are very hostile environments. this problem will not be fixed by a
movement to static binding.
3 IMHO the basic usage pattern for JCL suggested in the early days is
problematic.
private static Log log = LogFactory.getLog()
is very widely used and suitable for applications but is difficult for
bricks:
3a static utilities should not require logging
3b object libraries should allow themselves to be adapted to the logging
system of their host and therefore the log instance should be an
instance variable (not a class variable). this poses a difficulty:
logging is usually seen as a framework issue and possibly not exposed as
part of the public API. Joerg and Jörg have a solution in mind for this
but it's on hold until the 1.1 release is cut.
BTW i've been having problems with my ISP all week but hopefully i'm
back online now.
i can make time for JCL but i really need some more eyes on what is a
difficult problem.
volunteers?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
>> Basically all it holds is the Log interface and
>> the LogFactory providing an Log implementation
>> that is doing nothing.
>
> The existing jar already provides NoOpLog.jar. Providing a
> commons-logging.properties file, or setting the appropriate system
> property, ensures that no-op logging is used (the default is SimpleLog
> that just writes to stdout).
What "NoOpLog.jar"? I know there is a NoOpLog implementation
but that's not the point. Some people just don't want the
dependency. And they also don't want to care about a property
file. Instead of everyone providing this mini-jar it would be
nice to have it with JCL IMO.
Even better I like the idea of having a static selection of the
underlying log system. So having several jars
commons-logging-[version]-log4j.jar
commons-logging-[version]-noop.jar
...
would be a good alternative. Like that.
cheers
--
Torsten
Re: [jcl] mocks
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-12-11 at 03:19 +0100, Torsten Curdt wrote:
> On 11.12.2005, at 03:14, Simon Kitching wrote:
>
> > On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt wrote:
> >> As some projects are not really happy with the JCL
> >> dependency it would be nice to have a simple and
> >> small mock jar ...just to justify the dependency.
> >>
> >> Any objections to add this to the JCL codebase
> >> and build system? ...or should that be hosted
> >> somewhere else?
> >
> > What exactly do you mean by "mock jar", and how does this "justify the
> > dependency"?
>
> Basically all it holds is the Log interface and
> the LogFactory providing an Log implementation
> that is doing nothing.
The existing jar already provides NoOpLog.jar. Providing a
commons-logging.properties file, or setting the appropriate system
property, ensures that no-op logging is used (the default is SimpleLog
that just writes to stdout).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
On 11.12.2005, at 03:14, Simon Kitching wrote:
> On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt wrote:
>> As some projects are not really happy with the JCL
>> dependency it would be nice to have a simple and
>> small mock jar ...just to justify the dependency.
>>
>> Any objections to add this to the JCL codebase
>> and build system? ...or should that be hosted
>> somewhere else?
>
> What exactly do you mean by "mock jar", and how does this "justify the
> dependency"?
Basically all it holds is the Log interface and
the LogFactory providing an Log implementation
that is doing nothing.
cheers
--
Torsten
RE: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 19:30 +1300, Simon Kitching wrote:
<snip>
> There are still quite a few issues to be thought through for this,
> though. It seemed easier to fix the most prominent issues with the
> existing JCL design and release that before looking at more serious
> rework. Unfortunately all the people working on JCL seem to have run out
> of time simultaneously for various reasons. I'm expecting to have some
> spare time in January, though, and would love to get a release out
> during that month.
i gone quiet on the pending JCL release for a couple of reasons:
1 my ISP stopped delivering any mail for the last week :-/
2 there's a general crisis of confidence ATM about commons releases
IMHO it would be better use of your time to be able to push forward a
JCL2 effort. i'll try to get up to speed on the changes being made to
the commons release practises...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Torsten Curdt <tc...@apache.org>.
<snip type="all cool"/>
> I'm expecting to have some
> spare time in January, though, and would love to get a release out
> during that month.
awesome :)
cheers
--
Torsten
RE: [jcl] mocks
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-12-10 at 21:32 -0500, James Carman wrote:
> I don't know if this has ever been discussed or not, but could we not split
> JCL up into a bunch of different jars containing the different
> implementations? Each implementation jar (one for Log4J, Avalon, JDK14,
> etc.) would contain a file called something like "/META-INF/jcl-module.xml"
> or whatever. It could actually just be a properties file, I would imagine.
> Anyway, then that file is looked up at runtime to determine the
> implementation the user wishes to use. If they want to use log4j, they
> would include the commons-logging-log4j.jar file on the classpath. If they
> want to use the "no-op" implementation, they'd include the
> commons-logging-noop.jar file on the classpath. This is similar to what we
> do in HiveMind. It might work here. I don't know. Just a thought. There
> would be an issue if the user included two different implementations on the
> classpath. I guess the one that shows up first on the classpath would get
> loaded.
Something on these lines is likely to be seriously considered for the
release-after-next.
There have been a number of experiments along this line, though the
focus has been on using build-time stuff to generate classes with the
same classname (LogFactory) which are statically bound to the desired
library. This avoids configuration file issues.
There are still quite a few issues to be thought through for this,
though. It seemed easier to fix the most prominent issues with the
existing JCL design and release that before looking at more serious
rework. Unfortunately all the people working on JCL seem to have run out
of time simultaneously for various reasons. I'm expecting to have some
spare time in January, though, and would love to get a release out
during that month.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 09:56 -0800, Wade Chandler wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
> > if you want to understand why people complain, stick
> > around and help us
> > with the development ;)
> >
> > it's a small library but a difficult subject. we
> > need more eyes and more
> > hands with energy for the problem...
> >
> > - robert
> >
> >
> >
> So what are the biggest complaints? Is there a list
> of the most complained about issues some where? Is
> the only complaint that someone needs to configure a
> propeties file, or is it that they have to add a few
> more kilobytes to their application? I would be glad
> to help where I can. Is there a page on the dev site
> about current issues or the complaints?
there is really but one issue: automagic configuration in complex
classloaders has a tendency to throw exceptions. throwing runtime
exceptions is sort-of-theoretically-the-right-thing-to-do (from a
security perspective) but is also very bad thing for any deep library to
do. the consensus now (however) is that the practical security gains are
negligible.
1.1 is better than previous versions but there are number of
configurations which the various specifications ensure that JCL cannot
function. for the vast majority of these there are slight changes that
can be made to the configuration which will allow JCL to run fine.
what's really needed is a troubleshooting guide which tells people who
get into difficulties how they can fix stuff.
since there are very few even half-decent introductions to practical
classloading, we added one here:
http://jakarta.apache.org/commons/logging/tech.html. we also spent quite
a lot of time working on a systematic approach (with code) to the
various permutations possible with standard classloader configurations.
a reasonable troubleshooting guide could be based on that. help with
that guide would be very useful.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by Wade Chandler <hw...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> On Sun, 2005-12-11 at 00:17 -0800, Wade Chandler
> wrote:
> > --- Simon Kitching <sk...@apache.org> wrote:
>
> <snip>
>
> > > I think you've described exactly what
> > > commons-logging currently does.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> >
> > Yep...someone noticed. I don't see why people
> > complain over it...yet that is... considering the
> jar
> > sizes. Technically once a setup/configuration is
> > setup it's finished. Which the end result is it
> takes
> > up just as much time to set a property as it does
> to
> > write a line of code.
>
> if you want to understand why people complain, stick
> around and help us
> with the development ;)
>
> it's a small library but a difficult subject. we
> need more eyes and more
> hands with energy for the problem...
>
> - robert
>
>
>
So what are the biggest complaints? Is there a list
of the most complained about issues some where? Is
the only complaint that someone needs to configure a
propeties file, or is it that they have to add a few
more kilobytes to their application? I would be glad
to help where I can. Is there a page on the dev site
about current issues or the complaints?
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2005-12-11 at 00:17 -0800, Wade Chandler wrote:
> --- Simon Kitching <sk...@apache.org> wrote:
<snip>
> > I think you've described exactly what
> > commons-logging currently does.
> >
> > Regards,
> >
> > Simon
> >
>
> Yep...someone noticed. I don't see why people
> complain over it...yet that is... considering the jar
> sizes. Technically once a setup/configuration is
> setup it's finished. Which the end result is it takes
> up just as much time to set a property as it does to
> write a line of code.
if you want to understand why people complain, stick around and help us
with the development ;)
it's a small library but a difficult subject. we need more eyes and more
hands with energy for the problem...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by Wade Chandler <hw...@yahoo.com>.
--- Simon Kitching <sk...@apache.org> wrote:
> On Sat, 2005-12-10 at 18:54 -0800, Wade Chandler
> wrote:
>
> > You could always have a wrapper which defaults to
> JCL.
> > Then use a static property system and
> > System.setProperty (for simplicity sake). Need
> both
> > for web-apps sake because it's not good to use
> > System.setProperty in a web-app considering
> multiple
> > web-apps 1 VM and System class, and tell the user
> they
> > can set this value to work around the issue if
> they
> > don't like the default. Define the LoggingFactory
> in
> > an interface, provide wrapper implemenations for
> the
> > common/best known logging packages, and the
> "no-op"
> > version, and for the others they can implement in
> > interface extensions if they are not happy. Then
> have
> > a LogFactoryFactory class which creates the
> LogFactory
> > for the logging based on the simple
> implementation.
> > This might even be a good solution for a broken
> out
> > separate Apache API to allow all the Apache
> products
> > to be that flexible. Then you don't have to worry
> > about the user not being able to use their own
> > implementations of logging. Even the idea of a
> > commons simple static property system could become
> > it's own Apache API to allow all Apache products
> to
> > make themselves configurable in this way. It also
> > allows a defined documented cross properties API
> to be
> > created and used among the different projects.
> Being
> > defined, documented, and commonly used being the
> best
> > factors I think. The recommended use would be to
> not
> > install as a JVM extension. :-D
>
> I think you've described exactly what
> commons-logging currently does.
>
> Regards,
>
> Simon
>
Yep...someone noticed. I don't see why people
complain over it...yet that is... considering the jar
sizes. Technically once a setup/configuration is
setup it's finished. Which the end result is it takes
up just as much time to set a property as it does to
write a line of code.
Anyways....
1) The ant targets should be pretty easy to write to
strip out the different packages and make the
independent jars.
2) All you really have to change then:if some property
file exists on the class path open it up, read it, and
load that class. Else do what you currently do. I
wouldn't even worry about multiple copies. I would
just use LogFactory.class.getResource("/..."); like it
currently does and call it a day on that one...I
wouldn't even change the search..just include the
properties file.
So you're really only looking at a few lines of code,
and some ANT or Maven script changes. To do what has
been proposed. You'll spend most of the time in the
build scripts considering there really isn't much need
as far as configuration goes for JCL itself. I would
just use a simple properties file like it currently
uses. I would simply pre-include it in the jar file
and leave it at that..modifying the build scripts of
course. I mean, if the users don't want the
dependency then they won't have the System property,
services, or commons-logging.properties file setup
anyways.
That's my 2 pints,
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-12-10 at 18:54 -0800, Wade Chandler wrote:
> You could always have a wrapper which defaults to JCL.
> Then use a static property system and
> System.setProperty (for simplicity sake). Need both
> for web-apps sake because it's not good to use
> System.setProperty in a web-app considering multiple
> web-apps 1 VM and System class, and tell the user they
> can set this value to work around the issue if they
> don't like the default. Define the LoggingFactory in
> an interface, provide wrapper implemenations for the
> common/best known logging packages, and the "no-op"
> version, and for the others they can implement in
> interface extensions if they are not happy. Then have
> a LogFactoryFactory class which creates the LogFactory
> for the logging based on the simple implementation.
> This might even be a good solution for a broken out
> separate Apache API to allow all the Apache products
> to be that flexible. Then you don't have to worry
> about the user not being able to use their own
> implementations of logging. Even the idea of a
> commons simple static property system could become
> it's own Apache API to allow all Apache products to
> make themselves configurable in this way. It also
> allows a defined documented cross properties API to be
> created and used among the different projects. Being
> defined, documented, and commonly used being the best
> factors I think. The recommended use would be to not
> install as a JVM extension. :-D
I think you've described exactly what commons-logging currently does.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by Wade Chandler <hw...@yahoo.com>.
--- James Carman <ja...@carmanconsulting.com> wrote:
> I think he meant that there would be a "mock" or
> "no-op" implementation
> inside the jar. So, you could download this minimal
> jar file and include
> that on the classpath. No logging would actually
> occur, but it would
> satisfy the dependencies. I would imagine that some
> of the "core" classes
> would have to be included also.
>
> I don't know if this has ever been discussed or not,
> but could we not split
> JCL up into a bunch of different jars containing the
> different
> implementations? Each implementation jar (one for
> Log4J, Avalon, JDK14,
> etc.) would contain a file called something like
> "/META-INF/jcl-module.xml"
> or whatever. It could actually just be a properties
> file, I would imagine.
> Anyway, then that file is looked up at runtime to
> determine the
> implementation the user wishes to use. If they want
> to use log4j, they
> would include the commons-logging-log4j.jar file on
> the classpath. If they
> want to use the "no-op" implementation, they'd
> include the
> commons-logging-noop.jar file on the classpath.
> This is similar to what we
> do in HiveMind. It might work here. I don't know.
> Just a thought. There
> would be an issue if the user included two different
> implementations on the
> classpath. I guess the one that shows up first on
> the classpath would get
> loaded.
>
> James
>
> -----Original Message-----
> From: Simon Kitching [mailto:skitching@apache.org]
> Sent: Saturday, December 10, 2005 9:14 PM
> To: Jakarta Commons Developers List
> Subject: Re: [jcl] mocks
>
> On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt
> wrote:
> > As some projects are not really happy with the JCL
> > dependency it would be nice to have a simple and
> > small mock jar ...just to justify the dependency.
> >
> > Any objections to add this to the JCL codebase
> > and build system? ...or should that be hosted
> > somewhere else?
>
> What exactly do you mean by "mock jar", and how does
> this "justify the
> dependency"?
>
> Cheers,
>
> Simon
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
You could always have a wrapper which defaults to JCL.
Then use a static property system and
System.setProperty (for simplicity sake). Need both
for web-apps sake because it's not good to use
System.setProperty in a web-app considering multiple
web-apps 1 VM and System class, and tell the user they
can set this value to work around the issue if they
don't like the default. Define the LoggingFactory in
an interface, provide wrapper implemenations for the
common/best known logging packages, and the "no-op"
version, and for the others they can implement in
interface extensions if they are not happy. Then have
a LogFactoryFactory class which creates the LogFactory
for the logging based on the simple implementation.
This might even be a good solution for a broken out
separate Apache API to allow all the Apache products
to be that flexible. Then you don't have to worry
about the user not being able to use their own
implementations of logging. Even the idea of a
commons simple static property system could become
it's own Apache API to allow all Apache products to
make themselves configurable in this way. It also
allows a defined documented cross properties API to be
created and used among the different projects. Being
defined, documented, and commonly used being the best
factors I think. The recommended use would be to not
install as a JVM extension. :-D
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [jcl] mocks
Posted by James Carman <ja...@carmanconsulting.com>.
I think he meant that there would be a "mock" or "no-op" implementation
inside the jar. So, you could download this minimal jar file and include
that on the classpath. No logging would actually occur, but it would
satisfy the dependencies. I would imagine that some of the "core" classes
would have to be included also.
I don't know if this has ever been discussed or not, but could we not split
JCL up into a bunch of different jars containing the different
implementations? Each implementation jar (one for Log4J, Avalon, JDK14,
etc.) would contain a file called something like "/META-INF/jcl-module.xml"
or whatever. It could actually just be a properties file, I would imagine.
Anyway, then that file is looked up at runtime to determine the
implementation the user wishes to use. If they want to use log4j, they
would include the commons-logging-log4j.jar file on the classpath. If they
want to use the "no-op" implementation, they'd include the
commons-logging-noop.jar file on the classpath. This is similar to what we
do in HiveMind. It might work here. I don't know. Just a thought. There
would be an issue if the user included two different implementations on the
classpath. I guess the one that shows up first on the classpath would get
loaded.
James
-----Original Message-----
From: Simon Kitching [mailto:skitching@apache.org]
Sent: Saturday, December 10, 2005 9:14 PM
To: Jakarta Commons Developers List
Subject: Re: [jcl] mocks
On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt wrote:
> As some projects are not really happy with the JCL
> dependency it would be nice to have a simple and
> small mock jar ...just to justify the dependency.
>
> Any objections to add this to the JCL codebase
> and build system? ...or should that be hosted
> somewhere else?
What exactly do you mean by "mock jar", and how does this "justify the
dependency"?
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [jcl] mocks
Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2005-12-10 at 22:42 +0100, Torsten Curdt wrote:
> As some projects are not really happy with the JCL
> dependency it would be nice to have a simple and
> small mock jar ...just to justify the dependency.
>
> Any objections to add this to the JCL codebase
> and build system? ...or should that be hosted
> somewhere else?
What exactly do you mean by "mock jar", and how does this "justify the
dependency"?
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org