I have a question regarding EJBs, EARs and dependant resources in WSAD 5.1. It seems when deploying EARs, sometimes I can have an EJB WSAD project reference a jar file and it deploys ok, but in one particular case I have the bean reference a jar file and it will not deploy.
This is my situation:
I have an WSAD EJB project called MyEJBProject. This has a dependency on a very simple jar file of my own creation, called aaa.jar. By adding aaa.jar to the build path of MyEJBProject, I can compile MyEJBProject without error, add it to my EAR project and can deploy and run it succesfully. (Note: I am assuming that becuase MyEJBProject has a dependancy on aaa.jar, then aaa.jar is added to the ear and deployed.)
I now want to add Logging support to MyEJBProject, so I add a reference in MYEJBProject's build path to log4j-1.2.4.jar (a jar shipped with WSAD 5.1). I can now add logging support to MyEJBProject, but when I try to deploy the EAR, I get a ClassNotFound exception.
However, if instead of adding the jar to MyEJBProject, I add the jar to the EARProject and I place a dependancy in MyEJBProject to that jar, then it works and can be deployed succesfully. This allows me to continue working, although I am not entirely happy as it raises the following questions:
Why does one method work for aaa.jar and not for log4j-1.2.4.jar?
Should all of my dependant jar files be placed in the EAR? Is this the way I should be coding? My overall project consists of many WSAD Projects with lots of dependant jars. It seems strange to just lump everything into the EAR and work from that.
Any help anyone can shed on any of this will be greatly appreciated. Thanks, David
When you placed your log4j.jar in the MyEJBProject, did you try to use the logging in any classes outside the MyEJBProject, like for eg. in any servlet/filter/class residing in the MyWEBProject??
No I didn't. I would not have been able to get the classes to compile anyway, if the jar was not available.
as long as you have ur log4j.jar in any project , u can use logging only within that project. If you want application level use of a particular jar, then you have to place it in the EAR
Like I say, the jar fails on deployment with logging, when logging is used in MyEJBProject - where the logging jar is declared! Logging is not used in any other WSAD Project.
"Application level use" is an interesting phrase that you use, and a phrase that I am unfamiliar with. What exactly does it mean? However, since I can get the aaa.jar file to work and not the logging jar, I suspect that there is something special about the logging jar or logging in general.
Joined: Dec 06, 2004
I believe my problem is a class-path one! WSAD comes bundled with its own Logger (JRAS). So I'm guessing that the JRAS logger is being referenced before my log4j logger.
Although I am explicitly declaring my Logger as "org.apache.log4j.Logger" it's the failure to find the "Category" class that is the problem...
Although that should be on the classpath (within the log4j jar file)!!!
How are you creating a dependency on aaa.jar? Do you (1) add it to the 'Java Build Path' (2) add it to the 'Java JAR Dependencies' (3) add it to the 'Web Library Projects' (4) all of the above?
I have a utility 'Java Project' which I would like to jar and use in a couple of of 'Web Project's. I've added it to the Web Projects' 'Web Library Projects', and everything builds/runs fine in WSAD. I'm not sure how to export these projects to WAS.
I could bundle up my n Web Projects and 1 Java Project in a EAR and deploy that. However, if multiple developers are working on projects dependent on that 1 Java utility jar, we would have to coordinate our EAR deployment, which is annoying during iterative development/qa cycles.
We're also using Log4J for logging. We added log4j-1.2.8.jar to the 'Java Build Path' of our Web Projects. However, we found that if multiple Web Projects used Log4J, the configs of the one loaded first by WAS was used by all the other projects.
Finally, I believe Murtaza's term "application level use" means all the projects within an EAR.