You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jochen Wiedmann <jo...@gmail.com> on 2009/04/21 16:18:58 UTC
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
On Tue, Apr 21, 2009 at 3:30 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> They both allow the implementation
> to be chosen when you package your application - without recompliling
> anything.
The last time we had that discussion, this has been denied. If there
is new information, I'd like to listen.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 6:20 PM, Jochen Wiedmann wrote:
> One more note: Ceki is, of course, aware of that. Quoting
> http://www.slf4j.org/manual.html
>
> For example, the slf4j-log12-1.5.6.jar binding is bound at compile
> time to use log4j. In your
> code, in addition to slf4j-api-1.5.6.jar, you simply drop one and
> only one binding of your
> choice onto the appropriate class path location. Please do not place
> more than one binding
> on your class path because SLF4J can bind with one and only one
> logging framework at a time.
>
> Do you really believe, you can guarantee that there is a single
> binding file, should SLF4J be in
> widespread use?
>
For the sake of argument I'll concede this, primarily because I don't
think it is relevant to the discussion I really want to have.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Jochen Wiedmann <jo...@gmail.com>.
One more note: Ceki is, of course, aware of that. Quoting
http://www.slf4j.org/manual.html
For example, the slf4j-log12-1.5.6.jar binding is bound at compile
time to use log4j. In your
code, in addition to slf4j-api-1.5.6.jar, you simply drop one and
only one binding of your
choice onto the appropriate class path location. Please do not place
more than one binding
on your class path because SLF4J can bind with one and only one
logging framework at a time.
Do you really believe, you can guarantee that there is a single
binding file, should SLF4J be in
widespread use?
On Wed, Apr 22, 2009 at 3:17 AM, Jochen Wiedmann
<jo...@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 2:57 AM, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> I'm not sure what you mean by "SLF4J bindings will start to be part of any
>> major or minor component" and I think I've seen you make that comment
>> before. Can you provide an example of how you think that will occur?
>
> Easy. Suggest that you deliver a webapp (Pluto? :-), which contains a
> SLF4J binding. Furthermore, suggest that there is another binding in
> the web containers class path. Which one wins, aka is used? The answer
> is: It depends on the classpath. If WEB-INF/lib takes precedence, then
> the webapps binding is used. Otherwise, the containers binding will
> win. Examples for both cases can be constructed.
>
> In both cases, you'll encounter situations where logging won't work as
> expected. Obviously, both container and webapp will likely contain
> configurations for their respective logging system, aka binding. But,
> if the other binding is used, then the respective logging
> configuration will be ignored.
>
> Again, I admit that such issues are possibly less likely, given
> SFL4J's simplicity in that aspect. But it is a fairy tale, that such
> things won't occur.
>
> Jochen
>
>
> --
> I have always wished for my computer to be as easy to use as my
> telephone; my wish has come true because I can no longer figure out
> how to use my telephone.
>
> -- (Bjarne Stroustrup,
> http://www.research.att.com/~bs/bs_faq.html#really-say-that
> My guess: Nokia E50)
>
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Apr 22, 2009 at 2:57 AM, Ralph Goers <ra...@dslextreme.com> wrote:
> I'm not sure what you mean by "SLF4J bindings will start to be part of any
> major or minor component" and I think I've seen you make that comment
> before. Can you provide an example of how you think that will occur?
Easy. Suggest that you deliver a webapp (Pluto? :-), which contains a
SLF4J binding. Furthermore, suggest that there is another binding in
the web containers class path. Which one wins, aka is used? The answer
is: It depends on the classpath. If WEB-INF/lib takes precedence, then
the webapps binding is used. Otherwise, the containers binding will
win. Examples for both cases can be constructed.
In both cases, you'll encounter situations where logging won't work as
expected. Obviously, both container and webapp will likely contain
configurations for their respective logging system, aka binding. But,
if the other binding is used, then the respective logging
configuration will be ignored.
Again, I admit that such issues are possibly less likely, given
SFL4J's simplicity in that aspect. But it is a fairy tale, that such
things won't occur.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 5:39 PM, Jochen Wiedmann wrote:
>>
>
> The thing is that there is something like a "common" ClassLoader in
> Pluto (and, most possibly, in all Portlet servers).
>
> But that is nothing special: We know that from Tomcat as well. (Of
> course, the common ClassLoader isn't endorsed by the Servlet
> specification, but we all know that it is a necessity.)
>
> Now, if we start using the various class loaders, we'll have class
> loading issues with JCL. (Most of them, because people don't
> understand the concept.) But you can be sure (and that's where I
> absolutely disagree with PLUTO-533), that you can have class loading
> issues with SFL4J as well: Of course, I won't have any, if there is a
> single binding in a shared class loader. But that's mainly the case
> because SFL4J is currently less common than JCL. In other words, as
> soon as SFL4J bindings will start to be part of any major or minor
> component, they will start to override each other, causing all kind of
> trouble.
I'm not sure what you mean by "SLF4J bindings will start to be part of
any major or minor component" and I think I've seen you make that
comment before. Can you provide an example of how you think that will
occur?
>
>
> I agree that class loading issues with SFL4J will be simpler (because
> it's architecture in that aspect is much simpler), but nothing more.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Wed, Apr 22, 2009 at 12:03 AM, John Bollinger <th...@yahoo.com> wrote:
> I confess that I don't understand the portal environment very well, but if I'm following this correctly then
> PLUTO-553 is a symptom of a more fundamental issue: objects in a Pluto portlet cannot rely on the
> context classloader to be the correct one from which to obtain resources. This arises because -- as
> I understand it -- Pluto provides portlet isolation analogous to the isolation of distinct
> webapps in a servlet container, but unlike a servlet container, it
> allows one portlet to invoke methods on the live objects of another, not changing the context classloader
> when such cross-context method invocations occur.
>
> If I have analyzed that correctly then I would account it a Pluto bug, not a JCL bug.
The thing is that there is something like a "common" ClassLoader in
Pluto (and, most possibly, in all Portlet servers).
But that is nothing special: We know that from Tomcat as well. (Of
course, the common ClassLoader isn't endorsed by the Servlet
specification, but we all know that it is a necessity.)
Now, if we start using the various class loaders, we'll have class
loading issues with JCL. (Most of them, because people don't
understand the concept.) But you can be sure (and that's where I
absolutely disagree with PLUTO-533), that you can have class loading
issues with SFL4J as well: Of course, I won't have any, if there is a
single binding in a shared class loader. But that's mainly the case
because SFL4J is currently less common than JCL. In other words, as
soon as SFL4J bindings will start to be part of any major or minor
component, they will start to override each other, causing all kind of
trouble.
I agree that class loading issues with SFL4J will be simpler (because
it's architecture in that aspect is much simpler), but nothing more.
Jochen
--
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Paul Libbrecht <pa...@activemath.org>.
I know you can do that but doing this simply ruins pluggeability or?
paul
Le 21-avr.-09 à 23:22, Dennis Lundberg a écrit :
> Yes, it most certainly can. It seems to be a common misconception what
> the logging implementation cannot be predictably configured. Just
> put a
> commons-logging.properties file in your class path with the following
> line in it:
>
> org
> .apache
> .commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
>
> That will choose log4j for you.
>
> Paul Libbrecht wrote:
>> Ah, that's more clear.
>> But again, it cannot be predictable and pluggeable, or?
>>
Re: commons-logging unsuited for cross-context webapplication invocation
usage - migrating to slf4j?
Posted by Dennis Lundberg <de...@apache.org>.
Yes, it most certainly can. It seems to be a common misconception what
the logging implementation cannot be predictably configured. Just put a
commons-logging.properties file in your class path with the following
line in it:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
That will choose log4j for you.
Paul Libbrecht wrote:
> Ah, that's more clear.
> But again, it cannot be predictable and pluggeable, or?
> paul
>
>
> Le 21-avr.-09 à 22:27, Dennis Lundberg a écrit :
>
>> Sorry, I wasn't being clear. I was not talking about configuring the
>> *level* of logging, but rather the logging implementation being used.
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Paul Libbrecht <pa...@activemath.org>.
Ah, that's more clear.
But again, it cannot be predictable and pluggeable, or?
paul
Le 21-avr.-09 à 22:27, Dennis Lundberg a écrit :
> Sorry, I wasn't being clear. I was not talking about configuring the
> *level* of logging, but rather the logging implementation being used.
Re: commons-logging unsuited for cross-context webapplication invocation
usage - migrating to slf4j?
Posted by Dennis Lundberg <de...@apache.org>.
Sorry, I wasn't being clear. I was not talking about configuring the
*level* of logging, but rather the logging implementation being used.
Paul Libbrecht wrote:
> allow me to chim in,
>
> does it make sense to expect *predictable results* ?
> What you should always configure is the default logging, and that's
> done, traditionally, by making the normal threshold either info or error
> in the programme, maybe that could be enhanced ("preferred-level" ?).
>
> Full predictability does not make sense though.
> I almost never configure my logging, only when I start to explore, dig,
> and debug.
>
> paul
>
> On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:
>> Do you configure Commons Logging explicitly, by using a
>> commons-logging.properties file or are you relying on auto discovery? In
>> my experience you you should *always* configure the logging
>> implementation explicitly if you want deterministic results.
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Paul Libbrecht <pa...@activemath.org>.
allow me to chim in,
does it make sense to expect *predictable results* ?
What you should always configure is the default logging, and that's
done, traditionally, by making the normal threshold either info or
error in the programme, maybe that could be enhanced ("preferred-
level" ?).
Full predictability does not make sense though.
I almost never configure my logging, only when I start to explore,
dig, and debug.
paul
On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:
> Do you configure Commons Logging explicitly, by using a
> commons-logging.properties file or are you relying on auto
> discovery? In
> my experience you you should *always* configure the logging
> implementation explicitly if you want deterministic results.
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 7:08 PM, John Bollinger wrote:
>
>
> Ralph Goers wrote:
>> It is hard to classify something a "bug" when it is working
>> "corectly". The portlet spec requires that a portal container be a
>> webapp and that it be able to deploy and control portlets in the
>> manner in which Pluto is doing it. That could hardly be considered
>> a bug.
>
>
> Something is not working correctly, else there would be no bug
> report. Having now spent some quality time with the JSR-286
> spec and re-read the PLUTO-553 description a couple more times, I
> think I can speak a little more intelligently about this. The
> portlet spec requires that "portlet applications" be web
> applications, and that portlet containers be or extend servlet
> containers. That is not the problem. The problem is that any
> object operating in a servlet environment, including a portlet
> environment, should be able to assume that the current context
> classloader is an appropriate one for the current operating context,
> yet apparently this is not always the case in Pluto. I assert that
> this presents problems for more than just JCL.
>
> PLUTO-553 makes some hay about "cross-context" invocations, but the
> portlet spec doesn't speak at all to any such activity, so I reject
> the premise that a portlet container must support such a thing to be
> considered to work correctly.
The cross-context invocation allows Pluto to "communicate" with the
Servlet that it injected into the Portlet war. Tomcat has a setting in
server.xml which when set allows the ServletContext.getContext()
method to successfully return the ServletContext for other Web
applications running in the same host. This is what Pluto is using to
get to the portal's context. See the really nice picture at http://portals.apache.org/pluto/v11/architecture.html
. Something of this nature is required since web applications
deployed in different wars generally can't communicate effectively
with each other. In some portals classes are added to the servlet
container. IIRC Pluto can also work that way but takes advantage of
this Tomcat feature to make installation of the portal simpler.
>
>
>> Think about it this way. The end user sees a page with multiple
>> widgets on it. The end user can interact with any of them. All
>> pluto wants is that the logging that occurs work the same no matter
>> which portlet the end user interacts with. That doesn't seem too
>> unreasonable to me.
>
> All portlets in the same portlet application already log the same,
> else it is definitely a Pluto bug. You would have to do something
> very strange to make that not work. In any case, I don't think the
> issue is that all portlets should log the same. If that were the
> case then the solution would be to configure logging at the
> container level instead of inside each portlet application. That
> would provide the same logging for all portlet applications, even in
> the face of "cross-context" invocations.
You misunderstand the definition of "portlet application". A portlet
application is a war file that contains one or more portlets. Portlets
from different war files can appear on the same page in the portal. I
don't believe Pluto is attempting to control the logging that occurs
within the portlet. Unless I'm mistaken, they just want the servlet -
and any of the portal classes it uses - to use the same logging
mechanism that the portal itself is using.
>
>
>> What your answer basically says is, commons logging only supports
>> the servlet spec, not the portlet spec. I guess this falls in line
>> with https://issues.apache.org/jira/browse/LOGGING-124? Out of
>> curiosity, if commons-logging doesn't work in an OSGi container
>> then how can any commons components do logging there?
>
> I don't know about OSGi, but no, I'm not saying that commons-logging
> does not support the portlet spec. I see nothing in the portlet
> spec, including the few OSGi-related comments, that makes it any
> less compatible with commons-logging than the servlet spec (which it
> extends). On the contrary, it sounds like Pluto is probably failing
> to satisfy section SRV.9.7.2 of Servlet 2.4, concerning web
> application classloading, and I speculate that if it were meeting
> that requirement in a reasonable way then there would be no problem
> with JCL.
I can guarantee you that Pluto is not violating SRV 9.7.2. If you put
a servlet in your portlet war calls to getResource will behave as you
want. Portlets don't use that API. They use the Portlet API's version
of getResource. Pluto is the reference implementation for JSR 286 and
was the reference implementation for JSR 168, so it isn't like they
are creating something that the spec didn't envision. In fact, if the
concern you mentioned earlier regarding loading resources were true
then Pluto would be violating PLT 23.5. Presumably the TCK has
something that checks that.
FWIW, the portlet spec is much like the servlet spec. It defines what
must be provided to applications but doesn't actually say how the
container itself has to work. There are some things that the container
has to do in order to implement the spec properly, but you won't
necessarily see that called out in the spec. This is just one such
case of that.
The problem here, which you don't seem to recognize, is that Pluto
needs to do something it should be allowed to do because Tomcat allows
it. Your answer seems to be "No, you can't".
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Ralph Goers wrote:
> It is hard to classify something a "bug" when it is working "corectly". The portlet spec requires that a portal container be a webapp and that it be able to deploy and control portlets in the manner in which Pluto is doing it. That could hardly be considered a bug.
Something is not working correctly, else there would be no bug report. Having now spent some quality time with the JSR-286
spec and re-read the PLUTO-553 description a couple more times, I
think I can speak a little more intelligently about this. The portlet spec requires that "portlet applications" be web applications, and that portlet containers be or extend servlet containers. That is not the problem. The problem is that any object operating in a servlet environment, including a portlet environment, should be able to assume that the current context classloader is an appropriate one for the current operating context, yet apparently this is not always the case in Pluto. I assert that this presents problems for more than just JCL.
PLUTO-553 makes some hay about "cross-context" invocations, but the portlet spec doesn't speak at all to any such activity, so I reject the premise that a portlet container must support such a thing to be considered to work correctly.
> Think about it this way. The end user sees a page with multiple widgets on it. The end user can interact with any of them. All pluto wants is that the logging that occurs work the same no matter which portlet the end user interacts with. That doesn't seem too unreasonable to me.
All portlets in the same portlet application already log the same, else it is definitely a Pluto bug. You would have to do something very strange to make that not work. In any case, I don't think the issue is that all portlets should log the same. If that were the case then the solution would be to configure logging at the container level instead of inside each portlet application. That would provide the same logging for all portlet applications, even in the face of "cross-context" invocations.
> What your answer basically says is, commons logging only supports the servlet spec, not the portlet spec. I guess this falls in line with https://issues.apache.org/jira/browse/LOGGING-124? Out of curiosity, if commons-logging doesn't work in an OSGi container then how can any commons components do logging there?
I don't know about OSGi, but no, I'm not saying that commons-logging does not support the portlet spec. I see nothing in the portlet spec, including the few OSGi-related comments, that makes it any less compatible with commons-logging than the servlet spec (which it extends). On the contrary, it sounds like Pluto is probably failing to satisfy section SRV.9.7.2 of Servlet 2.4, concerning web application classloading, and I speculate that if it were meeting that requirement in a reasonable way then there would be no problem with JCL.
John
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 3:03 PM, John Bollinger wrote:
> I confess that I don't understand the portal environment very well,
> but if I'm following this correctly then PLUTO-553 is a symptom of a
> more fundamental issue: objects in a Pluto portlet cannot rely on
> the context classloader to be the correct one from which to obtain
> resources. This arises because -- as I understand it -- Pluto
> provides portlet isolation analogous to the isolation of distinct
> webapps in a servlet container, but unlike a servlet container, it
> allows one portlet to invoke methods on the live objects of another,
> not changing the context classloader when such cross-context method
> invocations occur.
>
> If I have analyzed that correctly then I would account it a Pluto
> bug, not a JCL bug.
It is hard to classify something a "bug" when it is working
"corectly". The portlet spec requires that a portal container be a
webapp and that it be able to deploy and control portlets in the
manner in which Pluto is doing it. That could hardly be considered a
bug.
Think about it this way. The end user sees a page with multiple
widgets on it. The end user can interact with any of them. All pluto
wants is that the logging that occurs work the same no matter which
portlet the end user interacts with. That doesn't seem too
unreasonable to me.
What your answer basically says is, commons logging only supports the
servlet spec, not the portlet spec. I guess this falls in line with https://issues.apache.org/jira/browse/LOGGING-124?
Out of curiosity, if commons-logging doesn't work in an OSGi
container then how can any commons components do logging there?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Paul Libbrecht <pa...@activemath.org>.
this is the type of comments I had heard several times about commons-
logging... classloader issue...
I never understood them, what you describe is a probably hypothesis.
paul
Le 22-avr.-09 à 00:03, John Bollinger a écrit :
> I confess that I don't understand the portal environment very well,
> but if I'm following this correctly then PLUTO-553 is a symptom of a
> more fundamental issue: objects in a Pluto portlet cannot rely on
> the context classloader to be the correct one from which to obtain
> resources. This arises because -- as I understand it -- Pluto
> provides portlet isolation analogous to the isolation of distinct
> webapps in a servlet container, but unlike a servlet container, it
> allows one portlet to invoke methods on the live objects of another,
> not changing the context classloader when such cross-context method
> invocations occur.
>
> If I have analyzed that correctly then I would account it a Pluto
> bug, not a JCL bug.
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 22, 2009, at 8:45 AM, Torsten Curdt wrote:
> What if one would create an JCL 2.0 experimental branch?
> Would that be OK for everyone?
>
I think that would be great. It appears that the logging page on the
wiki already has a start for ideas for 2.0. I would really like to see
John expand on the ideas he posted in his email with some concrete
examples that can be built upon.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation
usage - migrating to slf4j?
Posted by Dennis Lundberg <de...@apache.org>.
Sure, but I'd start with describing and discussing new features before
starting to code.
Torsten Curdt wrote:
> What if one would create an JCL 2.0 experimental branch?
> Would that be OK for everyone?
>
> cheers
> --
> Torsten
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Torsten Curdt <tc...@apache.org>.
What if one would create an JCL 2.0 experimental branch?
Would that be OK for everyone?
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 22, 2009, at 7:38 AM, sebb wrote:
>
> I could be wrong here, but it seems to me that SLF4J also relies on
> the ClassLoader to find the implementation.
>
> It's not clear whether Pluto would work if the properties file were
> used to define the CL implementation.
>
> It may be that CL cannot work with Pluto, but I'm not sure that has
> been proved.
>
> I'm not saying Pluto is wrong to use SLF4J, but the cited reasons may
> not be true.
>>
I am not sure that finding the implementation was the problem. As I
said, I am not intimate with Pluto so I'm not sure exactly what the
issue was. But the root of the problem seems to be that Commons
Logging "manages" the Class Loader. Whether it is to find the logging
implementation, loggers or whatever I can't say for sure without
asking Ate. This doesn't work well for applications that are also
"managing" the class loader. SLF4J won't have that problem since it
doesn't do that.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by sebb <se...@gmail.com>.
On 22/04/2009, Ralph Goers <ra...@dslextreme.com> wrote:
>
> On Apr 21, 2009, at 11:11 PM, Jörg Schaible wrote:
>
>
> > Hi Ralph,
> >
> > Ralph Goers wrote at Mittwoch, 22. April 2009 05:19:
> >
> > [snip]
> >
> >
> > > Does it really matter that you understand what they are trying to do?
> > > What should matter is what they are trying to do doesn't work properly
> > > and they couldn't find a work around.
> > >
> >
> > Did anyone of them ask here and try to explain the situation? All I ever
> > here is "it's a known issue that CL does not work, so let's switch". What
> a
> > great reasoning.
> >
>
> If they got interrogated like what you've been doing in this thread I could
> understand why they didn't bother. I suspect though that they understand
> that the fundamental design of how commons logging works is the problem.
>
> >
> >
> >
> > > I'm still at a loss as to how this conversation has devolved to this.
> > > This post was meant as an example as to why yet another project is
> > > switching away from Commons Logging.
> > >
> >
> > Yes, and they are switching probably for the wrong reasons. If they really
> > expect the classloading issues going away with SLF4J, I wonder, if they
> > really tested webapps that make usage of SLF4J themselves under the same
> > conditions.
> >
>
> Who are you to tell them that they are switching for the wrong reasons? You
> read their Jira issue and decided what they want to do is wrong so there
> must not be a problem with Commons Logging. They have since updated the
> issue to clearly answer your question. You still won't like it because
> Commons Logging doesn't work and SLF4J does.
I could be wrong here, but it seems to me that SLF4J also relies on
the ClassLoader to find the implementation.
It's not clear whether Pluto would work if the properties file were
used to define the CL implementation.
It may be that CL cannot work with Pluto, but I'm not sure that has been proved.
I'm not saying Pluto is wrong to use SLF4J, but the cited reasons may
not be true.
>
> >
> >
> >
> > > I'll ask again. What is next for Commons Logging? Is there any point
> > > in enhancing it to emulate SLF4J? Should it just stay more or less as
> > > it is while it slowly loses its customer base?
> > >
> >
> > This is more a consequence of a lot of FUD that is currently around. Yes,
> > there have been problems, but that's why version 1.1.1 is around. See that
> > guy raising the last issue in JIRA for a WebLogic 10.x instance, he's
> still
> > using 1.0.4.
> >
> > Therefore why is it necessary to use SLF4J in CC, when all other commons
> > components use CL?
> >
>
> I've itemized the reasons before. Why do I need to repeat them? And you
> are still avoiding the question.
>
> What is next for Commons Logging? Is there any point in enhancing it to
> emulate SLF4J? Should it just stay more or less as it is while it slowly
> loses its customer base?
>
> You can continue to bury your head in the sand, but projects are moving
> away from Commons Logging. Google says so.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Ralph Goers wrote:
>I'm still at a loss as to how this conversation has devolved to this. This post was meant as an example as to why yet another project is switching away from Commons Logging.
You are right. I apologize for taking the discussion so far afield.
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Jörg Schaible <jo...@gmx.de>.
John Bollinger wrote at Mittwoch, 22. April 2009 18:17:
> Ralph Goers wrote:
>> What is next for Commons Logging? Is there any point in enhancing it to
>> emulate SLF4J? Should it just stay more or less as it is while it slowly
>> loses its customer base?
>
> I think the most appropriate use case for Commons Logging always has been
> for small components intended to be reused in multiple environments, to
> adapt them to the appropriate logging system for each environment. Some
> larger projects, such as Tomcat, use it for more generalized purposes, but
> I think that is a mistake. Application projects (as opposed to
> components) should be encouraged to choose and use a low-level logging
> framework such as Log4J. If CL has a way forward then it is through
> focusing on its use as an adapter instead of trying to position it as a
> general-purpose logging framework.
>
> Furthermore, it seems clear that the class loading issues CL has
> exhibited, though mitigated in recent releases, are probably going to
> continue to present problems for some CL 1.x uses for the foreseeable
> future. (The irony of a convenience feature causing such widespread and
> tenacious trouble is not lost on me.) My solution is to abandon the idea
> of auto-adaptation, or to at least discourage its use. Therefore, I argue
> that CL should *not* attempt to evolve toward the SLF4J model, because
> that's just a different auto-adaptation approach, still likely to cause
> trouble.
>
> Instead, CL should focus technology-wise on making it as easy as possible
> to explicitly configure logging on both global and per-component bases.
> That could mean careful evaluation of defaults, more or better
> configuration sources, and / or tools for creating and maintaining logging
> configurations.
>
> Following this strategy will mean that CL's customer base *does* continue
> to shrink for a while, because some projects are using it that shouldn't
> be. It does not serve anyone well to try to keep people on CL when it's
> the wrong tool for the job. On the other hand, I think this strategy can
> ultimately grow the customer base by shedding CL's image problem and
> providing a clearer message of when, why, and how to use it.
Thanks John, you summed this up much better than I could have done it.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Ralph Goers wrote:
> What is next for Commons Logging? Is there any point in enhancing it to emulate SLF4J? Should it just stay more or less as it is while it slowly loses its customer base?
I think the most appropriate use case for Commons Logging always has been for small components intended to be reused in multiple environments, to adapt them to the appropriate logging system for each environment. Some larger projects, such as Tomcat, use it for more generalized purposes, but I think that is a mistake. Application projects (as opposed to components) should be encouraged to choose and use a low-level logging framework such as Log4J. If CL has a way forward then it is through focusing on its use as an adapter instead of trying to position it as a general-purpose logging framework.
Furthermore, it seems clear that the class loading issues CL has exhibited, though mitigated in recent releases, are probably going to continue to present problems for some CL 1.x uses for the foreseeable future. (The irony of a convenience feature causing such widespread and tenacious trouble is not lost on me.) My solution is to abandon the idea of auto-adaptation, or to at least discourage its use. Therefore, I argue that CL should *not* attempt to evolve toward the SLF4J model, because that's just a different auto-adaptation approach, still likely to cause trouble.
Instead, CL should focus technology-wise on making it as easy as possible to explicitly configure logging on both global and per-component bases. That could mean careful evaluation of defaults, more or better configuration sources, and / or tools for creating and maintaining logging configurations.
Following this strategy will mean that CL's customer base *does* continue to shrink for a while, because some projects are using it that shouldn't be. It does not serve anyone well to try to keep people on CL when it's the wrong tool for the job. On the other hand, I think this strategy can ultimately grow the customer base by shedding CL's image problem and providing a clearer message of when, why, and how to use it.
John
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 11:11 PM, Jörg Schaible wrote:
> Hi Ralph,
>
> Ralph Goers wrote at Mittwoch, 22. April 2009 05:19:
>
> [snip]
>
>> Does it really matter that you understand what they are trying to do?
>> What should matter is what they are trying to do doesn't work
>> properly
>> and they couldn't find a work around.
>
> Did anyone of them ask here and try to explain the situation? All I
> ever
> here is "it's a known issue that CL does not work, so let's switch".
> What a
> great reasoning.
If they got interrogated like what you've been doing in this thread I
could understand why they didn't bother. I suspect though that they
understand that the fundamental design of how commons logging works is
the problem.
>
>
>> I'm still at a loss as to how this conversation has devolved to this.
>> This post was meant as an example as to why yet another project is
>> switching away from Commons Logging.
>
> Yes, and they are switching probably for the wrong reasons. If they
> really
> expect the classloading issues going away with SLF4J, I wonder, if
> they
> really tested webapps that make usage of SLF4J themselves under the
> same
> conditions.
Who are you to tell them that they are switching for the wrong
reasons? You read their Jira issue and decided what they want to do is
wrong so there must not be a problem with Commons Logging. They have
since updated the issue to clearly answer your question. You still
won't like it because Commons Logging doesn't work and SLF4J does.
>
>
>> I'll ask again. What is next for Commons Logging? Is there any point
>> in enhancing it to emulate SLF4J? Should it just stay more or less as
>> it is while it slowly loses its customer base?
>
> This is more a consequence of a lot of FUD that is currently around.
> Yes,
> there have been problems, but that's why version 1.1.1 is around.
> See that
> guy raising the last issue in JIRA for a WebLogic 10.x instance,
> he's still
> using 1.0.4.
>
> Therefore why is it necessary to use SLF4J in CC, when all other
> commons
> components use CL?
I've itemized the reasons before. Why do I need to repeat them? And
you are still avoiding the question.
What is next for Commons Logging? Is there any point in enhancing it
to emulate SLF4J? Should it just stay more or less as it is while it
slowly loses its customer base?
You can continue to bury your head in the sand, but projects are
moving away from Commons Logging. Google says so.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ralph,
Ralph Goers wrote at Mittwoch, 22. April 2009 05:19:
[snip]
> Does it really matter that you understand what they are trying to do?
> What should matter is what they are trying to do doesn't work properly
> and they couldn't find a work around.
Did anyone of them ask here and try to explain the situation? All I ever
here is "it's a known issue that CL does not work, so let's switch". What a
great reasoning.
> I'm still at a loss as to how this conversation has devolved to this.
> This post was meant as an example as to why yet another project is
> switching away from Commons Logging.
Yes, and they are switching probably for the wrong reasons. If they really
expect the classloading issues going away with SLF4J, I wonder, if they
really tested webapps that make usage of SLF4J themselves under the same
conditions.
> I'll ask again. What is next for Commons Logging? Is there any point
> in enhancing it to emulate SLF4J? Should it just stay more or less as
> it is while it slowly loses its customer base?
This is more a consequence of a lot of FUD that is currently around. Yes,
there have been problems, but that's why version 1.1.1 is around. See that
guy raising the last issue in JIRA for a WebLogic 10.x instance, he's still
using 1.0.4.
Therefore why is it necessary to use SLF4J in CC, when all other commons
components use CL?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 7:47 PM, John Bollinger wrote:
> Ralph Goers wrote:
>> I saw your update on PLUTO-553. I suggest you read the JSR 286
>> Portlet spec. Portlets can access resources using the
>> PortletContext's getResource method. This corresponds to the
>> portlet War's servlet context. In addition, portlets also have
>> access to the PortalContext.
>
> Right, but I don't see how that's relevant. Surely
> PortletContext.getResource() should be and is using the portlet
> app's context classloader, but PortalContext does not provide an
> analogous getResource() method or similar that could reasonably be
> interpreted to require a classloader resource lookup.
>
>> It is important to remember that when a portlet war is "deployed"
>> by a portal a new servlet gets added by the portal container. This
>> servlet "bridges" between the portal and the portlet.
>
> I'm fairly confident that JSR-286 specifies none of those details,
> so from a standard-compliance perspective that bit is irrelevant. I
> also acknowledge, however, that that may not be a useful perspective
> to take if Pluto is already committed to the architecture you
> describe, and furthermore that it sounds like a reasonable
> architecture.
In order to implement the spec EVERY portal must implement something
similar. It is simply not possible to have a "generic" portlet
communicate with it's portal container unless a portion of the
container is "injected" into the porlet webapp somehow. No, you won't
see that called out in the spec. They leave that part up to the
container to do whatever they need to do to make it work.
>
>
>> Most likely this is where Pluto wants the logging framework to use
>> the Portal's class loader.
>
> I don't think so. The issue description says it's about
> "determining the LogFactory for a portal/portletcontainer class
> while being cross-context *invoked from a portlet
> application*" (emphasis added). I'm having trouble figuring out the
> failure scenario too, and I'm not sure that when I understand it I
> will agree that Pluto was doing the wrong thing.
Does it really matter that you understand what they are trying to do?
What should matter is what they are trying to do doesn't work properly
and they couldn't find a work around.
I'm still at a loss as to how this conversation has devolved to this.
This post was meant as an example as to why yet another project is
switching away from Commons Logging.
I'll ask again. What is next for Commons Logging? Is there any point
in enhancing it to emulate SLF4J? Should it just stay more or less as
it is while it slowly loses its customer base?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Ralph Goers wrote:
> I saw your update on PLUTO-553. I suggest you read the JSR 286 Portlet spec. Portlets can access resources using the PortletContext's getResource method. This corresponds to the portlet War's servlet context. In addition, portlets also have access to the PortalContext.
Right, but I don't see how that's relevant. Surely PortletContext.getResource() should be and is using the portlet app's context classloader, but PortalContext does not provide an analogous getResource() method or similar that could reasonably be interpreted to require a classloader resource lookup.
> It is important to remember that when a portlet war is "deployed" by a portal a new servlet gets added by the portal container. This servlet "bridges" between the portal and the portlet.
I'm fairly confident that JSR-286 specifies none of those details, so from a standard-compliance perspective that bit is irrelevant. I also acknowledge, however, that that may not be a useful perspective to take if Pluto is already committed to the architecture you describe, and furthermore that it sounds like a reasonable architecture.
> Most likely this is where Pluto wants the logging framework to use the Portal's class loader.
I don't think so. The issue description says it's about "determining the LogFactory for a portal/portletcontainer class while being cross-context *invoked from a portlet application*" (emphasis added). I'm having trouble figuring out the failure scenario too, and I'm not sure that when I understand it I will agree that Pluto was doing the wrong thing.
John
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 3:03 PM, John Bollinger wrote:
> I confess that I don't understand the portal environment very well,
> but if I'm following this correctly then PLUTO-553 is a symptom of a
> more fundamental issue: objects in a Pluto portlet cannot rely on
> the context classloader to be the correct one from which to obtain
> resources. This arises because -- as I understand it -- Pluto
> provides portlet isolation analogous to the isolation of distinct
> webapps in a servlet container, but unlike a servlet container, it
> allows one portlet to invoke methods on the live objects of another,
> not changing the context classloader when such cross-context method
> invocations occur.
>
> If I have analyzed that correctly then I would account it a Pluto
> bug, not a JCL bug.
>
I saw your update on PLUTO-553. I suggest you read the JSR 286 Portlet
spec. Portlets can access resources using the PortletContext's
getResource method. This corresponds to the portlet War's servlet
context. In addition, portlets also have access to the PortalContext.
It is important to remember that when a portlet war is "deployed" by a
portal a new servlet gets added by the portal container. This servlet
"bridges" between the portal and the portlet. Most likely this is
where Pluto wants the logging framework to use the Portal's class
loader.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
I confess that I don't understand the portal environment very well, but if I'm following this correctly then PLUTO-553 is a symptom of a more fundamental issue: objects in a Pluto portlet cannot rely on the context classloader to be the correct one from which to obtain resources. This arises because -- as I understand it -- Pluto provides portlet isolation analogous to the isolation of distinct
webapps in a servlet container, but unlike a servlet container, it
allows one portlet to invoke methods on the live objects of another, not changing the context classloader when such cross-context method invocations occur.
If I have analyzed that correctly then I would account it a Pluto bug, not a JCL bug.
John
________________________________
From: Ralph Goers <ra...@dslextreme.com>
To: Commons Developers List <de...@commons.apache.org>
Sent: Tuesday, April 21, 2009 3:25:32 PM
Subject: Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:
>>
>
> I'm not that experienced in writing portlets or how the portlet
> container works. Can you please try to explain in more detail what the
> problem is.
>
> Commons Logging works great in a servlet container like Tomcat. Every
> webapp can have their own version of commons-logging and their own
> configuration. How does the portlet container use case differ from this?
>
> Do you configure Commons Logging explicitly, by using a
> commons-logging.properties file or are you relying on auto discovery? In
> my experience you you should *always* configure the logging
> implementation explicitly if you want deterministic results.
>
As I said in an earlier post, I follow the various portlet mailing lists but really have very little to do with the issue they are experiencing. It is documented at http://issues.apache.org/jira/browse/PLUTO-553.
In a nutshell though, the Portal is a War. Individual portlets are packaged as separate war files and are run under the direction of the main portal war. They seem to want all the portlets to use the logging configuration of the portal. Personally, I'm not sure what they are saying they want makes sense, but I guess the point is that even if it doesn't they should still be able to do it.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:
>>
>
> I'm not that experienced in writing portlets or how the portlet
> container works. Can you please try to explain in more detail what the
> problem is.
>
> Commons Logging works great in a servlet container like Tomcat. Every
> webapp can have their own version of commons-logging and their own
> configuration. How does the portlet container use case differ from
> this?
>
> Do you configure Commons Logging explicitly, by using a
> commons-logging.properties file or are you relying on auto
> discovery? In
> my experience you you should *always* configure the logging
> implementation explicitly if you want deterministic results.
>
As I said in an earlier post, I follow the various portlet mailing
lists but really have very little to do with the issue they are
experiencing. It is documented at http://issues.apache.org/jira/browse/PLUTO-553
.
In a nutshell though, the Portal is a War. Individual portlets are
packaged as separate war files and are run under the direction of the
main portal war. They seem to want all the portlets to use the logging
configuration of the portal. Personally, I'm not sure what they are
saying they want makes sense, but I guess the point is that even if it
doesn't they should still be able to do it.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation
usage - migrating to slf4j?
Posted by Dennis Lundberg <de...@apache.org>.
Ralph Goers wrote:
>
> On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote:
>
>> On Tue, Apr 21, 2009 at 5:01 PM, sebb <se...@gmail.com> wrote:
>>
>>> Well, the SLF4J website specifically says it is not necessary to
>>> recompile:
>>>
>>> http://www.slf4j.org/manual.html#swapping
>>>
>>> i.e. SLF4J chooses the logging implementation based in which logging
>>> implementation it finds on the classpath; there must be only one such.
>>>
>>> I'm not saying SLF4J is better or worse than CL, but they both allow
>>> the implementation to be configured without recompilation.
>>
>> Thanks, that means that I'll drawback from this discussion. I'd only
>> like to note that I'd clearly prefer, if we all could stick to a
>> single logging system, regardless what.
>>
>
>
> Thanks. But I'd really like to get back to what this topic was meant to
> be about.
>
> Commons currently uses Commons Logging. It is a very minimal API (too
> minimal if you ask me) and apparently still has some issues with how it
> binds to its implementation.
I'm not that experienced in writing portlets or how the portlet
container works. Can you please try to explain in more detail what the
problem is.
Commons Logging works great in a servlet container like Tomcat. Every
webapp can have their own version of commons-logging and their own
configuration. How does the portlet container use case differ from this?
Do you configure Commons Logging explicitly, by using a
commons-logging.properties file or are you relying on auto discovery? In
my experience you you should *always* configure the logging
implementation explicitly if you want deterministic results.
> The basic question is, what is next for Commons Logging? Is there any
> point in enhancing it to emulate SLF4J? Should it just stay more or less
> as it is while it slowly loses its customer base?
>
> I don't think there is much point in discussing what logging system
> Commons projects should use in the future without answering this.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Ralph Goers <ra...@dslextreme.com>.
On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote:
> On Tue, Apr 21, 2009 at 5:01 PM, sebb <se...@gmail.com> wrote:
>
>> Well, the SLF4J website specifically says it is not necessary to
>> recompile:
>>
>> http://www.slf4j.org/manual.html#swapping
>>
>> i.e. SLF4J chooses the logging implementation based in which logging
>> implementation it finds on the classpath; there must be only one
>> such.
>>
>> I'm not saying SLF4J is better or worse than CL, but they both allow
>> the implementation to be configured without recompilation.
>
> Thanks, that means that I'll drawback from this discussion. I'd only
> like to note that I'd clearly prefer, if we all could stick to a
> single logging system, regardless what.
>
Thanks. But I'd really like to get back to what this topic was meant
to be about.
Commons currently uses Commons Logging. It is a very minimal API (too
minimal if you ask me) and apparently still has some issues with how
it binds to its implementation.
The basic question is, what is next for Commons Logging? Is there any
point in enhancing it to emulate SLF4J? Should it just stay more or
less as it is while it slowly loses its customer base?
I don't think there is much point in discussing what logging system
Commons projects should use in the future without answering this.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Jochen Wiedmann <jo...@gmail.com>.
On Tue, Apr 21, 2009 at 5:01 PM, sebb <se...@gmail.com> wrote:
> Well, the SLF4J website specifically says it is not necessary to recompile:
>
> http://www.slf4j.org/manual.html#swapping
>
> i.e. SLF4J chooses the logging implementation based in which logging
> implementation it finds on the classpath; there must be only one such.
>
> I'm not saying SLF4J is better or worse than CL, but they both allow
> the implementation to be configured without recompilation.
Thanks, that means that I'll drawback from this discussion. I'd only
like to note that I'd clearly prefer, if we all could stick to a
single logging system, regardless what.
Jochen
---
I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone.
-- (Bjarne Stroustrup,
http://www.research.att.com/~bs/bs_faq.html#really-say-that
My guess: Nokia E50)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by sebb <se...@gmail.com>.
On 21/04/2009, Jochen Wiedmann <jo...@gmail.com> wrote:
> On Tue, Apr 21, 2009 at 3:30 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> > They both allow the implementation
> > to be chosen when you package your application - without recompliling
> > anything.
>
>
> The last time we had that discussion, this has been denied. If there
> is new information, I'd like to listen.
Well, the SLF4J website specifically says it is not necessary to recompile:
http://www.slf4j.org/manual.html#swapping
i.e. SLF4J chooses the logging implementation based in which logging
implementation it finds on the classpath; there must be only one such.
I'm not saying SLF4J is better or worse than CL, but they both allow
the implementation to be configured without recompilation.
> Jochen
>
>
>
> --
> I have always wished for my computer to be as easy to use as my
> telephone; my wish has come true because I can no longer figure out
> how to use my telephone.
>
> -- (Bjarne Stroustrup,
> http://www.research.att.com/~bs/bs_faq.html#really-say-that
> My guess: Nokia E50)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org