You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ceki Gülcü <ce...@qos.ch> on 2002/12/11 11:04:06 UTC
JNDI based selection
I have been a long time critic of commons-logging API for its class
loader based approach of selecting the logging implementation. See for
example my http://qos.ch/logging/thinkAgain.html document. I think
more reliable solutions exist. In particular, you might want to
consider the JNDI based solution discussed in
http://qos.ch/logging/sc.html.
I suggest that you begin reading "thinkAgain.html" first and then read
sc.html. You are welcome to use the heretical ideas contained therein
to your advantage or alternatively ignore them altogether. Your
comments, constructive or otherwise, are welcome.
Regards,
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI based selection
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
>
> I have been a long time critic of commons-logging API for its class
> loader based approach of selecting the logging implementation. See for
> example my http://qos.ch/logging/thinkAgain.html document. I think
> more reliable solutions exist. In particular, you might want to
> consider the JNDI based solution discussed in
> http://qos.ch/logging/sc.html.
The class loader based _default_ approach is not perfect, but
you can plug other factories.
I like the JNDI solution, excelent idea.
One comment: application isolation is not a voluntary thing. If we want to
isolate the loggers you can't allow the application to specify what logger
it wants in web.xml and hope they'll not use the same name.
Using java:env is a great solution, probably it needs an external
config ( server.xml or the logging config file ).
Costin
>
>
> I suggest that you begin reading "thinkAgain.html" first and then read
> sc.html. You are welcome to use the heretical ideas contained therein
> to your advantage or alternatively ignore them altogether. Your
> comments, constructive or otherwise, are welcome.
>
> Regards,
>
> --
> Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI based selection
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
> OK, the solution I presented solves the "VOLUNTATRY separation of
> logging" problem. It can be further refined to address the
> "MANDATORY separation of logging" problem Costin mentions.
> Costin suggested the use of string prefixes to enforce mandatory
> separation which is quite a nice idea.
>
> One possible approach is to have the string values stored in JNDI to
> be prefixed by the host name if requested to so by the <host> element
> within the server.xml file. Thus, the log4j repository selector can
> provide a host specific logger hierarchy for the hosts that request
> the service. Moreover, the host specific logger hierarchy cannot be
> spoofed by other hosts living in the same container. Looks like we
> have got a solution to the mandatory logging separation problem.
The prefix should be set by container - and it should probably be
the "canonical" name of the application.
One remaining issue is if we allow apps to open loggers of a different
app. getLog() needs to check if a prefix is already present - and
if so do a permission check ( that would need JDK1.2 - but can be
implemented in a LogFactoryImpl ).
> Now, this solution requires that the Container directly provide
> support for log4j. Will Tomcat do that? Probably not, at least not
> until all the other containers do. How ironic would that be?
This has nothing to do with other containers.
If we add the jndi stuff to commons-logging, tomcat will set the
"prefix" env and it can also set other jndi properties that
are needed. Both log4j and commons-logging could use this info.
And of course, if LogFactory implements this lookup, then
it'll separate the loggers regardless of implementation ( we
may have a problem if both c-l and log4j are adding the prefix :-)
We already include commons-logging-api and we're in process of
migrating all the internal logging to c-l, and separating the
loggers is an important issue.
I think it would be a good idea to include log4j and log4j
specific hooks in tomcat5 - but that's an issue for tomcat-dev.
There are already some discussions about the content of the
5.0 release and increased modularity ( and a better hook system
and support for JMX ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI based selection
Posted by Ceki Gülcü <ce...@qos.ch>.
Costin Manolache wrote:
> One comment: application isolation is not a voluntary thing. If we
> want to isolate the loggers you can't allow the application to specify
> what logger it wants in web.xml and hope they'll not use the same
> name.
OK, the solution presented addresses the "voluntary separation of
logging" problem. It can be further refined to address the
"mandatory separation of logging" problem Costin mentions.
Costin suggested the use of prefixes to enforce mandatory separation.
One possible approach is to have the string values stored in JNDI to
be prefixed by the host name if requested to so by the <host> element
within the server.xml file. Thus, the log4j repository selector will
provide a host specific logger hierarchy for the hosts that request
it. Moreover, the host specific logger hierarchy cannot be spoofed by
other hosts living in the same container. Looks like we have got a
solution to the mandatory logging separation problem.
Now, this solution requires that the Container directly provide
support for log4j. Will Tomcat do that? Probably not, at least not
until all the other containers do. How ironic.
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI based selection
Posted by Ceki Gülcü <ce...@qos.ch>.
Costin Manolache wrote:
> One comment: application isolation is not a voluntary thing. If we
> want to isolate the loggers you can't allow the application to specify
> what logger it wants in web.xml and hope they'll not use the same
> name.
OK, the solution I presented solves the "VOLUNTATRY separation of
logging" problem. It can be further refined to address the
"MANDATORY separation of logging" problem Costin mentions.
Costin suggested the use of string prefixes to enforce mandatory
separation which is quite a nice idea.
One possible approach is to have the string values stored in JNDI to
be prefixed by the host name if requested to so by the <host> element
within the server.xml file. Thus, the log4j repository selector can
provide a host specific logger hierarchy for the hosts that request
the service. Moreover, the host specific logger hierarchy cannot be
spoofed by other hosts living in the same container. Looks like we
have got a solution to the mandatory logging separation problem.
Now, this solution requires that the Container directly provide
support for log4j. Will Tomcat do that? Probably not, at least not
until all the other containers do. How ironic would that be?
--
Ceki
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JNDI based selection
Posted by micael <ca...@harbornet.com>.
This is clear thinking, so far as I can see. Thanks, much appreciated.
At 11:04 AM 12/11/2002 +0100, you wrote:
>I have been a long time critic of commons-logging API for its class
>loader based approach of selecting the logging implementation. See for
>example my http://qos.ch/logging/thinkAgain.html document. I think
>more reliable solutions exist. In particular, you might want to
>consider the JNDI based solution discussed in
>http://qos.ch/logging/sc.html.
>
>
>I suggest that you begin reading "thinkAgain.html" first and then read
>sc.html. You are welcome to use the heretical ideas contained therein
>to your advantage or alternatively ignore them altogether. Your
>comments, constructive or otherwise, are welcome.
>
>Regards,
>
>--
>Ceki
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Micael
-------------------------------------------------------
This electronic mail transmission and any accompanying documents contain
information belonging to the sender which may be confidential and legally
privileged. This information is intended only for the use of the
individual or entity to whom this electronic mail transmission was sent as
indicated above. If you are not the intended recipient, any disclosure,
copying, distribution, or action taken in reliance on the contents of the
information contained in this transmission is strictly prohibited. If you
have received this transmission in error, please delete the message. Thank
you
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>