There seems to be three ways in WSAD to make sure an application has all the class files it needs: 1) A Jar file can be added to the "Java Build Path" by right-clicking on a Web application and choosing properties. 2) The enterprise application's deployment descriptor (application.xml) can be modified using the deployment descriptor editor, adding a "project utility Jar" file to the enterprise project. 3) The Server Configuration can be modified using the Server Configuration editor, adding the Jar file to the classpath. Which approach should I use? What is the difference between a "build path" and a "class path"?
Rick, 1) The build path is a normal classpath for java projects. If the project is in an ear, the build path is a compile time type classpath. 2) The deployment descriptor is used as a runtime type classpath for ejb projects. So if a class is needed when generating the deployed code, it should be in this descriptor. 3) The server configuration is a server classpath. I would avoid #3 if at all possible. Note that anything put in this classpath, needs to be put on the "real" application server classpath. To me this is a recipe to forget something. Between #1 and #2, think about whether the class is needed to compile or just run. If there is any doubt, use #2. Anything added to #2 is automatically added to #1. Also, note that you can add a java project to #1, but not to #2.
Hi Rick, Personally, I think: #3 will not be used anyway unless you need to install packs for the WHOLE server (such as bug fix, etc), becos it is mainly for the server, and affects ALL applications developped. #1 is mainly for compilation, which means the classpath is used for compiling your codes, thus, any external JAR files that needed by your project should be put in that. In addition, different projects may need different JAR files. E.g. javac -classpath ... XXX.java #2 is mainly for deployment and execution, which means the classpath is used for running your application. The application server will search all of them from DD, and load it into the memory during the startup. If some of the beans, or JNDI names cannot be resolved, exceptions will be thrown at that moment. E.g. java -classpath ... XXX (no c) I hope this makes you more clear on the 3 items. Nick.
#3 is not advisable because it makes your app unportable in the end. One option you missed is what I think is the best option if you are using code from your environment. Create a Web Library for your project. Go to Window->Web Library->add->browse and then select the project you want to put into the classpath. Then give it a name and apply. This will put the stuff from the project you selected into a virtual jar file in your projects WEB-INF/lib directory. This way when you change the library it will take effect in the Web App also. Also when you export your .ear file it will automatically jar up the library and place it into the lib directory. For other utility jar files that are static, I like to put in the WEB-INF/lib directory. Putting stuff at the ear level is OK if multiple applications are using the jar file but other than that they should go into the WEB-INF/lib of your wars. See the 'Where should utility classes go' section int this Tim deBoer article. [ January 21, 2004: Message edited by: William Duncan ]
No more rhymes! I mean it!<br /> <br />Does anybody want a peanut?
Let me clear up some confusions here. First, I agree that you should not use #3 because that needs to be configured at the server layer. I am a firm believer of getting the classpaths correct within the EAR first. Now on to the other two suggests. When you deal with J2EE modules (i.e., J2EE projects within WSAD) you should rarely ever use the Java Build path to update your compile-time classpath. The reason is that this is only a compile-time classpath and not a runtime classpath. The runtime classpath is managed by the MANIFEST.MF file within each J2EE project. Your #2 suggestion is just a way to add module projects and utility JARs to an Application project. By the way, I would not use the zip creation tool in Tim Deboer's article above because in version 5.0 we added the ability to map a utility JAR to an actual Java project within the workbench. When the Application is exported, the contents of the Java project will be put into a JAR and added to the EAR. Now back to updating the classpath for a J2EE project. You will want to use the Java JAR Dependencies editor or property page. The editor can be opened using the Open With context menu in the J2EE Hierarchy view for a given root EJB JAR, Web Application, Application Client, or Connector module object. You can also double click on the MANIFEST.MF file or open the properties page for the project or the root object. The Java JAR Dependencies editor/property page will show you the available modules or utility JARs that are avaible in the Application project. When you select the JARs and/or modules that you want to reference, the MANIFEST.MF classpath entries are updated as well as the Java Build path for your project. So, in the end, your compile-time classpath and runtime classpath are both updated corrected. Hope this helps to clear up some confusions. I am working with another developer to provide a more detailed paper on WebSphere Developer Domain that talks about this issue as well as proper Application structuring within WebSphere Studio.
author & internet detective
By the way, I would not use the zip creation tool in Tim Deboer's article above because in version 5.0 we added the ability to map a utility JAR to an actual Java project within the workbench. When the Application is exported, the contents of the Java project will be put into a JAR and added to the EAR.
Does this keep the java project/jar in synch all the time or just when you build the EAR? In other words, if I make a change to the java project, does the EJB project pick it up automatically?