You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2005/04/29 14:35:06 UTC
[logging] requirements and static binding
Hi,
Below is a simple list of the *requirements* for a logging wrapper with
respect to classloading.
As far as I can see, Ceki's static-binding approach (UGLI/SLF4J)
satisfies all of these requirements while being vastly simpler than the
current JCL approach - even without the more complex modifications
currently being proposed.
NB: UGLI has been renamed SLF4J, and moved to SLF4J.org. The code hosted
there is really only 4 core classes + a pair of classes per supported
logging library.
The static approach is exceedingly simple. Yes, it's also fairly
inflexible. But if it meets all the requirements, so what? The thought
of relying upon the classloader as the only mechanism to decide which
logging library gets used has always made me feel uncomfortable - but
having had a think about it, I can't see where it fails to meet the
requirements.
Richard, you mentioned in an email earlier that you thought there were
some situations where static binding didn't fare so well. Can you list
them for me?
==============
0. Code compiled against the logging wrapper should run without
recompilation against any supported concrete logging library
1. for normal apps, ie where
context-classloader = system-classloader
and all app classes are loaded via the system-classloader
* The logging library should initialise itself once
* The logging implementation should auto-detect which logging
library is present in the classpath and use it.
2. for webapps with child-first classloading
* need the ability for the logging library to be present in
WEB-INF/lib
* need the ability for the logging config to be present in
WEB-INF/lib
* need the ability for *a webapp-aware* logging library to
correctly work when deployed in a shared classloader, ie
still correctly pick up logging config from WEB-INF/lib.
3. for webapps with parent-first classloading
* need the ability for the logging library to be present in
WEB-INF/lib when none is present in the shared classloader.
* need the ability for the logging config to be present in
WEB-INF/lib when none is present in the shared classloader.
* NO need for the webapp to be able to select a local logging
library or config file when one is present in the parent -
if someone needs that, they should select child-first
classloading.
==============
Analysis of the effectiveness of static in the demonstration scenarios:
1-4: static fails, but that's expected. When using the static approach,
you simply must deploy the static adaptor and the target library
via the same classloader. I don't see that this causes any
conflict with the requirements listed above.
5-8: static works
9-12: as per 1-4
13-16: static works
17,19: as per 1-4
18,20: static works
21-24: static works
25,27: as per 1-4
26,28: static works
29-32: static works
notes:
* there are no scenarios defined for parent-first where static is
deployed via child (ie parent doesn't define it)
* there are no scenarios defined for child-first where static is
deployed via parent (ie child doesn't define it).
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-05-05 at 23:12 +1200, Simon Kitching wrote:
> On Wed, 2005-05-04 at 23:37 -0700, Brian Stansberry wrote:
<snip>
> > 2) When checking into the above, I discovered that in
> > the latest JBoss, their webapp classloader won't load
> > commons-logging.jar from WEB-INF/lib even if
> > parent-last loading is in effect. It's specifically
> > disabled. Seems there were type conflicts with JCL
> > classes loaded by the integrated Tomcat container.
> > Not sure yet what this is all about, but in any case
> > the net effect is that as far as JCL is concerned, a
> > webapp on JBoss behaves as if parent-first loading
> > were in effect.
>
> Interesting....I wonder if they posted any questions to the JCL
> development list before adopting this (apparently fairly radical)
> solution. I'll go have a look.
seems like an odd solution. any more information on this?
> >
> > 3) Thinking again of the DefaultServlet and JSPServlet
> > in Tomcat. These classes are loaded by a container
> > classloader, but the logging of a specific instance of
> > the classes should be governed by the configuration of
> > the webapp. AFAICT, this will require dynamic
> > discovery based on the TCCL.
>
> I'm not sure that logging from such classes *should* use the logging
> configuration of the webapp. I discussed this in my earlier email:
> <simon>
> > What about when a webapp calls a method on an object passed to it by the
> > container, and that method logs stuff? Well, in that case there's no
> > guarantee that the called object uses JCL anyway, so catching logging
> > from such objects really relies upon the container providing
> > container-specific hooks to redirect logging. And in that case logging
> > calls will end up in webapp-specific code that will statically bind via
> > the webapp classloader. So no problem.
> </simon>
> > I too prefer the simplicity (and lack of memory leaks)
> > of static binding, but given the above and the recent
> > discussion continue to see a long life for dynamic
> > discovery as well. This gets me thinking of how
> > carefully we're going to have to document things when
> > we provide both static and dynamic discovery. For
> > example, if we provide a commons-logging-jdk14.jar,
> > we'll have to make clear that deploying it with your
> > EJBs won't work if the container has
> > commons-logging.log4j.jar on the classpath, that it
> > won't work in a webapp on JBoss, etc.
>
> Ecch....
>
>
> This is great info, Brian. I'll need to mull it over a bit more.
good work brian
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] J2EE Spec and classloader order (WAS: requirements and static binding)
Posted by Boris Unckel <bo...@gmx.net>.
> Branching this discussion off, as I realize my
> previous post forked a thread.
> Could be (although my gut instinct says otherwise).
> Any BEA/Websphere/Geronimo/YourFavoriteAppServer
> experts out there know of support for child-first
> loading for EJBs?
WebSphere 5 has Option to
*Application classloader policy (Specifies whether there is a single
classloader for all applications ("Single") or a classloader per application
("Multiple")):
- Single
- Multiple
*Application class loading mode( Specifies the class loading mode when the
application classloader policy is "Single"!):
- ParentFirst
- ParentLast
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] J2EE Spec and classloader order (WAS: requirements
and static binding)
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thu, 2005-05-05 at 11:36 -0700, Brian Stansberry wrote:
> Branching this discussion off, as I realize my
> previous post forked a thread.
>
> --- Simon Kitching <sk...@apache.org> wrote:
>
> > On Wed, 2005-05-04 at 23:37 -0700, Brian Stansberry
> > wrote:
> > > A few semi-random points on parent-first vs.
> > > parent-last classloading:
> > >
> > > 1) EJBs, EARs and other non-webapp J2EE
> > deployments
> > > typically use parent-first loading. I'd thought
> > JBoss
> > > offered a deployment descriptor option that
> > allowed
> > > the deployer to choose parent-last, but I was
> > > mistaken. Too bad; I was hoping the scope of the
> > "if
> > > you want control, use parent-last classloading"
> > > approach would apply.
> >
> > Well, if the EJB spec is designed to prevent EJBs
> > from overriding jars
> > present in the parent classloader, who are we to
> > argue?
> >
>
> Sorry, didn't "cross-pollinate" between a discussion I
> was having on the JBoss forum and here. I briefly
> looked at the J2EE and EJB specs and didn't see
> anything that *required* parent-first. It really
> doesn't say anything about it at all. A comment by
> Scott Stark at JBoss implies the same.
>
> For the JBoss forum discussion, please see:
>
> http://www.jboss.org/index.html?module=bb&op=viewtopic&t=63520
i'd be interested to find out how the type conflict arises
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] J2EE Spec and classloader order (WAS: requirements and static binding)
Posted by Brian Stansberry <be...@yahoo.com>.
Branching this discussion off, as I realize my
previous post forked a thread.
--- Simon Kitching <sk...@apache.org> wrote:
> On Wed, 2005-05-04 at 23:37 -0700, Brian Stansberry
> wrote:
> > A few semi-random points on parent-first vs.
> > parent-last classloading:
> >
> > 1) EJBs, EARs and other non-webapp J2EE
> deployments
> > typically use parent-first loading. I'd thought
> JBoss
> > offered a deployment descriptor option that
> allowed
> > the deployer to choose parent-last, but I was
> > mistaken. Too bad; I was hoping the scope of the
> "if
> > you want control, use parent-last classloading"
> > approach would apply.
>
> Well, if the EJB spec is designed to prevent EJBs
> from overriding jars
> present in the parent classloader, who are we to
> argue?
>
Sorry, didn't "cross-pollinate" between a discussion I
was having on the JBoss forum and here. I briefly
looked at the J2EE and EJB specs and didn't see
anything that *required* parent-first. It really
doesn't say anything about it at all. A comment by
Scott Stark at JBoss implies the same.
For the JBoss forum discussion, please see:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=63520
> In other words, if a JCL logging implementation is
> in the parent
> classloader, then why not just bind to it?
>
> This doesn't give the EJB developer any control over
> what logging lib is
> used (though they don't typically need such
> control).
>
> More controversially, it doesn't give any control to
> the "application
> assembler", as any jar they bundle will be ignored
> if the container
> provides an implementation. But that's the way the
> J2EE spec wants
> things to work it appears.
>
> And potentially even more controversially, it
> doesn't give any control
> to the "application deployer" unless they are also a
> system
> administrator for the container (and are willing to
> change the logging
> lib globally). But again, if the J2EE spec authors
> chose "parent first"
> as the only option, then that must be what they
> wanted to happen.
>
> Or is it just JBoss that has adopted this position
> for EJB deployment I
> wonder?
Could be (although my gut instinct says otherwise).
Any BEA/Websphere/Geronimo/YourFavoriteAppServer
experts out there know of support for child-first
loading for EJBs?
Brian
__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-05-04 at 23:37 -0700, Brian Stansberry wrote:
> A few semi-random points on parent-first vs.
> parent-last classloading:
>
> 1) EJBs, EARs and other non-webapp J2EE deployments
> typically use parent-first loading. I'd thought JBoss
> offered a deployment descriptor option that allowed
> the deployer to choose parent-last, but I was
> mistaken. Too bad; I was hoping the scope of the "if
> you want control, use parent-last classloading"
> approach would apply.
Well, if the EJB spec is designed to prevent EJBs from overriding jars
present in the parent classloader, who are we to argue?
In other words, if a JCL logging implementation is in the parent
classloader, then why not just bind to it?
This doesn't give the EJB developer any control over what logging lib is
used (though they don't typically need such control).
More controversially, it doesn't give any control to the "application
assembler", as any jar they bundle will be ignored if the container
provides an implementation. But that's the way the J2EE spec wants
things to work it appears.
And potentially even more controversially, it doesn't give any control
to the "application deployer" unless they are also a system
administrator for the container (and are willing to change the logging
lib globally). But again, if the J2EE spec authors chose "parent first"
as the only option, then that must be what they wanted to happen.
Or is it just JBoss that has adopted this position for EJB deployment I
wonder?
>
> 2) When checking into the above, I discovered that in
> the latest JBoss, their webapp classloader won't load
> commons-logging.jar from WEB-INF/lib even if
> parent-last loading is in effect. It's specifically
> disabled. Seems there were type conflicts with JCL
> classes loaded by the integrated Tomcat container.
> Not sure yet what this is all about, but in any case
> the net effect is that as far as JCL is concerned, a
> webapp on JBoss behaves as if parent-first loading
> were in effect.
Interesting....I wonder if they posted any questions to the JCL
development list before adopting this (apparently fairly radical)
solution. I'll go have a look.
>
> 3) Thinking again of the DefaultServlet and JSPServlet
> in Tomcat. These classes are loaded by a container
> classloader, but the logging of a specific instance of
> the classes should be governed by the configuration of
> the webapp. AFAICT, this will require dynamic
> discovery based on the TCCL.
I'm not sure that logging from such classes *should* use the logging
configuration of the webapp. I discussed this in my earlier email:
<simon>
> What about when a webapp calls a method on an object passed to it by the
> container, and that method logs stuff? Well, in that case there's no
> guarantee that the called object uses JCL anyway, so catching logging
> from such objects really relies upon the container providing
> container-specific hooks to redirect logging. And in that case logging
> calls will end up in webapp-specific code that will statically bind via
> the webapp classloader. So no problem.
</simon>
>
>
> I too prefer the simplicity (and lack of memory leaks)
> of static binding, but given the above and the recent
> discussion continue to see a long life for dynamic
> discovery as well. This gets me thinking of how
> carefully we're going to have to document things when
> we provide both static and dynamic discovery. For
> example, if we provide a commons-logging-jdk14.jar,
> we'll have to make clear that deploying it with your
> EJBs won't work if the container has
> commons-logging.log4j.jar on the classpath, that it
> won't work in a webapp on JBoss, etc.
Ecch....
This is great info, Brian. I'll need to mull it over a bit more. I admin
I've been playing "devil's advocate" a bit above; may need to reconsider
in the face of reality :-)
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by Brian Stansberry <be...@yahoo.com>.
A few semi-random points on parent-first vs.
parent-last classloading:
1) EJBs, EARs and other non-webapp J2EE deployments
typically use parent-first loading. I'd thought JBoss
offered a deployment descriptor option that allowed
the deployer to choose parent-last, but I was
mistaken. Too bad; I was hoping the scope of the "if
you want control, use parent-last classloading"
approach would apply.
2) When checking into the above, I discovered that in
the latest JBoss, their webapp classloader won't load
commons-logging.jar from WEB-INF/lib even if
parent-last loading is in effect. It's specifically
disabled. Seems there were type conflicts with JCL
classes loaded by the integrated Tomcat container.
Not sure yet what this is all about, but in any case
the net effect is that as far as JCL is concerned, a
webapp on JBoss behaves as if parent-first loading
were in effect.
3) Thinking again of the DefaultServlet and JSPServlet
in Tomcat. These classes are loaded by a container
classloader, but the logging of a specific instance of
the classes should be governed by the configuration of
the webapp. AFAICT, this will require dynamic
discovery based on the TCCL.
I too prefer the simplicity (and lack of memory leaks)
of static binding, but given the above and the recent
discussion continue to see a long life for dynamic
discovery as well. This gets me thinking of how
carefully we're going to have to document things when
we provide both static and dynamic discovery. For
example, if we provide a commons-logging-jdk14.jar,
we'll have to make clear that deploying it with your
EJBs won't work if the container has
commons-logging.log4j.jar on the classpath, that it
won't work in a webapp on JBoss, etc.
Brian
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Mon, 2005-05-02 at 22:45 +1200, Simon Kitching wrote:
> On Sun, 2005-05-01 at 11:57 +0100, robert burrell donkin wrote:
> > On Sat, 2005-04-30 at 00:35 +1200, Simon Kitching wrote:
> >
> > <snip>
> >
> > > Analysis of the effectiveness of static in the demonstration scenarios:
> > >
> > > 1-4: static fails, but that's expected. When using the static approach,
> > > you simply must deploy the static adaptor and the target library
> > > via the same classloader. I don't see that this causes any
> > > conflict with the requirements listed above.
> >
> > this is the whole point :)
> >
> > with the compile time static approach you have to deploy the libraries
> > correctly. that's the same with dynamic classloading. both static and
> > dynamic approaches work when they are deployed in perfect conditions.
> > the real question is how many of the difficult conditions are also
> > covered. static binding (in theory) covers far fewer of the possible
> > imperfect permutations than dynamic binding could. given an impl jar, it
> > would be possible for dynamic binding to (in theory) cover every case
> > with conventional context classloaders which static binding can and some
> > that static binding cannot.
>
> What "imperfect" conditions are you referring to here?
the deployment conditions: how the libraries are deployed through the
various classloaders. perfect conditions means that
> As I said, I *did* feel a little uneasy about how simple the static
> binding approach is. It provides only one way of doing things.
>
> But on the other hand, it is *predictable*, clearly *bug-free* and as
> far as I can see there is no situation in which it cannot meet the
> requirements.
>
> There simply *is* no requirement to be able to deploy the static adaptor
> lib via one classloader but deploy the actual logging library via
> another. This isn't something that anyone needs to do.
LOL! i've spent hours and hours trying to persuade users that deployment
configurations are unreasonable.
> (a) if child-first loading is in operation, then the static adaptor and
> the logging library can both be deployed via WEB-INF/lib.
>
> (b) if parent-first loading is in operation and no static adaptor is
> present in the parent, then the static adaptor and the logging library
> can both be deployed via WEB-INF/lib.
>
> (c) if parent-first loading is in operation, and a static adaptor +
> logging library are deployed via the parent, then the webapp has no
> control. If they want control, they should use child-first [see scenario
> (a)].
it's equally easy to come up with a similar simple set of recipes where
the current JCL works well. stick to a set of reasonable deployment
configurations and everything's ok.
the problem is that this isn't what users demand. even ceki came up with
a number of examples in his critique where static calling would not work
but JCL was expected to. he was right that JCL wasn't performing up to
it's theoretic limits and needed fixing but it's unfair to advocate
static binding using examples where static binding fails.
the demonstration indicates that static binding trades reliability for
flexibility: dynamic binding can be made to function in a larger number
of possible permutations.
> Having looked at SLF4J I'm feeling very unfavourable towards the the
> amount and hairiness of the code present in JCL - and even less
> favourably to making it more complex as recent proposals would do. If we
> can show that there is a reasonable setup where static binding doesn't
> work then fine - but I can't think of one, and the scenarios listed in
> the "demonstration" branch don't show one.
the key part of your proposition is the phrase reasonable setup. this is
pretty much what i meant by perfect deployment conditions.
static binding has real problems when it is referenced high in a parent
first classloader hierarchy. the particular bridged implementation will
then be fixed for all children. this configuration may be considered
unreasonable by some but it is encountered in the wild.
> > it's all a big circle but hopefully now after this long journey, things
> > can be seen more clearly. we have reached again the original point of
> > departure and disagreement: does having to change your deployment in
> > some cases (by adding log4j to the classloader containing the JCL
> > implementation) count as a fatal flaw or is it simply a pragmatic way of
> > dealing with a difficult corner case?
>
> Yes, it has been a long journey. But not a wasted one for me anyway; I'm
> now much more aware of what logging needs to do. Sometimes creating a
> simple system requires more knowledge than creating a complex one :-)
don't steal my quotes ;)
> I see selecting child-first classloading for a deployed app as the
> universal, obvious and immediate solution to all the problems. Select
> child-first and deploy your libs from WEB-INF/lib. And in that case
> static binding works fine. The deployer then never needs to change the
> jars in the classpath - the webapp bundles what it wants, and the
> child-first loading policy delivers those.
>
> What about when a webapp calls a method on an object passed to it by the
> container, and that method logs stuff? Well, in that case there's no
> guarantee that the called object uses JCL anyway, so catching logging
> from such objects really relies upon the container providing
> container-specific hooks to redirect logging. And in that case logging
> calls will end up in webapp-specific code that will statically bind via
> the webapp classloader. So no problem.
ah but it's not just web applications. bricks are used in many different
kinds of application with lots of different kinds. many of these employ
parent-first.
static binding is definitely better for parent-last (mike's new name for
child-first) classloaders. dynamic has definite advantages for parent
first.
> > i like static binding. it's clean and easier to understand than dynamic.
> > for child-first classloaders, the deployment configurations required are
> > much easier. but in a parent-first environment, difficult configurations
> > are required to allow static binding to vary on a per application basis
> > in a container. each approach has different strengths and weaknesses.
>
> So let's not support webapp-specific logging libraries accessed via
> wrappers loaded via parent classloaders at all. Tell the idiots
> attempting to do this to just choose the child-first option when
> deploying instead.
that would have been too easy :)
take half a dozen great and famous coders with big egos (and me ;) and
they'll shoot for the stars. i have a feeling that brian might have
proved that they didn't come up too far short...
> Right now, I'm in favour of a JCL 1.1 which keeps the current API, but
> which supports only static binding behind the scenes (ie we ship 1 jar
> per supported logging library). This means ripping out 95% of the code
> and replacing it with the UGLI/SLF4J approach.
>
> I'm not so convinced by the UGLI/LOG4J API, and would rather keep the
> existing JCL one for the moment. But there's no reason we can't adopt
> the same binding approach while keeping the JCL api completely binary
> compatible for the vast majority of *callers* of JCL as far as I can
> see. All that "attribute" stuff in LogFactory would probably go,
> breaking any callers that use it - but I suspect no-one does; I've never
> seen any use for it. The getFactory/getInstance methods would also have
> to go, but I don't think people ever use those either.
>
> So what we would end up with is:
> commons-logging-nop.jar
> commons-logging-simple.jar
> commons-logging-log4j.jar
> commons-logging-jdk14log.jar
> all of which are extremely small and simple.
>
> We could of course also ship a "commons-logging-dynamic.jar" which would
> have the existing discovery mechanism intact for people who want it.
>
> And none of this is irreversible, because we haven't changed the API for
> callers. In the future, JCL can revise its discovery mechanism any time
> it likes, as long as it doesn't change the Log class or the main
> LogFactory.getLog methods.
indeed, i think that we've begun to arrive at the place i've been
wanting to depart from for a long while now. the good news is that this
journey has helped both me personally understand the issues in depth and
the community to bringing together the right people.
my preferred solution for a long term has long been a mixed one:
developing both dynamic and static variants (though i prefer byte code
enhancements but i can see the merit's of ceki's compile time approach).
but this cannot be done with the current LogFactory: it's too complex.
to fix that means lifting off something that can be statically bound.
that's the point of DON_QUIXOTE.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-05-01 at 11:57 +0100, robert burrell donkin wrote:
> On Sat, 2005-04-30 at 00:35 +1200, Simon Kitching wrote:
>
> <snip>
>
> > Analysis of the effectiveness of static in the demonstration scenarios:
> >
> > 1-4: static fails, but that's expected. When using the static approach,
> > you simply must deploy the static adaptor and the target library
> > via the same classloader. I don't see that this causes any
> > conflict with the requirements listed above.
>
> this is the whole point :)
>
> with the compile time static approach you have to deploy the libraries
> correctly. that's the same with dynamic classloading. both static and
> dynamic approaches work when they are deployed in perfect conditions.
> the real question is how many of the difficult conditions are also
> covered. static binding (in theory) covers far fewer of the possible
> imperfect permutations than dynamic binding could. given an impl jar, it
> would be possible for dynamic binding to (in theory) cover every case
> with conventional context classloaders which static binding can and some
> that static binding cannot.
What "imperfect" conditions are you referring to here?
As I said, I *did* feel a little uneasy about how simple the static
binding approach is. It provides only one way of doing things.
But on the other hand, it is *predictable*, clearly *bug-free* and as
far as I can see there is no situation in which it cannot meet the
requirements.
There simply *is* no requirement to be able to deploy the static adaptor
lib via one classloader but deploy the actual logging library via
another. This isn't something that anyone needs to do.
(a) if child-first loading is in operation, then the static adaptor and
the logging library can both be deployed via WEB-INF/lib.
(b) if parent-first loading is in operation and no static adaptor is
present in the parent, then the static adaptor and the logging library
can both be deployed via WEB-INF/lib.
(c) if parent-first loading is in operation, and a static adaptor +
logging library are deployed via the parent, then the webapp has no
control. If they want control, they should use child-first [see scenario
(a)].
Having looked at SLF4J I'm feeling very unfavourable towards the the
amount and hairiness of the code present in JCL - and even less
favourably to making it more complex as recent proposals would do. If we
can show that there is a reasonable setup where static binding doesn't
work then fine - but I can't think of one, and the scenarios listed in
the "demonstration" branch don't show one.
>
> it's all a big circle but hopefully now after this long journey, things
> can be seen more clearly. we have reached again the original point of
> departure and disagreement: does having to change your deployment in
> some cases (by adding log4j to the classloader containing the JCL
> implementation) count as a fatal flaw or is it simply a pragmatic way of
> dealing with a difficult corner case?
Yes, it has been a long journey. But not a wasted one for me anyway; I'm
now much more aware of what logging needs to do. Sometimes creating a
simple system requires more knowledge than creating a complex one :-)
I see selecting child-first classloading for a deployed app as the
universal, obvious and immediate solution to all the problems. Select
child-first and deploy your libs from WEB-INF/lib. And in that case
static binding works fine. The deployer then never needs to change the
jars in the classpath - the webapp bundles what it wants, and the
child-first loading policy delivers those.
What about when a webapp calls a method on an object passed to it by the
container, and that method logs stuff? Well, in that case there's no
guarantee that the called object uses JCL anyway, so catching logging
from such objects really relies upon the container providing
container-specific hooks to redirect logging. And in that case logging
calls will end up in webapp-specific code that will statically bind via
the webapp classloader. So no problem.
>
> i like static binding. it's clean and easier to understand than dynamic.
> for child-first classloaders, the deployment configurations required are
> much easier. but in a parent-first environment, difficult configurations
> are required to allow static binding to vary on a per application basis
> in a container. each approach has different strengths and weaknesses.
So let's not support webapp-specific logging libraries accessed via
wrappers loaded via parent classloaders at all. Tell the idiots
attempting to do this to just choose the child-first option when
deploying instead.
Right now, I'm in favour of a JCL 1.1 which keeps the current API, but
which supports only static binding behind the scenes (ie we ship 1 jar
per supported logging library). This means ripping out 95% of the code
and replacing it with the UGLI/SLF4J approach.
I'm not so convinced by the UGLI/LOG4J API, and would rather keep the
existing JCL one for the moment. But there's no reason we can't adopt
the same binding approach while keeping the JCL api completely binary
compatible for the vast majority of *callers* of JCL as far as I can
see. All that "attribute" stuff in LogFactory would probably go,
breaking any callers that use it - but I suspect no-one does; I've never
seen any use for it. The getFactory/getInstance methods would also have
to go, but I don't think people ever use those either.
So what we would end up with is:
commons-logging-nop.jar
commons-logging-simple.jar
commons-logging-log4j.jar
commons-logging-jdk14log.jar
all of which are extremely small and simple.
We could of course also ship a "commons-logging-dynamic.jar" which would
have the existing discovery mechanism intact for people who want it.
And none of this is irreversible, because we haven't changed the API for
callers. In the future, JCL can revise its discovery mechanism any time
it likes, as long as it doesn't change the Log class or the main
LogFactory.getLog methods.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] requirements and static binding
Posted by robert burrell donkin <rd...@apache.org>.
On Sat, 2005-04-30 at 00:35 +1200, Simon Kitching wrote:
<snip>
> Analysis of the effectiveness of static in the demonstration scenarios:
>
> 1-4: static fails, but that's expected. When using the static approach,
> you simply must deploy the static adaptor and the target library
> via the same classloader. I don't see that this causes any
> conflict with the requirements listed above.
this is the whole point :)
with the compile time static approach you have to deploy the libraries
correctly. that's the same with dynamic classloading. both static and
dynamic approaches work when they are deployed in perfect conditions.
the real question is how many of the difficult conditions are also
covered. static binding (in theory) covers far fewer of the possible
imperfect permutations than dynamic binding could. given an impl jar, it
would be possible for dynamic binding to (in theory) cover every case
with conventional context classloaders which static binding can and some
that static binding cannot.
it's all a big circle but hopefully now after this long journey, things
can be seen more clearly. we have reached again the original point of
departure and disagreement: does having to change your deployment in
some cases (by adding log4j to the classloader containing the JCL
implementation) count as a fatal flaw or is it simply a pragmatic way of
dealing with a difficult corner case?
i like static binding. it's clean and easier to understand than dynamic.
for child-first classloaders, the deployment configurations required are
much easier. but in a parent-first environment, difficult configurations
are required to allow static binding to vary on a per application basis
in a container. each approach has different strengths and weaknesses.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org