You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ralph Goers <ra...@dslextreme.com> on 2009/04/21 01:03:44 UTC
Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
FWIW - I subscribe to this list so I saw the message but have not
participated in the discussion.
This just adds to my concern with respect to what to do with commons
logging.
Ralph
Begin forwarded message:
> From: Eric Dalquist <er...@doit.wisc.edu>
> Date: April 20, 2009 1:47:42 PM PDT
> To: pluto-dev@portals.apache.org
> Subject: Re: commons-logging unsuited for cross-context
> webapplication invocation usage - migrating to slf4j?
> Reply-To: pluto-dev@portals.apache.org
> Reply-To: pluto-dev@portals.apache.org
>
> +1 to SLF4J several Jasig projects are also looking at it as an
> alternative to JCL.
>
> -Eric
>
> Ate Douma wrote:
>> Pluto community,
>>
>> I'd like to ask your intention for issue PLUTO-553:
>>
>> http://issues.apache.org/jira/browse/PLUTO-553
>>
>> Detailed information about this blocking issue can be found at
>> above JIRA page.
>> As I have described there, if nobody objects I intend to commit the
>> migration to sfl4j soon.
>> Any comments/feedback of further discussion is of course welcome.
>>
>> Regards,
>>
>> Ate
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Ate,
Ate Douma wrote at Freitag, 24. April 2009 02:09:
> Hi all,
>
> Thanks to Dennis for bringing this to my attention :)
thanks for providing now the appropriate information and for the level of
detail. It is only possible to react if such information is provided.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Hi Ate,
I'm glad your switch to SLF4J is doing what you need it to do, and I am in no way trying to persuade you to change course there. I do think, however, that the problem of classes loading required resources via the wrong ClassLoader could easily manifest in webapp / portlet components other than the logging system, thus I respectfully suggest that "trying to get rid of the ContextClassLoader use for *only* the logging" may be short sighted. I would not be so bold as to insist that the proxy solution must necessarily be useful or appropriate for you. Nevertheless, the fact that the portlet container needs to so carefully manage which context ClassLoader is used, where, and when would make me nervous if it were my responsibility. You seem comfortable with that, so I'll say no more on the topic.
Best Wishes,
John
Ate Douma wrote:
> While your example proxy solution is nice enough by itself, imo its way too much over-engineering for the issue at hand.
> We're trying to get rid of the ContextClassLoader use for *only* the logging, not add more overhead to it!
> And, in practice this solution wouldn't work for us anyway as there are other cross-context invocation usages where we
> *need* the ContextClassLoader of the caller, like when marshalling and unmarshalling complex PortletEvent payload (using
> JAXB) provided by the Portlet Application to be dispatched across potentially even other Portlet Applications (all this
> managed and coordinated from the Portal/container web app). The PortletContainer (we) know when to use the
> ContextClassLoader and when not. An all-encompassing proxy solution adds too much unnecessary overhead and actually
> blocks the usage of the real ContextClassLoader when its needed.
>
> We just needed the least intrusive and most straightforward solution available and wrapping or patching CL simply doesn't
> fit that bill.
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ate Douma <at...@douma.nu>.
Hi John,
While your example proxy solution is nice enough by itself, imo its way too much over-engineering for the issue at hand.
We're trying to get rid of the ContextClassLoader use for *only* the logging, not add more overhead to it!
And, in practice this solution wouldn't work for us anyway as there are other cross-context invocation usages where we *need* the
ContextClassLoader of the caller, like when marshalling and unmarshalling complex PortletEvent payload (using JAXB) provided by the Portlet
Application to be dispatched across potentially even other Portlet Applications (all this managed and coordinated from the Portal/container
web app). The PortletContainer (we) know when to use the ContextClassLoader and when not. An all-encompassing proxy solution adds too much
unnecessary overhead and actually blocks the usage of the real ContextClassLoader when its needed.
We just needed the least intrusive and most straightforward solution available and wrapping or patching CL simply doesn't fit that bill.
With kind regards,
Ate
John Bollinger wrote:
> Mark Thomas wrote:
>> John Bollinger wrote:
>>> See attached sample code for a class that would support this behavior.
>> Your attachment didn't make it through. Could you post it in-line?
>
> Sure:
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one or more
> * contributor license agreements. See the NOTICE file distributed with
> * this work for additional information regarding copyright ownership.
> * The ASF licenses this file to You under the Apache License, Version 2.0
> * (the "License"); you may not use this file except in compliance with
> * the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package example;
>
> import java.lang.reflect.InvocationHandler;
> import java.lang.reflect.Method;
> import java.lang.reflect.Proxy;
>
> /**
> * <p>
> * A service class that assists in managing a "context" within an application or
> * service. This version provides for creating dynamic proxies around objects
> * belonging to a particular context to ensure that those objects' methods are
> * invoked in that context.
> * </p><p>
> * Instances may be created and held on a one-per-context basis, but currently
> * there is no harm in having multiple managers for the same context.
> * Alternatively, {@code ContextManager}s are lightweight, so they may be created
> * at need and released freely. Model usage:<br/>
> * <tt><pre>
> * ContextManager contextManager = ContextManager.forCurrentContext();
> * ...
> * void passRequestToForeignContext(RequestInterface request, ForeignContext context) {
> * context.handleRequest(
> * contextManager.createProxy(request, RequestInterface.class)
> * );
> * }
> * </pre></tt>
> * </p>
> *
> * @author John C. Bollinger
> */
> public class ContextManager {
>
> /**
> * The context ClassLoader for the context managed by this ContextManager
> */
> private final ClassLoader contextClassLoader;
>
> /**
> * Initializes a new ContextManager managing the context defined by the
> * specified context {@code ClassLoader}
> *
> * @param contextClassLoader a {@code ClassLoader} representing the context
> * to be managed by this {@code ContextManager}
> */
> public ContextManager(ClassLoader contextClassLoader) {
> this.contextClassLoader = contextClassLoader;
> }
>
> /**
> * Creates and returns a {@code ContextManger} for the current context
> *
> * @return a {@code ContextManger} for the current context
> */
> public static ContextManager forCurrentContext() {
> return new ContextManager(Thread.currentThread().getContextClassLoader());
> }
>
> /**
> * Creates a dynamic proxy object wrapping the provided object and ensuring
> * that all methods of the wrapped object (when invoked via the proxy) see
> * the appropriate context ClassLoader for the context managed by this
> * {@code ContextManager}. The proxy's class will implement the specified
> * interface(s) by delegating every method invocation to the wrapped object,
> * setting the context ClassLoader before, and resetting it after.
> *
> * @param <T> an interface type that the proxy object will implement
> * @param object the object to be wrapped by the
> * @param iface a Class representing one of the interfaces the proxy's class
> * must implement, and defining the formal type of the return value and
> * the {@code object} argument
> * @param additionalIfaces {@code Class}es representing additional interfaces
> * the proxy's class must implement
> *
> * @return a proxy object wrapping the specified delegate object, and whose
> * class implements all the specified interfaces
> */
> public <T> T createProxy(T object, Class<T> iface, Class<?>... additionalIfaces) {
> Class<?>[] interfaces;
>
> /*
> * Could test to see whether the interfaces (iface and additionalIfaces)
> * are in fact interfaces (as opposed to normal classes). Haven't tested
> * what happens if they are non-interface classes, but probably Proxy
> * will fail to create the proxy object.
> *
> * Could also test whether they are null.
> */
>
> if (additionalIfaces != null) {
> /*
> * Set up the full list of interface classes the proxy will implement.
> * iface comes first, then any additionalIfaces elements, in order.
> */
>
> /*
> * Could test the additional interfaces here to make sure the
> * submitted object can successfully be cast to each type. If the
> * object's class does not implement one of the interfaces then
> * runtime failures will occur when those interfaces' methods are
> * invoked on the proxy.
> */
>
> interfaces = new Class[1 + additionalIfaces.length];
> interfaces[0] = iface;
> System.arraycopy(additionalIfaces, 0, interfaces, 1, additionalIfaces.length);
> } else {
> interfaces = new Class[] {iface};
> }
>
> return iface.cast(Proxy.newProxyInstance(contextClassLoader, interfaces,
> new ContextManagingInvocationHandler(object, contextClassLoader)));
> }
>
> /**
> * An InvocationHandler wrapping a specified object and serving to present a
> * given context ClassLoader to that object on all method invocations.
> *
> * @author John C. Bollinger
> */
> private static class ContextManagingInvocationHandler implements InvocationHandler {
>
> /*
> * This class doesn't really need to be nested. This version is nested
> * mainly for packaging purposes.
> */
>
> /**
> * The ClassLoader to set as the current context ClassLoader when
> * delegating method invocations to the {@link #wrappedObject}
> */
> private final ClassLoader contextClassLoader;
>
> /**
> * The object to which all method invocations are delegated
> */
> private final Object wrappedObject;
>
> /**
> * Initializes a new ContextManagingInvocationHandler that delegates
> * method invocations to the specified object while ensuring that the
> * current context ClassLoader is the specified one within the scope of
> * the invocation.
> *
> * @param wrappedObject the {@code Object} to which method invocations
> * should be delegated
> * @param contextClassLoader the {@code ClassLoader} that should be the
> * current context {@code ClassLoader} within the scope of method
> * invocations on the wrapped object
> */
> public ContextManagingInvocationHandler(Object wrappedObject,
> ClassLoader contextClassLoader) {
> this.contextClassLoader = contextClassLoader;
> this.wrappedObject = wrappedObject;
> }
>
> /**
> * {@inheritDoc}. This implementation sets the context ClassLoader to the
> * configured one, delegates to the wrapped object, then restores the
> * context ClassLoader to its value at method entry.
> *
> * @see java.lang.reflect.InvocationHandler#invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
> */
> public Object invoke(@SuppressWarnings("unused") Object proxy,
> Method method, Object[] args) throws Throwable {
> Thread currentThread = Thread.currentThread();
> ClassLoader currentContextClassLoader
> = currentThread.getContextClassLoader();
>
> try {
> currentThread.setContextClassLoader(contextClassLoader);
> return method.invoke(wrappedObject, args);
> } finally {
> currentThread.setContextClassLoader(currentContextClassLoader);
> }
> }
> }
> }
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Mark Thomas wrote:
> John Bollinger wrote:
>> See attached sample code for a class that would support this behavior.
>
> Your attachment didn't make it through. Could you post it in-line?
Sure:
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the "License"); you may not use this file except in compliance with
* the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package example;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
/**
* <p>
* A service class that assists in managing a "context" within an application or
* service. This version provides for creating dynamic proxies around objects
* belonging to a particular context to ensure that those objects' methods are
* invoked in that context.
* </p><p>
* Instances may be created and held on a one-per-context basis, but currently
* there is no harm in having multiple managers for the same context.
* Alternatively, {@code ContextManager}s are lightweight, so they may be created
* at need and released freely. Model usage:<br/>
* <tt><pre>
* ContextManager contextManager = ContextManager.forCurrentContext();
* ...
* void passRequestToForeignContext(RequestInterface request, ForeignContext context) {
* context.handleRequest(
* contextManager.createProxy(request, RequestInterface.class)
* );
* }
* </pre></tt>
* </p>
*
* @author John C. Bollinger
*/
public class ContextManager {
/**
* The context ClassLoader for the context managed by this ContextManager
*/
private final ClassLoader contextClassLoader;
/**
* Initializes a new ContextManager managing the context defined by the
* specified context {@code ClassLoader}
*
* @param contextClassLoader a {@code ClassLoader} representing the context
* to be managed by this {@code ContextManager}
*/
public ContextManager(ClassLoader contextClassLoader) {
this.contextClassLoader = contextClassLoader;
}
/**
* Creates and returns a {@code ContextManger} for the current context
*
* @return a {@code ContextManger} for the current context
*/
public static ContextManager forCurrentContext() {
return new ContextManager(Thread.currentThread().getContextClassLoader());
}
/**
* Creates a dynamic proxy object wrapping the provided object and ensuring
* that all methods of the wrapped object (when invoked via the proxy) see
* the appropriate context ClassLoader for the context managed by this
* {@code ContextManager}. The proxy's class will implement the specified
* interface(s) by delegating every method invocation to the wrapped object,
* setting the context ClassLoader before, and resetting it after.
*
* @param <T> an interface type that the proxy object will implement
* @param object the object to be wrapped by the
* @param iface a Class representing one of the interfaces the proxy's class
* must implement, and defining the formal type of the return value and
* the {@code object} argument
* @param additionalIfaces {@code Class}es representing additional interfaces
* the proxy's class must implement
*
* @return a proxy object wrapping the specified delegate object, and whose
* class implements all the specified interfaces
*/
public <T> T createProxy(T object, Class<T> iface, Class<?>... additionalIfaces) {
Class<?>[] interfaces;
/*
* Could test to see whether the interfaces (iface and additionalIfaces)
* are in fact interfaces (as opposed to normal classes). Haven't tested
* what happens if they are non-interface classes, but probably Proxy
* will fail to create the proxy object.
*
* Could also test whether they are null.
*/
if (additionalIfaces != null) {
/*
* Set up the full list of interface classes the proxy will implement.
* iface comes first, then any additionalIfaces elements, in order.
*/
/*
* Could test the additional interfaces here to make sure the
* submitted object can successfully be cast to each type. If the
* object's class does not implement one of the interfaces then
* runtime failures will occur when those interfaces' methods are
* invoked on the proxy.
*/
interfaces = new Class[1 + additionalIfaces.length];
interfaces[0] = iface;
System.arraycopy(additionalIfaces, 0, interfaces, 1, additionalIfaces.length);
} else {
interfaces = new Class[] {iface};
}
return iface.cast(Proxy.newProxyInstance(contextClassLoader, interfaces,
new ContextManagingInvocationHandler(object, contextClassLoader)));
}
/**
* An InvocationHandler wrapping a specified object and serving to present a
* given context ClassLoader to that object on all method invocations.
*
* @author John C. Bollinger
*/
private static class ContextManagingInvocationHandler implements InvocationHandler {
/*
* This class doesn't really need to be nested. This version is nested
* mainly for packaging purposes.
*/
/**
* The ClassLoader to set as the current context ClassLoader when
* delegating method invocations to the {@link #wrappedObject}
*/
private final ClassLoader contextClassLoader;
/**
* The object to which all method invocations are delegated
*/
private final Object wrappedObject;
/**
* Initializes a new ContextManagingInvocationHandler that delegates
* method invocations to the specified object while ensuring that the
* current context ClassLoader is the specified one within the scope of
* the invocation.
*
* @param wrappedObject the {@code Object} to which method invocations
* should be delegated
* @param contextClassLoader the {@code ClassLoader} that should be the
* current context {@code ClassLoader} within the scope of method
* invocations on the wrapped object
*/
public ContextManagingInvocationHandler(Object wrappedObject,
ClassLoader contextClassLoader) {
this.contextClassLoader = contextClassLoader;
this.wrappedObject = wrappedObject;
}
/**
* {@inheritDoc}. This implementation sets the context ClassLoader to the
* configured one, delegates to the wrapped object, then restores the
* context ClassLoader to its value at method entry.
*
* @see java.lang.reflect.InvocationHandler#invoke(java.lang.Object, java.lang.reflect.Method, java.lang.Object[])
*/
public Object invoke(@SuppressWarnings("unused") Object proxy,
Method method, Object[] args) throws Throwable {
Thread currentThread = Thread.currentThread();
ClassLoader currentContextClassLoader
= currentThread.getContextClassLoader();
try {
currentThread.setContextClassLoader(contextClassLoader);
return method.invoke(wrappedObject, args);
} finally {
currentThread.setContextClassLoader(currentContextClassLoader);
}
}
}
}
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Mark Thomas <ma...@apache.org>.
John Bollinger wrote:
> See attached sample code for a class that would support this behavior.
Your attachment didn't make it through. Could you post it in-line?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by John Bollinger <th...@yahoo.com>.
Mark Thomas wrote:
> Ate Douma wrote:
> > When Pluto needs to "aggregate" the content of this TestPortlet, it
> > invokes it render(PortletRequest, PortletResponse) method using a
> > "cross-context" call from the Pluto web application to the "test" web
> > application.
> > The TestPortlet.render method receives the PortletRequest object (as
> > loaded from the Pluto WEB-INF/lib) and invokes its
> > PortletRequest.getPortletPreferences() method. If the PortletPreferences
> > class hasn't been accessed yet before, this will cause the ClassLoader
> > of PortletRequest, being the Pluto webapp ClassLoader, to now load the
> > PortletPreferences class.
> > But, because the current ContextClassLoader is the "test" webapp
> > ClassLoader, LogFactory will lookup the logger implementation from the
> > "test" webapp...
> > With as result that logging output for the PortletPreferences class will
> > end up in the target as specified by the "test" webapp, not in the one
> > (as expected) as configured for the Pluto webapp.
So, basically, the PortletRequest needs to see the ClassLoader for the context
in which it was created, rather than the one for the context in which it is used?
I think this can be achieved without changing the behavior of LogFactory, and
in a way that provides the same benefit to any other classes that depend on
the context ClassLoader to find resources. (See below and attached.)
> I have seen similar issues in Tomcat's internal logging with
> java.util.logging, log4j and commons-logging. Why will this be any
> different with slf4j?
>
> > The only possible workaround I could come up with was extending
> > LogFactory itself and temporarily switching/enforcing the current
> > ContextClassLoader to that of the class itself, but obviously we didn't
> > even consider that as a real option.
>
> In Tomcat, the issue was (mainly) log objects for internal components
> being created and loaded by a web application class loader. This was a
> particular issue for Jasper, the JSP engine, as it interacts quite
> closely with web apps. We solved this by ensuring that the logs were
> created during Tomcat start.
I think the case of the server's internal classes is a bit different from the
cross-context case, in part because the a web application's (portlet
application's) expectations of its environment are largely defined by the
servlet (and portlet) spec, whereas the server's internal classes are
whatever the server needs. That doesn't necessarily mean they need
different solutions, but there are some solutions that are viable for the server
that the server may not be reasonably demand of webapps.
I think there is a better solution for cross-context, which may also have some
use for internal server classes: instead of subclassing LogFactory or any
class of an external component, wrap the servlet / portlet spec objects
in dynamic proxies that manage the context switch on method invocation
and return. As long as the wrapped objects are specified by Java interfaces,
the java.lang.reflect.Proxy class makes this pretty easy -- you don't even
need different methods or classes to handle it for different interfaces. As long
as the cross-context invocation is mediated by the server, web / portlet
applications would not need to do anything special -- the server could ensure
that the objects belonging to one webapp would always see the appropriate
context classloader for that context.
See attached sample code for a class that would support this behavior.
John
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ate Douma <at...@douma.nu>.
Mark Thomas wrote:
> Ate Douma wrote:
>> Mark Thomas wrote:
>>> I have seen similar issues in Tomcat's internal logging with
>>> java.util.logging, log4j and commons-logging. Why will this be any
>>> different with slf4j?
>> Because sfl4j does not use the ContextClassLoader to determine the
>> logger instance but compile-time binding.
>> Exactly the reason why CL doesn't work and slf4j does.
>> I think using slf4j for Tomcat internal logging would solve this too.
>
> I still don't get how slf4j solves all of the web app container logging
> issues. I might have to download slf4j and try a few things out.
> In the meantime consider this:
>
> Two web applications both using slf4j with java.util.logging and both
> using a third party library that has a logger called "MyLogger".
>
> When web app one uses the library, slf4j will return - via a call to
> j.u.l.getLogger() - a new logger called MyLogger. When web app two uses
> the library it will get the same logger instance as web app one. This
> type of behaviour is often at the root of permgen memory leaks.
If these libraries (slf4j + third party library) both are *separately* within the WEB-INF/lib of their own webapp as you replied in a later
message, *and* the webcontainer uses PARENT_LAST classloading policy (as standard by Tomcat), effectively you'll end up with two separate
instances of MyLogger (as being loaded by different classloaders) and all should be fine, at least when using log4j.
How a global JUL configuration will work out in this case I don't know for sure because, to be honest, I always do my best to stay far away
from using JUL.
>
> Remy had to write a new LogManager for j.u.l to work around this.
>
> If you use slf4j/log4j with your webapp you should not see this issue as
> the logger repository would be at the webapp level rather than globally
> as it is with j.u.l.
Right :)
> That said, I'd still be worried about cross-context
> calls and webapps getting instances of loggers loaded by other webapps
> and would want to do some very careful testing.
When using slf4j+log4j and PARENT_LAST webapp classloader policy as is the servlet spec recommendation (I won't say requirement because some
people/companies disagree, but *I* think that is the only sensible configuration and interpretation of the spec), you should not need to worry.
Regards,
Ate
>
> I freely admit this stuff makes my head hurt every time I have to try
> and figure out one of these bugs. If slf4j solves all of these issues
> I'd really like to understand how.
>
> Mark
>
>
> ---------------------------------------------------------------------
> 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: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Mark Thomas <ma...@apache.org>.
Ceki Gulcu wrote:
> Mark Thomas wrote:
>>
>> Sorry if I wasn't clear. I intended that the slf4j jars and the third
>> party jars were all in WEB-INF/lib
>>
>> My concern in this scenario is more that this j.u.l, as part of the JRE,
>> will be loaded by the System class loader and hence loggers are
>> registered JVM wide rather than per webapp. Does slf4j provide a way
>> around this issue?
>
> Thank you for your response. Actually, I am unable to understand what
> the issue is. So I can't answer whether SLF4J would be helpful or
> not. In principle, SLF4J does not provide any mechanism whatsoever to
> get around class loading issues. It only follows a two step recipe: 1)
> attempt to load a class named StaticLoggerBinder which ships within
> each slf4j binding 2) Each binding in turn will try to bind with a
> specific logging framework. It's a very dumb and rather inelegant
> approach which I would not recommend except in the context of
> logging. SLF4J does not use class loaders directly.
>
> Anyway, while I understand that j.u.l. classes are part of the JRE, I
> don't see what difference it makes in this scenario.
Just that the root cause of the particular issue I described (which has
moved away from the subject line a little) is the way j.u.l registers
logging. I was curious if slf4j did anything to workaround the issues
that presents.
Thanks for the clarification.
I think I need to go away and test slf4j with the various logger
framework / classloader issues I have seen over the years and see if any
of them remain. Now I just need to find the time to do it :)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ceki Gulcu <ce...@qos.ch>.
Mark Thomas wrote:
>
> Sorry if I wasn't clear. I intended that the slf4j jars and the third
> party jars were all in WEB-INF/lib
>
> My concern in this scenario is more that this j.u.l, as part of the JRE,
> will be loaded by the System class loader and hence loggers are
> registered JVM wide rather than per webapp. Does slf4j provide a way
> around this issue?
Thank you for your response. Actually, I am unable to understand what
the issue is. So I can't answer whether SLF4J would be helpful or
not. In principle, SLF4J does not provide any mechanism whatsoever to
get around class loading issues. It only follows a two step recipe: 1)
attempt to load a class named StaticLoggerBinder which ships within
each slf4j binding 2) Each binding in turn will try to bind with a
specific logging framework. It's a very dumb and rather inelegant
approach which I would not recommend except in the context of
logging. SLF4J does not use class loaders directly.
Anyway, while I understand that j.u.l. classes are part of the JRE, I
don't see what difference it makes in this scenario.
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Mark Thomas <ma...@apache.org>.
Ceki Gulcu wrote:
>
>
> Mark Thomas wrote:
>>
>> Two web applications both using slf4j with java.util.logging and both
>> using a third party library that has a logger called "MyLogger".
>>
>> When web app one uses the library, slf4j will return - via a call to
>> j.u.l.getLogger() - a new logger called MyLogger. When web app two uses
>> the library it will get the same logger instance as web app one. This
>> type of behaviour is often at the root of permgen memory leaks.
>
> Where is the 3rd party library located on the class path? Is the 3rd
> party library loaded by a shared/common class loader, parent of the
> web-app class loaders?
Sorry if I wasn't clear. I intended that the slf4j jars and the third
party jars were all in WEB-INF/lib
My concern in this scenario is more that this j.u.l, as part of the JRE,
will be loaded by the System class loader and hence loggers are
registered JVM wide rather than per webapp. Does slf4j provide a way
around this issue?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ceki Gulcu <ce...@qos.ch>.
Mark Thomas wrote:
>
> Two web applications both using slf4j with java.util.logging and both
> using a third party library that has a logger called "MyLogger".
>
> When web app one uses the library, slf4j will return - via a call to
> j.u.l.getLogger() - a new logger called MyLogger. When web app two uses
> the library it will get the same logger instance as web app one. This
> type of behaviour is often at the root of permgen memory leaks.
Where is the 3rd party library located on the class path? Is the 3rd party
library loaded by a shared/common class loader, parent of the web-app class loaders?
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Mark Thomas <ma...@apache.org>.
Ate Douma wrote:
> Mark Thomas wrote:
>> I have seen similar issues in Tomcat's internal logging with
>> java.util.logging, log4j and commons-logging. Why will this be any
>> different with slf4j?
> Because sfl4j does not use the ContextClassLoader to determine the
> logger instance but compile-time binding.
> Exactly the reason why CL doesn't work and slf4j does.
> I think using slf4j for Tomcat internal logging would solve this too.
I still don't get how slf4j solves all of the web app container logging
issues. I might have to download slf4j and try a few things out.
In the meantime consider this:
Two web applications both using slf4j with java.util.logging and both
using a third party library that has a logger called "MyLogger".
When web app one uses the library, slf4j will return - via a call to
j.u.l.getLogger() - a new logger called MyLogger. When web app two uses
the library it will get the same logger instance as web app one. This
type of behaviour is often at the root of permgen memory leaks.
Remy had to write a new LogManager for j.u.l to work around this.
If you use slf4j/log4j with your webapp you should not see this issue as
the logger repository would be at the webapp level rather than globally
as it is with j.u.l. That said, I'd still be worried about cross-context
calls and webapps getting instances of loggers loaded by other webapps
and would want to do some very careful testing.
I freely admit this stuff makes my head hurt every time I have to try
and figure out one of these bugs. If slf4j solves all of these issues
I'd really like to understand how.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ate Douma <at...@douma.nu>.
Mark Thomas wrote:
> Ate Douma wrote:
>> When Pluto needs to "aggregate" the content of this TestPortlet, it
>> invokes it render(PortletRequest, PortletResponse) method using a
>> "cross-context" call from the Pluto web application to the "test" web
>> application.
>> The TestPortlet.render method receives the PortletRequest object (as
>> loaded from the Pluto WEB-INF/lib) and invokes its
>> PortletRequest.getPortletPreferences() method. If the PortletPreferences
>> class hasn't been accessed yet before, this will cause the ClassLoader
>> of PortletRequest, being the Pluto webapp ClassLoader, to now load the
>> PortletPreferences class.
>> But, because the current ContextClassLoader is the "test" webapp
>> ClassLoader, LogFactory will lookup the logger implementation from the
>> "test" webapp...
>> With as result that logging output for the PortletPreferences class will
>> end up in the target as specified by the "test" webapp, not in the one
>> (as expected) as configured for the Pluto webapp.
>
> I have seen similar issues in Tomcat's internal logging with
> java.util.logging, log4j and commons-logging. Why will this be any
> different with slf4j?
Because sfl4j does not use the ContextClassLoader to determine the logger instance but compile-time binding.
Exactly the reason why CL doesn't work and slf4j does.
I think using slf4j for Tomcat internal logging would solve this too.
>
>> The only possible workaround I could come up with was extending
>> LogFactory itself and temporarily switching/enforcing the current
>> ContextClassLoader to that of the class itself, but obviously we didn't
>> even consider that as a real option.
>
> In Tomcat, the issue was (mainly) log objects for internal components
> being created and loaded by a web application class loader. This was a
> particular issue for Jasper, the JSP engine, as it interacts quite
> closely with web apps. We solved this by ensuring that the logs were
> created during Tomcat start.
Sure, that will work *if* you manage to prime/pre-load all loggers upfront.
For a webserver that might be doable (for its internal libraries), but for an embeddable component like a portletcontainer and definitely
for a highly configurable and extendable portal like Jetspeed that would put too much runtime overhead and an indeterminable configuration
nightmare for the end users/integrators.
>
> Would a similar solution not work for Pluto? Use a
> ServletContextListener to create your log instances when the portlet
> container web appilcation starts?
And start scanning and preloading all classes from WEB-INF/classes and WEB-INF/lib?
Replacing CL with slf4j is by far a more transparent and easier solution than that.
Ate
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> 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: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Mark Thomas <ma...@apache.org>.
Ate Douma wrote:
> When Pluto needs to "aggregate" the content of this TestPortlet, it
> invokes it render(PortletRequest, PortletResponse) method using a
> "cross-context" call from the Pluto web application to the "test" web
> application.
> The TestPortlet.render method receives the PortletRequest object (as
> loaded from the Pluto WEB-INF/lib) and invokes its
> PortletRequest.getPortletPreferences() method. If the PortletPreferences
> class hasn't been accessed yet before, this will cause the ClassLoader
> of PortletRequest, being the Pluto webapp ClassLoader, to now load the
> PortletPreferences class.
> But, because the current ContextClassLoader is the "test" webapp
> ClassLoader, LogFactory will lookup the logger implementation from the
> "test" webapp...
> With as result that logging output for the PortletPreferences class will
> end up in the target as specified by the "test" webapp, not in the one
> (as expected) as configured for the Pluto webapp.
I have seen similar issues in Tomcat's internal logging with
java.util.logging, log4j and commons-logging. Why will this be any
different with slf4j?
> The only possible workaround I could come up with was extending
> LogFactory itself and temporarily switching/enforcing the current
> ContextClassLoader to that of the class itself, but obviously we didn't
> even consider that as a real option.
In Tomcat, the issue was (mainly) log objects for internal components
being created and loaded by a web application class loader. This was a
particular issue for Jasper, the JSP engine, as it interacts quite
closely with web apps. We solved this by ensuring that the logs were
created during Tomcat start.
Would a similar solution not work for Pluto? Use a
ServletContextListener to create your log instances when the portlet
container web appilcation starts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication
invocation usage - migrating to slf4j?
Posted by Ate Douma <at...@douma.nu>.
Hi all,
Thanks to Dennis for bringing this to my attention :)
Sorry for chiming in so late but I wasn't subscribed to the list and unaware of the discussion going on about our migration to slf4j at
Pluto, Jetspeed-2, and in time probably all our Apache Portals projects.
I just read through the whole of this thread and noticed a lot of speculation and misinterpretation of the real reason why we choose to
migrate away from CL.
Let me first try to describe in a nutshell what IMO is the core of our problem with CL.
Consider class A and B, where A has a usage/reference to class B.
Class B has a statically defined CL Log, e.g. like: private static final Log log = LogFactory.getLog(B.class);
Class A is being invoked, such that class B is pulled into usage for the first time.
The ClassLoader of class A will be used to load class B, and because of the static Log definition, the same ClassLoader will be used for
accessing and invoking LogFactory.getLog().
Then, LogFactory will determine the actual logger implementation using the current ContextClassLoader. If *within* that ContextClassLoader a
commons-logging.properties resource is defined, it will use it to lookup the implementation class and then load that class also using the
ContextClassLoader.
The common use-case here is that the ContextClassLoader and the Classloader of class A/B are actually the same, so everything goes as
expected and the loaded logging configuration will match the intended usage of the developer defining it.
However, if the ContextClassLoader is *not* the same as the ClassLoader of class A/B, this all breaks down terribly.
To make this concrete, I'll describe the actually issue as I encountered it with Pluto (albeit a little bit simplified/abbreviated).
The portletcontainer (jar), which resides within the WEB-INF/lib of the Pluto web application, contains the classes PortletRequest (A) and
PortletPreferences (B), with PortletPreferences defining a private static Log log = LogFactory.getLog(PortletPreferences.class).
A different web application, e.g. a portlet application "test" also uses CL, and provides a class TestPortlet within its own WEB-INF/classes.
When Pluto needs to "aggregate" the content of this TestPortlet, it invokes it render(PortletRequest, PortletResponse) method using a
"cross-context" call from the Pluto web application to the "test" web application.
The TestPortlet.render method receives the PortletRequest object (as loaded from the Pluto WEB-INF/lib) and invokes its
PortletRequest.getPortletPreferences() method. If the PortletPreferences class hasn't been accessed yet before, this will cause the
ClassLoader of PortletRequest, being the Pluto webapp ClassLoader, to now load the PortletPreferences class.
But, because the current ContextClassLoader is the "test" webapp ClassLoader, LogFactory will lookup the logger implementation from the
"test" webapp...
With as result that logging output for the PortletPreferences class will end up in the target as specified by the "test" webapp, not in the
one (as expected) as configured for the Pluto webapp.
As should hopefully be clear from the above, this problem really has *nothing* to do with the Portlet spec in itself, or how Pluto is
implementing it.
IMO, the "natural" and expected result of a static initialization like a Log definition is that its configuration and behavior is tied to
the class defining it, for which it should (by default) use the same ClassLoader.
Any application using multiple ClassLoaders can be "hit" by this same issue, and although portals *by nature* rely heavily upon
"cross-context" web/portlet application interaction (which actually is described in the portlet spec), that is not limited to portals only.
Although not a formal servlet spec feature, all Java web servers support cross-context web application invocation nowadays and already long
before the portlet spec was defined. And it is used for far more purposes than portals only.
The only possible workaround I could come up with was extending LogFactory itself and temporarily switching/enforcing the current
ContextClassLoader to that of the class itself, but obviously we didn't even consider that as a real option.
I hope the above now better explains why we had to migrate away from CL.
If not, I'll be happy to further elaborate on this of course.
With kind regards,
Ate
Ralph Goers wrote:
> FWIW - I subscribe to this list so I saw the message but have not
> participated in the discussion.
>
> This just adds to my concern with respect to what to do with commons
> logging.
>
> Ralph
>
> Begin forwarded message:
>
>> From: Eric Dalquist <er...@doit.wisc.edu>
>> Date: April 20, 2009 1:47:42 PM PDT
>> To: pluto-dev@portals.apache.org
>> Subject: Re: commons-logging unsuited for cross-context webapplication
>> invocation usage - migrating to slf4j?
>> Reply-To: pluto-dev@portals.apache.org
>> Reply-To: pluto-dev@portals.apache.org
>>
>> +1 to SLF4J several Jasig projects are also looking at it as an
>> alternative to JCL.
>>
>> -Eric
>>
>> Ate Douma wrote:
>>> Pluto community,
>>>
>>> I'd like to ask your intention for issue PLUTO-553:
>>>
>>> http://issues.apache.org/jira/browse/PLUTO-553
>>>
>>> Detailed information about this blocking issue can be found at above
>>> JIRA page.
>>> As I have described there, if nobody objects I intend to commit the
>>> migration to sfl4j soon.
>>> Any comments/feedback of further discussion is of course welcome.
>>>
>>> Regards,
>>>
>>> Ate
>
>
---------------------------------------------------------------------
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
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 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 20, 2009, at 11:41 PM, Jörg Schaible wrote:
>
> Ralph Goers wrote at Dienstag, 21. April 2009 01:03:
>
>> FWIW - I subscribe to this list so I saw the message but have not
>> participated in the discussion.
>
> Actually it would be nice if people would report problems in first
> place.
>
>> This just adds to my concern with respect to what to do with commons
>> logging.
>
> As I said earlier, choosing SLF4J in a solution might be
> appropriate, but
> not for small components that should be used everywhere. Pluto will
> have to
> deal with a lot of components using CL and must adjust dependencies,
> but
> that's their choice. And with those components using CL they
> actually have
> the choice - this is for me the important part.
>
I don't understand your reply. What is it that you think is so
different between SLF4J and Commons Logging? SLF4J is just as
appropriate to use with small components as Commosn Logging is. They
are both adapters that require you to choose a logging implementation.
They both allow the implementation to be chosen when you package your
application - without recompliling anything.
So why do you think Commons Logging gives you more choices than SLF4J
does?
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: Fwd: commons-logging unsuited for cross-context webapplication invocation usage - migrating to slf4j?
Posted by Jörg Schaible <jo...@gmx.de>.
Ralph Goers wrote at Dienstag, 21. April 2009 01:03:
> FWIW - I subscribe to this list so I saw the message but have not
> participated in the discussion.
Actually it would be nice if people would report problems in first place.
> This just adds to my concern with respect to what to do with commons
> logging.
As I said earlier, choosing SLF4J in a solution might be appropriate, but
not for small components that should be used everywhere. Pluto will have to
deal with a lot of components using CL and must adjust dependencies, but
that's their choice. And with those components using CL they actually have
the choice - this is for me the important part.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org