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 2006/02/18 17:14:23 UTC

[logging] new simple logging component?

i've been considering for a while whether the commons should ship a
simpler but reasonably compatible version of JCL. over the years, we've
recommended this so many times but have always left it to the actual
user to go away and do the work themselves. i've come to the conclusion
that it would be a good idea for this to be available as a separate
component.

i think that there is an argument that we leave static binding until
JCL2.0 but i would prefer a version to be available as a (limited)
substitute for 1.1.

this would be created by stripping out all the classloading magic
required to support the java 1.2 hierarchical classloading model and
would be java 1.1 compatible. most of the standard JCL configuration
mechanisms would still be used but only the class classloader would be
searched. the jar would be fully compatible with the JCL API but
semantically (and possibly also binary) incompatible with the SPI. 

no exceptions would be thrown when discovery fails: a backup log
implementation would be provided. the diagnostic log switch would allow
limited debugging of configurations.

this would be runtime only substitute: applications should still compile
against the conventional JCL jar.

use cases replacing (dynamic discovery) JCL:

* for J2ME applications
* for applets
* for some client-side applications
* for frameworks which do not want JCL dependencies (Torsten's
requirements)
* for those requiring maximum performance (at the expense of
flexibility)

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] new simple logging component?

Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2006-02-19 at 14:30 +0000, robert burrell donkin wrote:
> On Sun, 2006-02-19 at 12:35 +1100, Torsten Curdt wrote:
> > <snip/>
> > 
> > Sounds all excellent ...but IMO that's exactly what JCL2 should
> > target on. I say: let's get started with the 2.x version. 
> 
> there's nothing really holding up 2.0 now (from a technical
> perspective). i'll take a release branch from the RC5 tag.
> 
> > I would not try to push that into the 1.x version. It's a pretty big change
> 
> this new component would not require any changes to the 1.x version:
> it'd just be a more fully functional version of the NULL implementation
> you proposed earlier.
> 
> my plan would be just to create a separate component that is fully
> compatible with the JCL 1.1 API and binary (but not semantically)
> compatible with the SPI. JCL 1.1 is likely to be around for quite a
> while so i'd like to have solutions available for those who are stuck
> with JCL 1.1. 

I hope that JCL 2.x will be API and binary compatible with the existing
user API. I don't think there is anything particularly wrong with the
following methods and would like to keep them for JCL 2.0:

   LogFactory.getLog(String)
   LogFactory.getLog(Class)
   Log.error(String) etc
   Log.isErrorEnabled() etc

And as long as we keep these, all normal uses of JCL 1.x will be
compatible with the 2.0 release.

However that's a debate for the JCL2 email thread (see below).

> 
> > ...and frankly speaking - it will also help marketing wise. JCL1
> > has a bit of a bad reputation. JCL2 could help to leave this behind.
> 
> it would be good to get JCL2 up and running ASAP but i'm not sure i have
> the energy to push it through (for the next few months, at least). i've
> dropped quite a lot of other stuff for JCL which really can't be left
> much longer. so, other people need to step up.

Understood. Thanks for interrupting your other stuff to push JCL along!

> 
> anyone care to start a new JCL2.0 design thread?

Ok, I'll do that.

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] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-02-19 at 12:35 +1100, Torsten Curdt wrote:
> <snip/>
> 
> Sounds all excellent ...but IMO that's exactly what JCL2 should
> target on. I say: let's get started with the 2.x version. 

there's nothing really holding up 2.0 now (from a technical
perspective). i'll take a release branch from the RC5 tag.

> I would not try to push that into the 1.x version. It's a pretty big change

this new component would not require any changes to the 1.x version:
it'd just be a more fully functional version of the NULL implementation
you proposed earlier.

my plan would be just to create a separate component that is fully
compatible with the JCL 1.1 API and binary (but not semantically)
compatible with the SPI. JCL 1.1 is likely to be around for quite a
while so i'd like to have solutions available for those who are stuck
with JCL 1.1. 

> ...and frankly speaking - it will also help marketing wise. JCL1
> has a bit of a bad reputation. JCL2 could help to leave this behind.

it would be good to get JCL2 up and running ASAP but i'm not sure i have
the energy to push it through (for the next few months, at least). i've
dropped quite a lot of other stuff for JCL which really can't be left
much longer. so, other people need to step up.

anyone care to start a new JCL2.0 design thread?

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-02-19 at 09:22 +0100, Boris Unckel wrote:
> Good Morning,
> 
> Torsten Curdt wrote:
> > ...and frankly speaking - it will also help marketing wise. JCL1
> > has a bit of a bad reputation. JCL2 could help to leave this behind.
> 
> JCL 1.0x "has a bit of a bad reputation": Some developers/admins 
> (profession) or people who have developer and/or admin jobs (this is not 
> the same)
> expect _any_ software to unzip, click on the start button, and 
> _everything_ works with the default settings. Even more: The whole system
> is completely self healing, regardless which error occurs.
> I understand your remark from the use in tomcat environments. A J2EE 
> server is not a plug'n'play system like a USB->MP3 stick, but some
> people seem to expect that. Until they do not change their mind and 
> recognize that there is software which has the need to read and understand
> documentation you  will have this "bit of a bad reputation".

:)

the problem is expectation: we promised automagic configuration

hubris

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Boris Unckel <bo...@gmx.net>.
Good Morning,

Torsten Curdt wrote:
> ...and frankly speaking - it will also help marketing wise. JCL1
> has a bit of a bad reputation. JCL2 could help to leave this behind.

JCL 1.0x "has a bit of a bad reputation": Some developers/admins 
(profession) or people who have developer and/or admin jobs (this is not 
the same)
expect _any_ software to unzip, click on the start button, and 
_everything_ works with the default settings. Even more: The whole system
is completely self healing, regardless which error occurs.
I understand your remark from the use in tomcat environments. A J2EE 
server is not a plug'n'play system like a USB->MP3 stick, but some
people seem to expect that. Until they do not change their mind and 
recognize that there is software which has the need to read and understand
documentation you  will have this "bit of a bad reputation".

In my company this has led to a proprietary logging framework. It is 
ment to be a independent wrapper, but in reality it just works with log4j.
It has very cruelly methods like
public void debug(Exception e, Object message);
public static void debug(String loggercategory, Object message);

Please develop JCL as it is developed now: High quality, excellent 
functionality, debug output to support solving problems, need to 
read/understand documentation
NOT: Low functionality to avoid errors to support the minority mentioned 
above.

Regards
Boris


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Torsten Curdt <tc...@apache.org>.
<snip/>

Sounds all excellent ...but IMO that's exactly what JCL2 should
target on. I say: let's get started with the 2.x version. I would
not try to push that into the 1.x version. It's a pretty big change

...and frankly speaking - it will also help marketing wise. JCL1
has a bit of a bad reputation. JCL2 could help to leave this behind.

cheers
--
Torsten

Re: [logging] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2006-02-18 at 18:25 +0100, Boris Unckel wrote:
> Hello Robert,
> 
> robert burrell donkin wrote:
> > the java 2 model causes issues with J2ME, embedded applications and some
> > containers which be found on clients and the failure of very many
> > container and framework vendors to create applications that adhere to
> > this specification causes the majority of problems users experience with
> > JCL. 
> >   
> I have searched the JSRs several times but I did not find any 
> requirement, recommendation for J2EE
> classloader delegation modells. Could you provide an URL/PDF and exact 
> page where to read this?
> I am interested both in the EJB-Container and the Servlet/JSP-Container 
> part.

references are given in
http://jakarta.apache.org/commons/logging/tech.html

the difficulties arise from the conflicts between the original java 2
era specifications (including the servlet specification) and the later
ones including the various later J2EE era specifications. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Craig McClanahan <cr...@apache.org>.
On 2/18/06, Boris Unckel <b....@gmx.net> wrote:
>
> Hello Robert,
>
> robert burrell donkin wrote:
> > the java 2 model causes issues with J2ME, embedded applications and some
> > containers which be found on clients and the failure of very many
> > container and framework vendors to create applications that adhere to
> > this specification causes the majority of problems users experience with
> > JCL.
> >
> I have searched the JSRs several times but I did not find any
> requirement, recommendation for J2EE
> classloader delegation modells. Could you provide an URL/PDF and exact
> page where to read this?
> I am interested both in the EJB-Container and the Servlet/JSP-Container
> part.


You are probably looking for these pointers (using the J2EE 1.4 family of
specs -- similar stuff is in the JavaEE 5 versions):

(1) Class loading requirements for the J2EE platform as a whole
     is in the J2EE Platform Specification, sections J2EE.6.2.4.8
     and J2EE.8.2.

    http://jcp.org/en/jsr/detail?id=151

(2) Class loading requirements specifically for servlet containers
     are described in the Servlet Specificat, sections SRV.9.7.1
     and SRV.9.7.2.

     http://jcp.org/en/jsr/detail?id=154

Regards
> Boris


Craig

Re: [logging] new simple logging component?

Posted by Boris Unckel <b....@gmx.net>.
Hello Karthik,

Karthik Kumar wrote:
> Robert said J2ME.
> J2ME has issues with classloading? :o
J2ME is not my domain, I have never written any app or API for it. I 
just have read container
and I do not know if there is something over a J2ME Virtual Machine(VM) 
that can be compared
to a J2SE VM and EJB/Servlet Container.

Even if this is not corresponding to the original thread - I am still 
interested in the exact specification for
J2EE classloader recommendations.

Regards
Boris


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2006-02-18 at 23:01 +0530, Karthik Kumar wrote:
> Robert said J2ME.
> 
> J2ME has issues with classloading? :o

AIUI it's typical for classloading to be performed by a single simple
classloader. this is basically the java 1 classloading model.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Karthik Kumar <ka...@gmail.com>.
Robert said J2ME.

J2ME has issues with classloading? :o

--
Karthik

Re: [logging] new simple logging component?

Posted by Boris Unckel <b....@gmx.net>.
Hello Robert,

robert burrell donkin wrote:
> the java 2 model causes issues with J2ME, embedded applications and some
> containers which be found on clients and the failure of very many
> container and framework vendors to create applications that adhere to
> this specification causes the majority of problems users experience with
> JCL. 
>   
I have searched the JSRs several times but I did not find any 
requirement, recommendation for J2EE
classloader delegation modells. Could you provide an URL/PDF and exact 
page where to read this?
I am interested both in the EJB-Container and the Servlet/JSP-Container 
part.

Regards
Boris


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sat, 2006-02-18 at 21:45 +0530, Karthik Kumar wrote:
> Well,
> 
> Is 1.1 really used nowadays? i mean.. at least 1.2 is acceptable coz the
> threading model was changed.

J2ME, (some) applets and lots of embedded applications

> We could, strip out all unwanted loggers, and give a lite-version of JCL
> (with SimpleLogger), IMHO.

it's not the lightness: it's the dynamic discovery model. 

the dynamic discovery mechanism used in JCL is based on the java 2
classloader model (thread context classloaders, hierarchies and so on).
the dynamic discovery in the new component would be based on the simpler
java 1 classloader model. 

the java 2 model causes issues with J2ME, embedded applications and some
containers which be found on clients and the failure of very many
container and framework vendors to create applications that adhere to
this specification causes the majority of problems users experience with
JCL. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Karthik Kumar <ka...@gmail.com>.
Well,

Is 1.1 really used nowadays? i mean.. at least 1.2 is acceptable coz the
threading model was changed.

We could, strip out all unwanted loggers, and give a lite-version of JCL
(with SimpleLogger), IMHO.

On 2/18/06, robert burrell donkin <ro...@blueyonder.co.uk>
wrote:
>
> i've been considering for a while whether the commons should ship a
> simpler but reasonably compatible version of JCL. over the years, we've
> recommended this so many times but have always left it to the actual
> user to go away and do the work themselves. i've come to the conclusion
> that it would be a good idea for this to be available as a separate
> component.
>
> i think that there is an argument that we leave static binding until
> JCL2.0 but i would prefer a version to be available as a (limited)
> substitute for 1.1.
>
> this would be created by stripping out all the classloading magic
> required to support the java 1.2 hierarchical classloading model and
> would be java 1.1 compatible. most of the standard JCL configuration
> mechanisms would still be used but only the class classloader would be
> searched. the jar would be fully compatible with the JCL API but
> semantically (and possibly also binary) incompatible with the SPI.
>
> no exceptions would be thrown when discovery fails: a backup log
> implementation would be provided. the diagnostic log switch would allow
> limited debugging of configurations.
>
> this would be runtime only substitute: applications should still compile
> against the conventional JCL jar.
>
> use cases replacing (dynamic discovery) JCL:
>
> * for J2ME applications
> * for applets
> * for some client-side applications
> * for frameworks which do not want JCL dependencies (Torsten's
> requirements)
> * for those requiring maximum performance (at the expense of
> flexibility)
>
> opinions?
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Karthik
http://guilt.bafsoft.net

Re: [logging] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-02-19 at 10:45 +1300, Simon Kitching wrote:
> On Sat, 2006-02-18 at 21:33 +0000, robert burrell donkin wrote:
> > On Sun, 2006-02-19 at 10:05 +1300, Simon Kitching wrote:
> > > On Sat, 2006-02-18 at 16:14 +0000, robert burrell donkin wrote:
> > > > i've been considering for a while whether the commons should ship a
> > > > simpler but reasonably compatible version of JCL. over the years, we've
> > > > recommended this so many times but have always left it to the actual
> > > > user to go away and do the work themselves. i've come to the conclusion
> > > > that it would be a good idea for this to be available as a separate
> > > > component.
> > > 
> > > I'm ok with this idea. It certainly would be useful.
> > > 
> > > However I think that JCL2.0 won't be too hard to create, and we would of
> > > course end up generating exactly this as part of JCL2.0. So I would
> > > probably prefer to just leave this work until then, rather than delay
> > > the 1.1 release. If someone (you?) really wants to work on this, then
> > > perhaps that could be done as a 1.1.1 release?
> > 
> > i was thinking about a completely separate commons component with an
> > independent lifecycle. 
> 
> Well, this component would become obsolete as soon as JCL2.0 was
> released. Also seems confusing for two commons components to offer
> classes with the same names.

that's true enough

> If it's to be a temporary thing only, then perhaps a sourceforge project
> would be a better home for this?

depends on what you mean by temporary :)

given the vast number of containers, applications and frameworks that
use JCL, it may take several years before JCL 1.x is replaced in even a
simple majority of installations. so, this component would need to be
made available for at least as long as JCL is in common usage. 

there are also political reasons why it might be better to host the
component here. many companies have misguided policies which make it
easy to use apache components but difficult for those hosted offshore. 

since we're going to need to provide support for JCL 1.x for a number of
years ahead, it would probably make sense to move JCL 1.x into a legacy
section once JCL 2.0 is ready. we could move this component there at the
same time.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-02-18 at 21:33 +0000, robert burrell donkin wrote:
> On Sun, 2006-02-19 at 10:05 +1300, Simon Kitching wrote:
> > On Sat, 2006-02-18 at 16:14 +0000, robert burrell donkin wrote:
> > > i've been considering for a while whether the commons should ship a
> > > simpler but reasonably compatible version of JCL. over the years, we've
> > > recommended this so many times but have always left it to the actual
> > > user to go away and do the work themselves. i've come to the conclusion
> > > that it would be a good idea for this to be available as a separate
> > > component.
> > 
> > I'm ok with this idea. It certainly would be useful.
> > 
> > However I think that JCL2.0 won't be too hard to create, and we would of
> > course end up generating exactly this as part of JCL2.0. So I would
> > probably prefer to just leave this work until then, rather than delay
> > the 1.1 release. If someone (you?) really wants to work on this, then
> > perhaps that could be done as a 1.1.1 release?
> 
> i was thinking about a completely separate commons component with an
> independent lifecycle. 

Well, this component would become obsolete as soon as JCL2.0 was
released. Also seems confusing for two commons components to offer
classes with the same names.

If it's to be a temporary thing only, then perhaps a sourceforge project
would be a better home for this?

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] new simple logging component?

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Sun, 2006-02-19 at 10:05 +1300, Simon Kitching wrote:
> On Sat, 2006-02-18 at 16:14 +0000, robert burrell donkin wrote:
> > i've been considering for a while whether the commons should ship a
> > simpler but reasonably compatible version of JCL. over the years, we've
> > recommended this so many times but have always left it to the actual
> > user to go away and do the work themselves. i've come to the conclusion
> > that it would be a good idea for this to be available as a separate
> > component.
> 
> I'm ok with this idea. It certainly would be useful.
> 
> However I think that JCL2.0 won't be too hard to create, and we would of
> course end up generating exactly this as part of JCL2.0. So I would
> probably prefer to just leave this work until then, rather than delay
> the 1.1 release. If someone (you?) really wants to work on this, then
> perhaps that could be done as a 1.1.1 release?

i was thinking about a completely separate commons component with an
independent lifecycle. 

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [logging] new simple logging component?

Posted by Simon Kitching <sk...@apache.org>.
On Sat, 2006-02-18 at 16:14 +0000, robert burrell donkin wrote:
> i've been considering for a while whether the commons should ship a
> simpler but reasonably compatible version of JCL. over the years, we've
> recommended this so many times but have always left it to the actual
> user to go away and do the work themselves. i've come to the conclusion
> that it would be a good idea for this to be available as a separate
> component.

I'm ok with this idea. It certainly would be useful.

However I think that JCL2.0 won't be too hard to create, and we would of
course end up generating exactly this as part of JCL2.0. So I would
probably prefer to just leave this work until then, rather than delay
the 1.1 release. If someone (you?) really wants to work on this, then
perhaps that could be done as a 1.1.1 release?

Cheers,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org