Community
Participate
Working Groups
Import attached project, deploy them into one web project, then run it on tomcat 6, click the button and you will get "EGL0024E: An exception occurred during a service call. Service:server.TestService, Function:server.TestService ", but if you change service binding to workspace, it will work well in VE.
Created attachment 207517 [details] sample
Joe, can you review this one and determine a priority for the .7 release?
The Service calls an external type which wraps up a java class located in a jar in <Project ExternalJava>/lib/MyExternal.jar This jar does not get deployed to the target web project. Thus target web project contains compilation errors in the service's generated java files, and will not run correctly. I copied the jar to the target project's WebContent\lib and it worked. Neither does RBD copy the jars to the target deployment. It might be an enhancement to make our deployer aware of all the java resource in the class path. But this looks low priority to me. A developer knows how to use Java external types and jars are likely to know how to deploy the custom java code to the target project. I would suggest defer this.
Add some info, deploy the projects into a web project called "targetTest9", then run H1.html in tomcat 6.
Marking this as Future for now. I will let Joe add more details about why this jar file is not being copied by default, and then we can determine if this is a defect, an enhancement, or should be closed as working as designed.
Does a jar sitting in the EGL project being deployed get copied into the target project?
Tony is correct in RBD we do not copy any jar files. The reason is there are many ways to add a jar to the classpath besides adding it to the WebContent/lib. Jars could be in a common folder on the server and the war is updated to point to the jar, or if the application is using an EAR the jar could be in the EAR classpath, or the jar could be in the server or the actual system classpath, and I bet there are other ways to add it to the classpath. Let's take 3 examples: 1. I have a jar that contains code that is common to an application and the application is made up of multiple war files. In this case the jar belongs in the EAR classpath. 2. You have multiple server instances and all of your applications on a server instance use the same database driver jars, the jars can go in the server classpath. 3. You have multiple server instances and all server instances use the same database driver jars the jars can go in the system classpath. Whoever implements this enhancement will have to investigate the J2EE deployment/classloader structure (is this the same for all servers?).
I think our first goal should be to make the app work after it is deployed, and that means copying required jars into the deployed project (we already copy jars referenced by the database connection, right?). For advanced users, in the future we could offer an option (in the DD) to control which (if any) jars get deployed, like how we allow the developer to restrict which resources (WebContent) are deployed into the target project. I think our goal, in general, should be to make things clean/simple for the basic scenarios, but give advanced users the ability to alter the behavior (e.g. not copy jars into the target project) for advanced scenarios. This philosophy should apply throughout EDT, not just on this particular issue ...
