You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Javier Iglesias <Ja...@unil.ch> on 2006/05/24 15:04:40 UTC
URLStreamHandler and ContentHandler
Hi there!
I'm working on a framework that uses its own URL scheme
("protocol": oan://host/file...) by extension of
java.net.URLStreamHandler. It also uses its own content
handlers by extension of java.net.ContentHandler.
Using Sun's default resolution mechanisms, their respective
packages are appended to the "java.protocol.handler.pkgs" and
"java.content.handler.pkgs" System properties.
Everything works fine, until I try to use my protocol and
content handlers in a webapp deployed on Tomcat 5.5.17/MacOSX...
[1] From what I could gather from the documentation and forums,
the jars containing my classes should be placed in
$CATALINA_HOME/common/endorsed/. Is it correct?
Indeed, they are not considered by Tomcat's class loader if they
are copied to $CATALINA_HOME/mywebapp/WEB-INF/lib/. I tried
$CATALINA_HOME/common/lib/ too, without success.
[2] Apparently, all the dependencies (.jars) required by my
handlers jars should also be placed in $CATALINA_HOME/common/endorsed/
or the classes cannot be instantiated by mines. Still correct?
[3] One of those dependencies itself depends on
apache-commons-logging.jar.
[3a] If I put this jar in $CATALINA_HOME/common/endorsed/, Tomcat
refuses to launch. Does it happen due to a collision with
$CATALINA_HOME/bin/commons-logging-api.jar?
-------------------------------------------------------------------------------------
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerException))
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
at org.apache.catalina.startup.Bootstrap.<clinit>(Bootstrap.java:53)
Caused by: org.apache.commons.logging.LogConfigurationException:
java.lang.NullPointerException (Caused by java.lang.NullPointerEx
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
... 4 more
Caused by: java.lang.NullPointerException
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:374)
... 5 more
-------------------------------------------------------------------------------------
[3b] If I remove apache-commons-logging.jar. from
$CATALINA_HOME/common/endorsed/, then I get a
NoClassDefFoundError for org.apache.commons.logging.LogFactory
Using java -verbose... I could check that my classes are properly
loaded, as well as org.apache.commons.logging.LogFactory by the System,
but this loading fails when requested through my code's dependencies.
Thanks in advance for all the wisdom you will poor into my inbox!
Best wishes,
--javier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
> Ok, this particular one is not 100% FUD, it's merely hugely inflating
> issues which may occur when log4j is used and is deployed in certain
> ways, and which can also be caused by bugs in Tomcat's logging usage
> (getting a logger without the proper classloader being bound, etc). In
> the end, having a more robust logging implementation would most likely
> also avoid problems.
Agreed.
Do we want to do something in this area beyond the current JULI
implementation for Tomcat 6.0?
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hola,
> For starters, I don't think the article is total FUD. It's may be
> outdated, and like I said progress has been made by multiple parties
> involved (Tomcat with JULI, commons-logging with its implementation,
> log4j 1.3 in some relevant areas, SLF4j and other external projects,
> etc). But that's besides the point.
Ok, this particular one is not 100% FUD, it's merely hugely inflating
issues which may occur when log4j is used and is deployed in certain
ways, and which can also be caused by bugs in Tomcat's logging usage
(getting a logger without the proper classloader being bound, etc). In
the end, having a more robust logging implementation would most likely
also avoid problems.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Shankar Unni <sh...@netscape.net>.
Wade Chandler wrote:
> You will still be able to use your log4j while Tomcat
> uses a different internal logging package.
No, that's not what I meant. I meant that now, to configure our Tomcat +
our webapps, I need to do two distinct configuration mechanisms: one to
configure Catalina logs, and a totally different (as in mechanism) step
for webapp logging. Makes it clumsy..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Wade Chandler <hw...@yahoo.com>.
--- Shankar Unni <sh...@netscape.net> wrote:
> Yoav Shapira wrote:
>
> > More on topic, I don't mind switching Tomcat to
> java.util.logging
>
> Umm, please don't do that. For those of us who
> *have* mastered the art
> of using log4j with Tomcat (:-)), this would be a
> giant step back
> (having one logging mechanism for Tomcat and one for
> the webapps - and I
> don't want to go to java.util.Logging for our
> apps!).
>
> While I think the current situation is a bit
> unfortunate and requires a
> fair degree of knowledge of classloader hierarchies,
> it's at least a
> workable setup for most users today.
You will still be able to use your log4j while Tomcat
uses a different internal logging package. If you
have based your logging on some TC specific things
then that isn't really good and this type of thing
would be why it should be considered bad practice (if
you are really dependent upon the logging API used by
TC that is).
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Shankar Unni <sh...@netscape.net>.
Yoav Shapira wrote:
> More on topic, I don't mind switching Tomcat to java.util.logging
Umm, please don't do that. For those of us who *have* mastered the art
of using log4j with Tomcat (:-)), this would be a giant step back
(having one logging mechanism for Tomcat and one for the webapps - and I
don't want to go to java.util.Logging for our apps!).
While I think the current situation is a bit unfortunate and requires a
fair degree of knowledge of classloader hierarchies, it's at least a
workable setup for most users today.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
For starters, I don't think the article is total FUD. It's may be
outdated, and like I said progress has been made by multiple parties
involved (Tomcat with JULI, commons-logging with its implementation,
log4j 1.3 in some relevant areas, SLF4j and other external projects,
etc). But that's besides the point.
More on topic, I don't mind switching Tomcat to java.util.logging, and
I've been happy with the way JULI is working. Like you said, anything
to remove problems for our users. We just have to make sure we do it
such that users can still use log4j in their own web applications.
Yoav
On 5/24/06, Peter Rossbach <pr...@objektpark.de> wrote:
>
> Am 24.05.2006 um 16:18 schrieb Remy Maucherat:
>
> > Yoav Shapira wrote:
> >> Hola,
> >>> > Mmm, I'd hate having endorsed classes depend on commons-logging ;(
> >>>
> >>> Could you expand this thought?
> >> It's a simple thought, like I said, shooting from the hip.
> >> Commons-Logging has an unfortunate history
> >> (http://www.qos.ch/logging/thinkAgain.jsp), and the deeper /
> >> higher it
> >> is on the classpath, the worse the potential. It doesn't get much
> >> deeper on the classpath than the endorsed repository, so putting
> >> commons-logging there made me instinctively cringe a bit.
> >
> > This article is total FUD, this should be obvious. Actually, log4j
> > is one of the libraries which has been causing the most problems in
> > Tomcat (the most being held by Xerces, which thankfully is now
> > solved).
> >
> > If you want to say bye bye to logging problem, it's easy: we need
> > to switch Tomcat to java.util.logging (with an appropriate
> > LogManager and Handlers, of course).
> >
> +1 of that...
>
> > Rémy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Peter Rossbach <pr...@objektpark.de>.
Am 24.05.2006 um 16:18 schrieb Remy Maucherat:
> Yoav Shapira wrote:
>> Hola,
>>> > Mmm, I'd hate having endorsed classes depend on commons-logging ;(
>>>
>>> Could you expand this thought?
>> It's a simple thought, like I said, shooting from the hip.
>> Commons-Logging has an unfortunate history
>> (http://www.qos.ch/logging/thinkAgain.jsp), and the deeper /
>> higher it
>> is on the classpath, the worse the potential. It doesn't get much
>> deeper on the classpath than the endorsed repository, so putting
>> commons-logging there made me instinctively cringe a bit.
>
> This article is total FUD, this should be obvious. Actually, log4j
> is one of the libraries which has been causing the most problems in
> Tomcat (the most being held by Xerces, which thankfully is now
> solved).
>
> If you want to say bye bye to logging problem, it's easy: we need
> to switch Tomcat to java.util.logging (with an appropriate
> LogManager and Handlers, of course).
>
+1 of that...
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hola,
>
>
>> > Mmm, I'd hate having endorsed classes depend on commons-logging ;(
>>
>> Could you expand this thought?
>
> It's a simple thought, like I said, shooting from the hip.
> Commons-Logging has an unfortunate history
> (http://www.qos.ch/logging/thinkAgain.jsp), and the deeper / higher it
> is on the classpath, the worse the potential. It doesn't get much
> deeper on the classpath than the endorsed repository, so putting
> commons-logging there made me instinctively cringe a bit.
This article is total FUD, this should be obvious. Actually, log4j is
one of the libraries which has been causing the most problems in Tomcat
(the most being held by Xerces, which thankfully is now solved).
If you want to say bye bye to logging problem, it's easy: we need to
switch Tomcat to java.util.logging (with an appropriate LogManager and
Handlers, of course).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
> > Mmm, I'd hate having endorsed classes depend on commons-logging ;(
>
> Could you expand this thought?
It's a simple thought, like I said, shooting from the hip.
Commons-Logging has an unfortunate history
(http://www.qos.ch/logging/thinkAgain.jsp), and the deeper / higher it
is on the classpath, the worse the potential. It doesn't get much
deeper on the classpath than the endorsed repository, so putting
commons-logging there made me instinctively cringe a bit.
Now, commons-logging has been getting better with time, and I give
credit to its maintainers for this, but there are some fundamental
classloading issues at play here...
Yoav
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Javier Iglesias <Ja...@unil.ch>.
Hi Yoav,
> Mmm, I'd hate having endorsed classes depend on commons-logging ;(
Could you expand this thought?
> what happens if you don't depend on commons-logging?
It's not going to be easy to instruct the JCS and JORAM communities
to stop using commons-logging just because I wish so : )
I don't (yet) depend on commons-logging directly, even if I was
considering this possibility in a short future...
--j
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: URLStreamHandler and ContentHandler
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
Mmm, I'd hate having endorsed classes depend on commons-logging ;( I
haven't tried it myself, nor attempted to reproduce your scenario, so
this is just shooting from the hip: what happens if you don't depend
on commons-logging?
Yoav
On 5/24/06, Javier Iglesias <Ja...@unil.ch> wrote:
> Hi there!
>
> I'm working on a framework that uses its own URL scheme
> ("protocol": oan://host/file...) by extension of
> java.net.URLStreamHandler. It also uses its own content
> handlers by extension of java.net.ContentHandler.
>
> Using Sun's default resolution mechanisms, their respective
> packages are appended to the "java.protocol.handler.pkgs" and
> "java.content.handler.pkgs" System properties.
>
> Everything works fine, until I try to use my protocol and
> content handlers in a webapp deployed on Tomcat 5.5.17/MacOSX...
>
>
>
> [1] From what I could gather from the documentation and forums,
> the jars containing my classes should be placed in
> $CATALINA_HOME/common/endorsed/. Is it correct?
>
> Indeed, they are not considered by Tomcat's class loader if they
> are copied to $CATALINA_HOME/mywebapp/WEB-INF/lib/. I tried
> $CATALINA_HOME/common/lib/ too, without success.
>
>
>
> [2] Apparently, all the dependencies (.jars) required by my
> handlers jars should also be placed in $CATALINA_HOME/common/endorsed/
> or the classes cannot be instantiated by mines. Still correct?
>
>
>
> [3] One of those dependencies itself depends on
> apache-commons-logging.jar.
>
> [3a] If I put this jar in $CATALINA_HOME/common/endorsed/, Tomcat
> refuses to launch. Does it happen due to a collision with
> $CATALINA_HOME/bin/commons-logging-api.jar?
>
> -------------------------------------------------------------------------------------
> Exception in thread "main" java.lang.ExceptionInInitializerError
> Caused by: org.apache.commons.logging.LogConfigurationException:
> org.apache.commons.logging.LogConfigurationException:
> java.lang.NullPointerException (Caused by java.lang.NullPointerException))
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)
> at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)
> at org.apache.catalina.startup.Bootstrap.<clinit>(Bootstrap.java:53)
> Caused by: org.apache.commons.logging.LogConfigurationException:
> java.lang.NullPointerException (Caused by java.lang.NullPointerEx
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397)
> at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)
> ... 4 more
> Caused by: java.lang.NullPointerException
> at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:374)
> ... 5 more
> -------------------------------------------------------------------------------------
>
>
>
> [3b] If I remove apache-commons-logging.jar. from
> $CATALINA_HOME/common/endorsed/, then I get a
> NoClassDefFoundError for org.apache.commons.logging.LogFactory
>
>
>
> Using java -verbose... I could check that my classes are properly
> loaded, as well as org.apache.commons.logging.LogFactory by the System,
> but this loading fails when requested through my code's dependencies.
>
>
>
> Thanks in advance for all the wisdom you will poor into my inbox!
>
> Best wishes,
>
> --javier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org