I've created a struts application with WSAD 5.1.2 and I want to change the logging level. I've created a commons-logging.properties file, but whatever I specify in this file, it doesn't have any impact.
Does someone have experience with logging in Struts when using WSAD? How can I change the Log implementation commons-logging is using? Because the usual way to do that is not working.
Few days back i was also struggling with tha same problem but now i have resolved the problem. If i am not wrong you must be getting TrLogFactory instead of your implementation LogFactoryImpl.
Read the following steps and you would be able to resolve your issue.
Using the commons-logging.properties File:
The LogFactory.getFactory() method causes the WebSphere Application or WAR classloaders to locate and load the commons-logging.properties file supplied with an application -- before locating that supplied with WebSphere and ultimately returns the application-specific LogFactory implementation. If the classloaders locate the file supplied with WebSphere instead, getFactory() returns the proprietary LogFactory implementation, TrLogFactory.
Because this option mandates changing the WebSphere classloader [delegation] mode to PARENT_LAST, it supports the integration of JCL versions different than that supplied with WebSphere.
To override the WebSpheres JCL LogFactory implementation using the commons-logging.properties file:
1.) Create a commons-logging.properties file and enter the following line:
For example, to use Apache's implementation, enter the line:
2.) Add the commons-logging.properties file to the jar file containing your LogFactory implementation class.
The actual requirement of 2.) is to add the commons-logging.properties file to the application classpath. Inserting the properties file into such a jar is not required, but satisfies the requirement utilizing a standard J2EE application development practice. See section Suggestions for Integrating JCL Artifacts for further ideas.
Note: If the application requires other logging-related classes, such as a different version of JCL, consider placing such artifacts in this jar as well. When adding a different version of JCL, you must ensure that the application provides all dependent JCL classes. If this condition is violated, the WebSphere classloaders will throw an error or exception when loading a dependency class, of the JCL package supplied by WebSphere, that is binary-incompatible to a user-supplied JCL class.
3.) Add this jar to your application EAR. If the application is packaged in a WAR only, insert the jar in the WAR instead (WEB-INF/lib).
Moreover, if your application contains servlets/JSPs and EJBs, put the jar in the EAR so that all server-side application components can utilize the specified JCL LogFactory implementation.
Visit section 17.7.1 of System Management and Configuration Redbook  for directions to package utility JARs into WARs and EARs.
Now we must ensure that the WebSphere classloaders load your JCL classes and properties files before those supplied by WebSphere.
4.) If you added the JAR containing JCL artifacts to the EAR: launch the Admin console, select Applications > Enterprise Applications > my application , and set the "Classloader Mode" to PARENT_LAST. Save your changes!
5.) If you added the JAR containing JCL artifacts to a WAR: launch the Admin console, select Applications > Enterprise Applications > my application > Web Modules > my WAR module, and set the Classloader Mode to PARENT_LAST. Save your changes!
Redeploy and restart application as necessary before executing the application.
Using the commons-logging.properties file for overriding WebSpheres TrLogFactory implementation has certain benefits: assuming an application is packaged as suggested above, then all application-specific JCL artifacts will override those supplied with WebSphere. Also, the solution is guaranteed to affect only the application, not the application server nor its hosted applications; and third, it allows different versions of JCL to integrate on a per-application basis. These benefits derive from the PARENT_LAST WebSphere classloader [delegation] mode, which causes the context classloader to locate the application-specific artifacts first.
Meanwhile I also found this document from IBM describing the problem and some possible solutions:http://www-1.ibm.com/support/docview.wss?uid=swg27004610
But, I tried all of the proposed solutions and nothing is working. I changed the classloader mode to PARENT_LAST, the commons-logging.properties is in place, I created the file org.apache.commons.logging.LogFactory in /META-INF/services/, but it's still using TrLogFactory.
I have no clue what I'm doing wrong. Or could it be that the TrLogFactory implementation changed in WAS 5.1 or WSAD 5.1.2 ?
Since TSS doesn't have file attachment facility so i paste the all steps . nway coming back to your problem it seems that the websphere classloader is not able to read your commons-logging.properties file so package your properties file in jar and put it in Websphere specific classpath(ws.ext.dirs) and classpath entries. Hope that works. You will find these in Environment tab options of wsad.
It works fine now with my WAS test server in WSAD. But like this the problem will still be there when we deploy the application on the production server, because we cannot copy the jar file there and the logging should be configured on application level.
I still don't understand why the WebSphere classloader is not reading my commons-logging.properties file in the application.
But, I can control it now in my development environment. So, I guess I'd better stop worrying about it.