myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@obsidium.com>
Subject Re: Loggers in API Components
Date Thu, 15 Dec 2005 03:38:19 GMT
Hi,

I've had a go at building a logging lib as required. However I've 
realized something to do with dependencies that I think is rather important.

It's a known rule that no new classes can be added to the "javax.faces" 
namespace.

Are non-javax.faces classes allowed to be bundled in the myfaces-api.jar 
file? I presume not.

So in that case, any logging code that is used by the api classes would 
have to be distributed in a separate jar that is a "dependency" of the 
myfaces-api.jar file. But doesn't that turn the restriction above into 
nonsense? What's the point of forbidding non-faces classes in 
myfaces-api.jar, but allow them to be provided in a separate jar that is 
a pre-requisite of myfaces-api.jar?

I've checked the sun RI, and confirmed that their "api" classes have 
*no* import statements except for ones loading java.* and javax.*. This 
makes their api jarfile completely "stand-alone" which I believe was the 
original intent, even if the TCK doesn't currently test for that.

Unforunately, such an interpretation effectively bans any logging except 
via java.util.logging - and that's banned in JSF1.1 implementations.

It is clearly still possible to log from classes in myfaces-impl.jar. 
However it looks to me like logging should be excluded from the api jar, 
and the emphasis placed on good exception messages instead. Where it is 
desirable to emit warnings (but not throw an exception), maybe the 
message could be placed in the request and logged later by some class in 
the impl library.

API classes that currently do logging:
  * UIComponentBase (one warning message, no exception thrown)
  * FacesServlet (just trace-level enter/exit logging)
  * UIComponentTag (one error message; exception thrown immediately after)

Cheers,

Simon

>> Martin Marinschek wrote:
>>> Ok,
>>>
>>> still another issue, another vote.
>>>
>>> For the short run, Travis should go with commons-logging IMHO.
>>>
>>> For the long run, it might be optimal to wrap away commons-logging. If
>>> someone actually implements that, I don't see a problem with this
>>> approach. Simon, you are volunteering, I suppose ;) ?
>>>
>>> This is something we should do consistently across all subprojects,
>>> though. Also for Tobago, also for the eventual Cherokee, etc. So our
>>> fellow co-committers get a say in this as well.
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 12/15/05, Simon Kitching <skitching@obsidium.com> wrote:
>>>> Martin Marinschek wrote:
>>>>> -1 java.util.logging
>>>>>
>>>>> +1 commons-logging - cause this is used right now all over the codebase.
>>>>>
>>>>> If we want to change to use log4j directly, this would be another
>>>>> issue, another vote.
>>>> I would prefer to see some myfaces logging API that would be a facade,
>>>> avoiding a compilation dependency between general MyFaces classes and
>>>> *any* external library for logging (including commons-logging).
>>>>
>>>> This facade should consist of 2 classes of about 20 lines each, which
>>>> simply map directly to commons-logging. Why? Because when a container
>>>> producer wants to ship MyFaces but not commons-logging, they then just
>>>> write their own mapping to their choice of logging library and repackage
>>>> MyFaces. Two classes need to be changed, not hundreds.
>>>>
>>>> Note that this is *not* duplicating commons-logging functionality (I'm a
>>>> commons-logging developer). This simply means that the MyFaces source
>>>> code doesn't contain org.apache.commons.logging references anywhere
>>>> except in the facade, localising the places where the container producer
>>>> needs to make changes. The library as shipped would still have a *hard*
>>>> runtime dependency on commons-logging, ie won't even start unless
>>>> commons-logging is in the classpath. This is different from the kind of
>>>> dependency commons-logging has on log4j/etc, and because of this the
>>>> mapping is much simpler and therefore performant.
>>>>
>>>> Note; I haven't yet proved that the above is possible, though I'm fairly
>>>> confident having worked with logging libs for a long while now. This
>>>> thread has pushed me to propose the above before I'm really prepared :-)
>>>>
>>>> Cheers,
>>>>
>>>> Simon
>>>>


Mime
View raw message