You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by robert burrell donkin <ro...@blueyonder.co.uk> on 2005/02/08 23:25:57 UTC
[logging] discovery error handling
one of the drawbacks about JCL 1.0.x is the approach to handling errors
in the configuration and discovery mechanism. JCL falls down and (in
most commons use cases) takes the application with it. it also fails to
provide useful diagnostic information.
i've been considering for a while adopting a system for error handling
which allows a system property to be used to tune the exactly behaviour:
classic more would throw runtimes (as per now), silent more would
suppress all issues continuing to function as well as it is able and
diagnostic would print diagnostic information to System.out. though not
all environments would allow system properties to be set, i think that
this would improve matters for many common use cases.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by robert burrell donkin <rd...@apache.org>.
On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
> I know there has been a lot of discussion on this list
> of these issues, far more than I have had a chance to
> digest fully, so I apologize if I'm stating the
> obvious or missing the obvious.
very little to do with JCL is obvious :)
one of the problems is that richard and i come with JCL with our own
preconceptions. we've also talked these issues through in the past. so
> But, in any case I
> thought others might find it useful to have the
> relevant issues summarized in one document; I know I
> found Ceki's document very helpful.
thanks
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] distribution packaging
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-03-08 at 07:35, Brian Stansberry wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
> > i'd definitely be willing
> > to review patches if someone wants to volunteer to
> > alter the build,
> > create some good test cases and write up some
> > documentation.
>
> I'd be happy to take that on if a consensus is reached
> that repackaging is the way to go.
i think that repackaging might be the way to go for the future of the
1.0.x series of JCL releases. i also think that anything that can
improve this series is definitely worth doing. it has the great
advantage of being fully compatible.
opinions anyone?
> Might take me a
> bit of time though, as I'm fairly swamped.
understood :)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] distribution packaging
Posted by Brian Stansberry <be...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> (new thread on packaging)
>
> On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote:
> > What I've found is documented at
> >
> >
http://xnet.wanconcepts.com/jcl/furtherAnalysis.html.
>
>
> we need to take a longer look into repackaging. i
> didn't expect that
> altering the distributions would work so well.
I was a little surprised myself, which is why I wanted
to follow Ceki's good example and publish test cases
that could easily be verified (or debunked) by others.
> i'd definitely be willing
> to review patches if someone wants to volunteer to
> alter the build,
> create some good test cases and write up some
> documentation.
I'd be happy to take that on if a consensus is reached
that repackaging is the way to go. Might take me a
bit of time though, as I'm fairly swamped.
> i'd always suspected that static binding was the
> only solution for
> several difficult cases (but using byte code
> engineering rather than
> selective compilation as used in UGLI). the sticking
> point for this (and
> many other cases i'd like to be able to address) is
> that LogFactory is
> too complex and too tightly coupled to a container
> environment.
Yep, all the tests cases basically simulate different
types of containers. But hopefully we're close to
getting the container use cases clean.
Brian
>
> - robert
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
>
>
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[logging] distribution packaging [WAS Re: [logging] discovery
error handling]
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
(new thread on packaging)
On Thu, 2005-03-03 at 05:34, Brian Stansberry wrote:
> --- robert burrell donkin
> <ro...@blueyonder.co.uk> wrote:
<snip>
> What I've found is documented at
> http://xnet.wanconcepts.com/jcl/furtherAnalysis.html.
we need to take a longer look into repackaging. i didn't expect that
altering the distributions would work so well. i'd definitely be willing
to review patches if someone wants to volunteer to alter the build,
create some good test cases and write up some documentation.
i'd always suspected that static binding was the only solution for
several difficult cases (but using byte code engineering rather than
selective compilation as used in UGLI). the sticking point for this (and
many other cases i'd like to be able to address) is that LogFactory is
too complex and too tightly coupled to a container environment.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by Brian Stansberry <be...@yahoo.com>.
--- robert burrell donkin
<ro...@blueyonder.co.uk> wrote:
> that all depends on what is meant by fix :)
> and on what is meant by soon :)
>
> anyone (brian or dennis, maybe?) want to volunteer
> to take a look into
> improving classloading for the 1.0.x development
> stream?
>
I got some time to look into this and thought I'd
start by going through the test cases Ceki G�lc�
published (thanks Ceki). What I found was that 1) JCL
1.05RC1 goes a long way toward resolving the issues
Ceki raised, and 2) providing a
"commons-logging-impl.jar" (i.e. the
commons-logging.jar classes not included in
commons-logging-api.jar) for use in child deployments
would resolve most of the rest.
What I've found is documented at
http://xnet.wanconcepts.com/jcl/furtherAnalysis.html.
I know there has been a lot of discussion on this list
of these issues, far more than I have had a chance to
digest fully, so I apologize if I'm stating the
obvious or missing the obvious. But, in any case I
thought others might find it useful to have the
relevant issues summarized in one document; I know I
found Ceki's document very helpful.
If anyone has any comments or suggestions, they would
be most welcome.
Best regards,
Brian
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
that all depends on what is meant by fix :)
and on what is meant by soon :)
anyone (brian or dennis, maybe?) want to volunteer to take a look into
improving classloading for the 1.0.x development stream?
i'd be willing to make reviewing contributions a priority (but don't
think that i'll be able to find the energy to do this and get some
momentum back into the production of a more comprehensive solution).
- robert
On Mon, 2005-02-14 at 15:53, Richard Sitze wrote:
> It means a fix will be made available as part of the next phase.
> <ras>
>
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development
>
> Ceki Gülcü <ce...@qos.ch> wrote on 02/14/2005 06:20:14 AM:
>
> > At 05:59 PM 2/13/2005, robert burrell donkin wrote:
> >
> > > > Anyway, before camouflaging errors occurring during
> > > > Logger retrieval, I'd recommend that you fix the bug exposed by
> > > > Example 2 in my analysis [1]. In my opinion it cannot be fixed
> without
> > > > a major redesign and overhaul of JCL, but maybe I am wrong...
> > >
> > >this general issued was discussed earlier. i suspect that it would be
> > >possible to improve the situation in JCL1 but richard's more sceptical
> > >and seems keener to push straight towards JCL2. i think that there's
> > >some danger that momentum is starting to slip away so i'm probably not
> > >going to look at fix the issue in the 1.0.x stream right now.
> >
> > Does this mean that JCL won't be fixed anytime soon? :-(
> >
> > >- robert
> >
> > --
> > Ceki Gülcü
> >
> > The complete log4j manual: http://www.qos.ch/log4j/
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: [logging] discovery error handling
Posted by Richard Sitze <rs...@us.ibm.com>.
It means a fix will be made available as part of the next phase.
<ras>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Ceki Gülcü <ce...@qos.ch> wrote on 02/14/2005 06:20:14 AM:
> At 05:59 PM 2/13/2005, robert burrell donkin wrote:
>
> > > Anyway, before camouflaging errors occurring during
> > > Logger retrieval, I'd recommend that you fix the bug exposed by
> > > Example 2 in my analysis [1]. In my opinion it cannot be fixed
without
> > > a major redesign and overhaul of JCL, but maybe I am wrong...
> >
> >this general issued was discussed earlier. i suspect that it would be
> >possible to improve the situation in JCL1 but richard's more sceptical
> >and seems keener to push straight towards JCL2. i think that there's
> >some danger that momentum is starting to slip away so i'm probably not
> >going to look at fix the issue in the 1.0.x stream right now.
>
> Does this mean that JCL won't be fixed anytime soon? :-(
>
> >- robert
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [logging] discovery error handling
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:59 PM 2/13/2005, robert burrell donkin wrote:
> > Anyway, before camouflaging errors occurring during
> > Logger retrieval, I'd recommend that you fix the bug exposed by
> > Example 2 in my analysis [1]. In my opinion it cannot be fixed without
> > a major redesign and overhaul of JCL, but maybe I am wrong...
>
>this general issued was discussed earlier. i suspect that it would be
>possible to improve the situation in JCL1 but richard's more sceptical
>and seems keener to push straight towards JCL2. i think that there's
>some danger that momentum is starting to slip away so i'm probably not
>going to look at fix the issue in the 1.0.x stream right now.
Does this mean that JCL won't be fixed anytime soon? :-(
>- robert
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-02-11 at 21:49, Ceki Gülcü wrote:
> At 11:25 PM 2/8/2005, you wrote:
> >one of the drawbacks about JCL 1.0.x is the approach to handling errors
> >in the configuration and discovery mechanism. JCL falls down and (in
> >most commons use cases) takes the application with it. it also fails to
> >provide useful diagnostic information.
> >
> >i've been considering for a while adopting a system for error handling
> >which allows a system property to be used to tune the exactly behaviour:
> >classic more would throw runtimes (as per now), silent more would
> >suppress all issues continuing to function as well as it is able and
> >diagnostic would print diagnostic information to System.out. though not
> >all environments would allow system properties to be set, i think that
> >this would improve matters for many common use cases.
>
> Considering that logging often doubles as an error reporting system,
> it must be very robust to begin with. One of the toughest problems
> addressed in log4j version 1.3 the way log4j logs internally generated
> messages using itself recursively. In certain special cases, log4j
> needed a fallback logging API for its own use and that is how UGLI
> came into being.
>
> Coming back to JCL, printing something on the console in case of
> errors is not enough. JCL must to also return a valid Logger back to
> the application.
valid loggers are pretty easy to return. the problem is that the type of
logger may differ from the one the deployer expects. at the moment, JCL
just throws a runtime when things go wrong. this can be very annoying. i
suspect that this was done as part of the conservative approach to
isolating different application in containers.
> Anyway, before camouflaging errors occurring during
> Logger retrieval, I'd recommend that you fix the bug exposed by
> Example 2 in my analysis [1]. In my opinion it cannot be fixed without
> a major redesign and overhaul of JCL, but maybe I am wrong...
this general issued was discussed earlier. i suspect that it would be
possible to improve the situation in JCL1 but richard's more sceptical
and seems keener to push straight towards JCL2. i think that there's
some danger that momentum is starting to slip away so i'm probably not
going to look at fix the issue in the 1.0.x stream right now.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:25 PM 2/8/2005, you wrote:
>one of the drawbacks about JCL 1.0.x is the approach to handling errors
>in the configuration and discovery mechanism. JCL falls down and (in
>most commons use cases) takes the application with it. it also fails to
>provide useful diagnostic information.
>
>i've been considering for a while adopting a system for error handling
>which allows a system property to be used to tune the exactly behaviour:
>classic more would throw runtimes (as per now), silent more would
>suppress all issues continuing to function as well as it is able and
>diagnostic would print diagnostic information to System.out. though not
>all environments would allow system properties to be set, i think that
>this would improve matters for many common use cases.
Considering that logging often doubles as an error reporting system,
it must be very robust to begin with. One of the toughest problems
addressed in log4j version 1.3 the way log4j logs internally generated
messages using itself recursively. In certain special cases, log4j
needed a fallback logging API for its own use and that is how UGLI
came into being.
Coming back to JCL, printing something on the console in case of
errors is not enough. JCL must to also return a valid Logger back to
the application. Anyway, before camouflaging errors occurring during
Logger retrieval, I'd recommend that you fix the bug exposed by
Example 2 in my analysis [1]. In my opinion it cannot be fixed without
a major redesign and overhaul of JCL, but maybe I am wrong...
[1] http://www.qos.ch/logging/classloader.jsp
>- robert
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by Ceki Gülcü <ce...@qos.ch>.
At 02:45 AM 2/9/2005, you wrote:
>robert burrell donkin <ro...@blueyonder.co.uk> wrote on
>02/08/2005 04:25:57 PM:
>
> > one of the drawbacks about JCL 1.0.x is the approach to handling errors
> > in the configuration and discovery mechanism. JCL falls down and (in
> > most commons use cases) takes the application with it. it also fails to
> > provide useful diagnostic information.
> >
> > i've been considering for a while adopting a system for error handling
> > which allows a system property to be used to tune the exactly behaviour:
> > classic more would throw runtimes (as per now), silent more would
> > suppress all issues continuing to function as well as it is able and
> > diagnostic would print diagnostic information to System.out. though not
> > all environments would allow system properties to be set, i think that
> > this would improve matters for many common use cases.
> >
> > opinions?
>
>Yes :-), focus all efforts on improving discovery and diagnostics on
>commons-discovery, and let's abandon further efforts to improve JC
>logging/discovery, other than to regress back to "simple simple simple"
>behavior that doesn't break so easily [ala the UGLI discovery].
Richard,
The article below should strengthen your hand:
http://www.qos.ch/logging/classloader.jsp
Admittedly, it deals rather harshly with JCL but factually so, in the
sense that all examples therein can be reproduced with a Java compiler
and the JVM. For any remaining subjective interpretation, I am sure
you'll know who to blame.
If you spot any factual mistakes, please do not hesitate to contact me
so that the error can be rectified. Thanks in advance,
>*******************************************
>Richard A. Sitze
>IBM WebSphere WebServices Development
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] discovery error handling
Posted by Richard Sitze <rs...@us.ibm.com>.
robert burrell donkin <ro...@blueyonder.co.uk> wrote on
02/08/2005 04:25:57 PM:
> one of the drawbacks about JCL 1.0.x is the approach to handling errors
> in the configuration and discovery mechanism. JCL falls down and (in
> most commons use cases) takes the application with it. it also fails to
> provide useful diagnostic information.
>
> i've been considering for a while adopting a system for error handling
> which allows a system property to be used to tune the exactly behaviour:
> classic more would throw runtimes (as per now), silent more would
> suppress all issues continuing to function as well as it is able and
> diagnostic would print diagnostic information to System.out. though not
> all environments would allow system properties to be set, i think that
> this would improve matters for many common use cases.
>
> opinions?
Yes :-), focus all efforts on improving discovery and diagnostics on
commons-discovery, and let's abandon further efforts to improve JC
logging/discovery, other than to regress back to "simple simple simple"
behavior that doesn't break so easily [ala the UGLI discovery].
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development