My portlet uses a few of the jakarta commons libraries. The one in
question in this case is the Digester project (1.5). However, Digester
is not the problem... it's the commons logging framework (1.0.3) that
causing me headache.

Now, I am not very familiar with the commons logging framework, since my
portlet is using Log4J (1.2.8) for it's logging, but the Digester uses
the commons logging framework so it needs to be in place.

In my portlet I have a file in the WebContent/META-INF/services/
directory named org.apache.commons.logging.LogFactory. It contains the line:
org.apache.commons.logging.impl.Log4jFactory
indicating that the commons logging framework should use Log4J classes
for logging. However, WPS won't have nothing of it and says:

Nested Exception is
org.apache.commons.logging.LogConfigurationException:
java.lang.ClassNotFoundException:
com.ibm.wps.portlets.struts.logging.StrutsLogFactory
at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609)
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561)
at org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:298)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
at org.apache.commons.digester.Digester.<init>(Digester.java:346)

when I try to initialize Digester.

Now, where is com.ibm.wps.portlets.struts.logging.StrutsLogFactory
coming from? This is a simple portlet and isn't using any kind of Struts
references.

I'm using WSAD 5.1.0 with the local portlet envionment for development.
Everything works fine on my machine. It's only when I move the portlet
to the production WPS server that things go wrong.

Any ideas?

Regards
Lee Francis

[ Post a follow-up to this message ]

Hi!

Lee Francis Wilhelmsen wrote:

> My portlet uses a few of the jakarta commons libraries. The one in
> question in this case is the Digester project (1.5). However, Digester
> is not the problem... it's the commons logging framework (1.0.3) that
> causing me headache.
>
> Now, I am not very familiar with the commons logging framework, since my
> portlet is using Log4J (1.2.8) for it's logging, but the Digester uses
> the commons logging framework so it needs to be in place.
>
> In my portlet I have a file in the WebContent/META-INF/services/
> directory named org.apache.commons.logging.LogFactory. It contains the
> line:
>     org.apache.commons.logging.impl.Log4jFactory
> indicating that the commons logging framework should use Log4J classes
> for logging. However, WPS won't have nothing of it and says:
>
> Nested Exception is
> org.apache.commons.logging.LogConfigurationException:
> java.lang.ClassNotFoundException:
> com.ibm.wps.portlets.struts.logging.StrutsLogFactory
>     at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at
> org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561)
>     at
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:298)
>     at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
>     at org.apache.commons.digester.Digester.<init>(Digester.java:346)
>
> when I try to initialize Digester.
>
> Now, where is com.ibm.wps.portlets.struts.logging.StrutsLogFactory
> coming from? This is a simple portlet and isn't using any kind of Struts
> references.

The JAR you're looking for is called "PortalStruts.jar".  Include it in your
app.  On Unix, go to the Portal Server directory and use "find . -name
PortalStruts.jar". I found it for instance in the IBM newsgroup portlet
directory.

There is an IBM article about Commons Logging and WebSphere:
http://www-1.ibm.com/support/docvie...uid=swg27004610

The main problem is that WebSphere ships with a version of Commons Logging
(and contains configuration settings) that typically is loaded before your
application.  So the Commons Logging configuration included in your
application is probably ignored.  The article describes how to fix that.

However, at least in the portal server, there still seem to be problems with
that approach because "something" wants to load the (IBM) StrutsLogFactory.
So you need to include it in your app.  If you ever find out where this
StrutsLogFactory actually logs to - please tell me.  :-)

> I'm using WSAD 5.1.0 with the local portlet envionment for development.
> Everything works fine on my machine. It's only when I move the portlet
> to the production WPS server that things go wrong.
>
> Any ideas?
>
> Regards
> Lee Francis

--
Karsten Silz
Seldon Systems, Inc.
www.seldonsystems.com

"Women often think about what other people think.  Men don't even know that
other people think."
Dave Barry (http://www.davebarry.com)

[ Post a follow-up to this message ]

> The JAR you're looking for is called "PortalStruts.jar".  Include it in
> your app.  On Unix, go to the Portal Server directory and use "find .
> -name PortalStruts.jar". I found it for instance in the IBM newsgroup
> portlet directory.

Well, I'll have to see if I can find it when I get to work.

> There is an IBM article about Commons Logging and WebSphere:
> http://www-1.ibm.com/support/docvie...uid=swg27004610

Yes, I have read this article. It's here that I found out how to include
the org.apache.commons.logging.LogFactory file in the
WebContent/META-INF/services/ directory. However, let me add that
everything worked find up to only a few weeks back. Then my system
administrator wanted to re-install the portal server and after that I've
been getting this wierd struts error. We're using the exact same portal
server version as before. My administrator says that the only thing
different between the reinstalled installation is that he hasn't
installed Lotus Collaborative Components on it.

> The main problem is that WebSphere ships with a version of Commons
> Logging (and contains configuration settings) that typically is loaded
> before your application.  So the Commons Logging configuration included
> in your application is probably ignored.  The article describes how to
> fix that.

Yes, well I believe that using the procedure described above should take
care of this... but it doesn't

> However, at least in the portal server, there still seem to be problems
> with that approach because "something" wants to load the (IBM)
> StrutsLogFactory.   So you need to include it in your app.  If you ever
> find out where this StrutsLogFactory actually logs to - please tell me.
> :-)

I will.

regards
Lee Francis

[ Post a follow-up to this message ]

Hi!

Lee Francis Wilhelmsen wrote: 
>
>
> Well, I'll have to see if I can find it when I get to work.
> 
>
>
> Yes, I have read this article. It's here that I found out how to include
> the org.apache.commons.logging.LogFactory file in the
> WebContent/META-INF/services/ directory. However, let me add that
> everything worked find up to only a few weeks back. Then my system
> administrator wanted to re-install the portal server and after that I've
> been getting this wierd struts error. We're using the exact same portal
> server version as before. My administrator says that the only thing
> different between the reinstalled installation is that he hasn't
> installed Lotus Collaborative Components on it.

That was the same for us: On a plain Portal Express 5.0, we set the
classloader to "PARENT_LAST" - and the Commons Logging JAR & properties used
in our portal app were used.  After a (somewhat failed) upgrade to 5.0.2,
the StrutsLogFactory reared its ugly head so we needed to include the
PortalStruts.jar in our apps.  No idea why...
 
>
>
> Yes, well I believe that using the procedure described above should take
> care of this... but it doesn't
> 
>
>
> I will.

Hope that helps.

> regards
> Lee Francis

--
Karsten Silz
Seldon Systems, Inc.
www.seldonsystems.com

"Women often think about what other people think.  Men don't even know that
other people think."
Dave Barry (http://www.davebarry.com)

[ Post a follow-up to this message ]

Lee Francis Wilhelmsen wrote:

> Nested Exception is
> org.apache.commons.logging.LogConfigurationException:
> java.lang.ClassNotFoundException:
> com.ibm.wps.portlets.struts.logging.StrutsLogFactory
>     at org.apache.commons.logging.LogFactory$2.run(LogFactory.java:609)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at
> org.apache.commons.logging.LogFactory.newFactory(LogFactory.java:561)
>     at
> org.apache.commons.logging.LogFactory.getFactory(LogFactory.java:298)
>     at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:414)
>     at org.apache.commons.digester.Digester.<init>(Digester.java:346)

I'm on to something here.  I wrote a portlet that lets me evaulate
ad-hoc beanshell scripts; I've just saved myself about a day's worth of
coding, compiling, deploying (lather, rinse, repeat).

Some nimrod has set a system property for
org.apache.commons.logging.LogFactory to
com.ibm.wps.portlets.struts.logging.StrutsLogFactory.  That's why
Commons Logging is going for that instead of what we've tried to
configure via the services directory.

I'm opening a PMR with IBM now for this.

I don't think there is a way around this, short of removing the property
from the System properties (kind of draconian, but it takes force to
fight stupidity sometimes...) or modifying JCL to ignore the system
property.

[ Post a follow-up to this message ]

Brian Lalor wrote:
> Some nimrod has set a system property for
> org.apache.commons.logging.LogFactory to
> com.ibm.wps.portlets.struts.logging.StrutsLogFactory.  That's why
> Commons Logging is going for that instead of what we've tried to
> configure via the services directory.

Do you know if this was the case in earlier WPS releases? I can't
understand how it just suddenly popped up....

[ Post a follow-up to this message ]

Lee Francis Wilhelmsen wrote:

> Do you know if this was the case in earlier WPS releases? I can't
> understand how it just suddenly popped up....

I'm seeing it in WPS 5.0 (not 5.0.1 or 5.0.2).  I haven't tested with
any of the 4.x series portal servers.

[ Post a follow-up to this message ]

mransley wrote:
> Or whatever you want it to be.  This problem happens in 5.0.2 and 5.0.2.1.

Have you tested on 5.0.2.2?

[ Post a follow-up to this message ]