Loggers in API Components

[Travis Reeder <tr...@gmail.com>]

Is it safe to put loggers into Spec components, for instance in
UISelectMany, to show why something is invalid?

Travis

Re: Loggers in API Components

[Sean Schofield <se...@gmail.com>]

I'm in favor of commons logging for everything (api, Impl and
tomahawk.)  I agree with Travis that a simple logging message can go a
long way in solving a problem.  In fact, robust logging can be a way
that we differentiate ourselves from other implementations.

sean

On 12/7/05, Mike Kienenberger <mk...@gmail.com> wrote:
> Logging is always contentious.   I'd rather we let the end-users
> decide, and currently the "standard" for doing that in a framework is
> to use commons-logging.  We do need to clear up whether it's ok to use
> it for the api jar file, though.
>
> Our wiki currently reads:
>
> http://wiki.apache.org/myfaces/MyFaces_Developer_Notes
> ===============================
> Logging
>
> Except in the JSF API (javax.faces.*) classes, where there must not be
> any dependencies to additional libraries, commons-logging is used for
> logging generally. Commons-logging should be used in the recommended
> way, i.e. each class has it's own private static logger.
> ===============================
>
> On 12/7/05, Martin Cooper <ma...@apache.org> wrote:
> >
> >
> >
> > On 12/6/05, Adam Winer <aw...@gmail.com> wrote:
> > > On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:
> > >
> > > > Is it really ok for stuff in the "api" and "impl" subdirs to depend on
> > > > commons-logging?
> > >
> > > AFAIK, yes.  Certainly for "impl", and I see no reason why not as well
> > > for "api", as long as it doesn't actually show up in the
> > > public/protected API.
> > >
> > >
> > > > Does the spec say anything about dependency requirements for the JSF
> > > > implementation? In particular, I'm concerned that j2ee.jar will
> > > > apparently require a JSF implementation to be included in the future; if
> > > > MyFaces is that implementation and it uses org.apache.* libs then those
> > > > libs must also be bundled in the j2ee.jar file, or be bundled by every
> > > > container that provides that j2ee file. And exposing libraries via the
> > > > container like that can cause pain, as we all found out when a buggy
> > > > version of org.apache.xerces was bundled with java 1.4 :-(
> > >
> > > JSF 1.2 requires J2SE 5.0 (both annotations and generics).  And, yeah,
> > > any full J2EE webtier server in EE 5.0 will necessary include a JSF
> > > implementation - so, for instance, any Java EE 5.0 version of Tomcat
> > > must include a JSF implementation.
> > >
> > > JSF 1.1, well, in theory it would require JDK 1.3 at a minimum -
> > > though there's no specific reason why any particular implementation
> > > couldn't decide to make 1.4 the minimum.  (And I can't specifically
> > > remember an API reason why it couldn't run on JDK 1.2 as well.)
> > >
> > > But as far as logging goes, if you're willing to take JDK 1.4 as a
> > > requirement (and I can't see why not), I find commons-logging a rather
> > > pointless bonus dependency - log4j is not sufficiently better than
> > > java.util.logging to justify its use
> >
> >  I'm quite certain that Ceki would take you to task on that comment...
> >
> >  But +1 on logging being a good thing.
> >
> >  --
> >  Martin Cooper
> >
> >
> > > , and if you're only ever going to
> > > use java.util.logging, what's the point of going through an
> > > intermediary?
> > >
> > > Total agreement with Travis that logging in the components is a very good
> > thing.
> > >
> > > Cheers,
> > > Adam
> > >
> >
> >
>

Re: Loggers in API Components

[Mike Kienenberger <mk...@gmail.com>]

Logging is always contentious.   I'd rather we let the end-users
decide, and currently the "standard" for doing that in a framework is
to use commons-logging.  We do need to clear up whether it's ok to use
it for the api jar file, though.

Our wiki currently reads:

http://wiki.apache.org/myfaces/MyFaces_Developer_Notes
===============================
Logging

Except in the JSF API (javax.faces.*) classes, where there must not be
any dependencies to additional libraries, commons-logging is used for
logging generally. Commons-logging should be used in the recommended
way, i.e. each class has it's own private static logger.
===============================

On 12/7/05, Martin Cooper <ma...@apache.org> wrote:
>
>
>
> On 12/6/05, Adam Winer <aw...@gmail.com> wrote:
> > On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:
> >
> > > Is it really ok for stuff in the "api" and "impl" subdirs to depend on
> > > commons-logging?
> >
> > AFAIK, yes.  Certainly for "impl", and I see no reason why not as well
> > for "api", as long as it doesn't actually show up in the
> > public/protected API.
> >
> >
> > > Does the spec say anything about dependency requirements for the JSF
> > > implementation? In particular, I'm concerned that j2ee.jar will
> > > apparently require a JSF implementation to be included in the future; if
> > > MyFaces is that implementation and it uses org.apache.* libs then those
> > > libs must also be bundled in the j2ee.jar file, or be bundled by every
> > > container that provides that j2ee file. And exposing libraries via the
> > > container like that can cause pain, as we all found out when a buggy
> > > version of org.apache.xerces was bundled with java 1.4 :-(
> >
> > JSF 1.2 requires J2SE 5.0 (both annotations and generics).  And, yeah,
> > any full J2EE webtier server in EE 5.0 will necessary include a JSF
> > implementation - so, for instance, any Java EE 5.0 version of Tomcat
> > must include a JSF implementation.
> >
> > JSF 1.1, well, in theory it would require JDK 1.3 at a minimum -
> > though there's no specific reason why any particular implementation
> > couldn't decide to make 1.4 the minimum.  (And I can't specifically
> > remember an API reason why it couldn't run on JDK 1.2 as well.)
> >
> > But as far as logging goes, if you're willing to take JDK 1.4 as a
> > requirement (and I can't see why not), I find commons-logging a rather
> > pointless bonus dependency - log4j is not sufficiently better than
> > java.util.logging to justify its use
>
>  I'm quite certain that Ceki would take you to task on that comment...
>
>  But +1 on logging being a good thing.
>
>  --
>  Martin Cooper
>
>
> > , and if you're only ever going to
> > use java.util.logging, what's the point of going through an
> > intermediary?
> >
> > Total agreement with Travis that logging in the components is a very good
> thing.
> >
> > Cheers,
> > Adam
> >
>
>

Re: Loggers in API Components

[Martin Cooper <ma...@apache.org>]

On 12/6/05, Adam Winer <aw...@gmail.com> wrote:
>
> On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:
>
> > Is it really ok for stuff in the "api" and "impl" subdirs to depend on
> > commons-logging?
>
> AFAIK, yes.  Certainly for "impl", and I see no reason why not as well
> for "api", as long as it doesn't actually show up in the
> public/protected API.
>
>
> > Does the spec say anything about dependency requirements for the JSF
> > implementation? In particular, I'm concerned that j2ee.jar will
> > apparently require a JSF implementation to be included in the future; if
> > MyFaces is that implementation and it uses org.apache.* libs then those
> > libs must also be bundled in the j2ee.jar file, or be bundled by every
> > container that provides that j2ee file. And exposing libraries via the
> > container like that can cause pain, as we all found out when a buggy
> > version of org.apache.xerces was bundled with java 1.4 :-(
>
> JSF 1.2 requires J2SE 5.0 (both annotations and generics).  And, yeah,
> any full J2EE webtier server in EE 5.0 will necessary include a JSF
> implementation - so, for instance, any Java EE 5.0 version of Tomcat
> must include a JSF implementation.
>
> JSF 1.1, well, in theory it would require JDK 1.3 at a minimum -
> though there's no specific reason why any particular implementation
> couldn't decide to make 1.4 the minimum.  (And I can't specifically
> remember an API reason why it couldn't run on JDK 1.2 as well.)
>
> But as far as logging goes, if you're willing to take JDK 1.4 as a
> requirement (and I can't see why not), I find commons-logging a rather
> pointless bonus dependency - log4j is not sufficiently better than
> java.util.logging to justify its use


I'm quite certain that Ceki would take you to task on that comment...

But +1 on logging being a good thing.

--
Martin Cooper


, and if you're only ever going to
> use java.util.logging, what's the point of going through an
> intermediary?
>
> Total agreement with Travis that logging in the components is a very good
> thing.
>
> Cheers,
> Adam
>

Re: Loggers in API Components

[Adam Winer <aw...@gmail.com>]

On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:

> Is it really ok for stuff in the "api" and "impl" subdirs to depend on
> commons-logging?

AFAIK, yes.  Certainly for "impl", and I see no reason why not as well
for "api", as long as it doesn't actually show up in the
public/protected API.


> Does the spec say anything about dependency requirements for the JSF
> implementation? In particular, I'm concerned that j2ee.jar will
> apparently require a JSF implementation to be included in the future; if
> MyFaces is that implementation and it uses org.apache.* libs then those
> libs must also be bundled in the j2ee.jar file, or be bundled by every
> container that provides that j2ee file. And exposing libraries via the
> container like that can cause pain, as we all found out when a buggy
> version of org.apache.xerces was bundled with java 1.4 :-(

JSF 1.2 requires J2SE 5.0 (both annotations and generics).  And, yeah,
any full J2EE webtier server in EE 5.0 will necessary include a JSF
implementation - so, for instance, any Java EE 5.0 version of Tomcat
must include a JSF implementation.

JSF 1.1, well, in theory it would require JDK 1.3 at a minimum -
though there's no specific reason why any particular implementation
couldn't decide to make 1.4 the minimum.  (And I can't specifically
remember an API reason why it couldn't run on JDK 1.2 as well.)

But as far as logging goes, if you're willing to take JDK 1.4 as a
requirement (and I can't see why not), I find commons-logging a rather
pointless bonus dependency - log4j is not sufficiently better than
java.util.logging to justify its use, and if you're only ever going to
use java.util.logging, what's the point of going through an
intermediary?

Total agreement with Travis that logging in the components is a very good thing.

Cheers,
Adam

Re: Loggers in API Components

[Simon Kitching <sk...@obsidium.com>]

Hi,

I'm not sure if support for java.util.logging is sufficiently advanced 
yet for it to be an option.

Tomcat bundles JULI since version 5.5. JULI is a custom LogManager class 
capable of separating logging by webapp. Tomcat configures JULI at 
startup, so using java.util.logging calls from code running in tomcat 
5.x should be ok.

However for servlet engines which don't set up a custom LogManager, the 
default config in $JRE_HOME/lib/logging.properties will be used. This 
will write all messages of priority INFO or higher to file ~/java%u.log, 
where ~ is the home directory of the user who started the servlet 
engine. A user can override the logging config for a container by setting
   -Djava.util.logging.config.file=myconfig.properties
in the container startup script; however that config will apply globally 
across the whole container. Only if they specify
   -Djava.util.logging.manager=some.custom.logging.manager
to point to a library like JULI will they be able to have per-webapp 
logging.

I also suspect, from experience as a maintainer of commons-logging. that 
in order to avoid memory leaks the container must *notify* its 
java.util.logging implementation when a webapp is unloaded. If I'm right 
then simply setting the container startup options to point to JULI isn't 
sufficient; the container actually needs to *integrate* with the 
specified logging lib.

I don't know how many servlet engines come with decent java.util.logging 
replacements these days. Resin? Oracle? Websphere? However the fact that 
tomcat 4.x and tomcat 5.0.x don't will make things awkward for users; 
essentially they will need to download and configure JULI in order to 
gain any control over MyFaces logging.

Unfortunately, I can't suggest a *good* solution. I'd like to avoid 
using commons-logging if possible, due to the added dependency. However 
I'm not sure java.util.logging is good for the above reasons. And as 
Travis says, good logging from MyFaces would help us all.


By the way, what is the minimal version of Java required to use MyFaces, 
and where is that documented? I can see this which *hints* that 1.4 is 
the minimum version, but nothing definitive:
    http://myfaces.apache.org/compatibility.html

Cheers,

Simon

Travis Reeder wrote:
> We could use java.util.logging, then no dependencies.  We definitely
> need some kind of logging in the components, getting a message on the
> UI that says:
> 
> "Validation Error "Segment": Value is not a valid option.", isn't
> exactly useful. A simple log message would have told me exactly what
> the problem is.  When I finally broke down and put a logger into the
> component and found out in two seconds that it was because the value
> wasn't in my select list after spending all day thinking it was
> something completely different.  For our users sake, we need this.
> 
> Travis
> 
> On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:
>> Hi,
>>
>> Is it really ok for stuff in the "api" and "impl" subdirs to depend on
>> commons-logging?
>>
>> Does the spec say anything about dependency requirements for the JSF
>> implementation? In particular, I'm concerned that j2ee.jar will
>> apparently require a JSF implementation to be included in the future; if
>> MyFaces is that implementation and it uses org.apache.* libs then those
>> libs must also be bundled in the j2ee.jar file, or be bundled by every
>> container that provides that j2ee file. And exposing libraries via the
>> container like that can cause pain, as we all found out when a buggy
>> version of org.apache.xerces was bundled with java 1.4 :-(
>>
>> I see that currently 3 classes in the "api" project use JCL, and lots of
>> classes in "impl".
>>
>> JBoss and Tomcat always provide JCL jars at the container level (which
>> is a bad idea IMHO, but that's another topic). However not all
>> containers may.
>>
>> Cheers,
>>
>> Simon
>>
>> Martin Marinschek wrote:
>>> yes.
>>>
>>> You can do whatever you want, as long as it is private ;)
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 12/7/05, Travis Reeder <tr...@gmail.com> wrote:
>>>> Is it safe to put loggers into Spec components, for instance in
>>>> UISelectMany, to show why something is invalid?

Re: Loggers in API Components

[Travis Reeder <tr...@gmail.com>]

We could use java.util.logging, then no dependencies.  We definitely
need some kind of logging in the components, getting a message on the
UI that says:

"Validation Error "Segment": Value is not a valid option.", isn't
exactly useful. A simple log message would have told me exactly what
the problem is.  When I finally broke down and put a logger into the
component and found out in two seconds that it was because the value
wasn't in my select list after spending all day thinking it was
something completely different.  For our users sake, we need this.

Travis

On 12/6/05, Simon Kitching <sk...@obsidium.com> wrote:
> Hi,
>
> Is it really ok for stuff in the "api" and "impl" subdirs to depend on
> commons-logging?
>
> Does the spec say anything about dependency requirements for the JSF
> implementation? In particular, I'm concerned that j2ee.jar will
> apparently require a JSF implementation to be included in the future; if
> MyFaces is that implementation and it uses org.apache.* libs then those
> libs must also be bundled in the j2ee.jar file, or be bundled by every
> container that provides that j2ee file. And exposing libraries via the
> container like that can cause pain, as we all found out when a buggy
> version of org.apache.xerces was bundled with java 1.4 :-(
>
> I see that currently 3 classes in the "api" project use JCL, and lots of
> classes in "impl".
>
> JBoss and Tomcat always provide JCL jars at the container level (which
> is a bad idea IMHO, but that's another topic). However not all
> containers may.
>
> Cheers,
>
> Simon
>
> Martin Marinschek wrote:
> > yes.
> >
> > You can do whatever you want, as long as it is private ;)
> >
> > regards,
> >
> > Martin
> >
> > On 12/7/05, Travis Reeder <tr...@gmail.com> wrote:
> >> Is it safe to put loggers into Spec components, for instance in
> >> UISelectMany, to show why something is invalid?
> >>
> >> Travis
> >>
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
>
>

Re: Loggers in API Components

[Simon Kitching <sk...@obsidium.com>]

Hi,

Is it really ok for stuff in the "api" and "impl" subdirs to depend on 
commons-logging?

Does the spec say anything about dependency requirements for the JSF 
implementation? In particular, I'm concerned that j2ee.jar will 
apparently require a JSF implementation to be included in the future; if 
MyFaces is that implementation and it uses org.apache.* libs then those 
libs must also be bundled in the j2ee.jar file, or be bundled by every 
container that provides that j2ee file. And exposing libraries via the 
container like that can cause pain, as we all found out when a buggy 
version of org.apache.xerces was bundled with java 1.4 :-(

I see that currently 3 classes in the "api" project use JCL, and lots of 
classes in "impl".

JBoss and Tomcat always provide JCL jars at the container level (which 
is a bad idea IMHO, but that's another topic). However not all 
containers may.

Cheers,

Simon

Martin Marinschek wrote:
> yes.
> 
> You can do whatever you want, as long as it is private ;)
> 
> regards,
> 
> Martin
> 
> On 12/7/05, Travis Reeder <tr...@gmail.com> wrote:
>> Is it safe to put loggers into Spec components, for instance in
>> UISelectMany, to show why something is invalid?
>>
>> Travis
>>
> 
> 
> --
> 
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 

Re: Loggers in API Components

[Martin Marinschek <ma...@gmail.com>]

yes.

You can do whatever you want, as long as it is private ;)

regards,

Martin

On 12/7/05, Travis Reeder <tr...@gmail.com> wrote:
> Is it safe to put loggers into Spec components, for instance in
> UISelectMany, to show why something is invalid?
>
> Travis
>


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces