- This topic has 2 replies, 2 voices, and was last updated 18 years, 2 months ago by
.
-
Posts
-
I added spring capabilities to my project which includes the log4j-1.2.13.jar file. After I deploy to jBoss 4.0 server, there is a nasty stack trace indicating that it can’t read the log file. I won’t put the 2-mile long stack trace here but you can read a very similar one in the thread:
http://jboss.org/index.html?module=bb&op=viewtopic&p=3858982
The suggestion in the thread works. If you remove the jar file from your deploy lib directory the server fires up normally (I don’t know yet if it will affect the application). The question is how to prevent this without manually deleting every time the app is deployed.
I would imagine that these conflicts happen all of the time when using the different plugins. How is this normally handled?
Travis
Travis,
Good question… one way would be to remove the Spring user libraries from your build path and instead re-add the JAR’s explicitly one-by-one from their respective plugin location in order to control that the one JAR not be added.I know this is a suboptimal solution and the light at the end of the tunnel is that we are working on deployment filtering for a future release that will allow you to control exactly what gets deployed and what doesn’t. It would be ideal for this situation.
Riyad, no worries…I’m just happy to hear that I’m not messing up the configuration. It actually sounds to me like something that jBoss itself should handle. I should be able to tell my app to use one archive (log4j, for example) and the jBoss AS should be able to use whatever version of the tool as well. The app still logs just fine…it’s just that you don’t get a very warm feeling from the stack trace.
Thanks for the response…
Travis
