Community
Participate
Working Groups
Steps to reproduce: 1. Create an EAR 1.4 project. 2. Call the EJB project wizard. 2.1. Set the EJB module version to 2.1. 2.2. Set the configuration to "EJB Project with XDoclet". 2.3. Check "Add project to an EAR". 2.4. Refer the EAR 1.4 project in the "EAR Project Name" field. 2.5. Finish the wizard. The EJB project is created with Java facet version 1.4, while the EJB Client project is created with Java facet version 6.0 (the latest available). The problem caused is that if the EAR is deployed on a server that runs with JDK version lower than 1.6, then the deployment fails with UnsupportedClassVersionException, because the java classes in the EJB Client project are compiled with 1.6 compatibility. The generated EJB Client project should have a Java facet that follows the version EJB host project's Java facet.
Does this only happen if the EJB project does not target a runtime? If the EJB project targets a runtime, then that target runtime should carry over to the EJB Client project, where the runtime's default facets should appropriately configure the java facet version. In absence of runtime, the default java facet version is set based on the version of the VM running Eclipse.
Thanks for the comments, Konstantin! It happens in both cases - when a runtime is targeted and when not. I am still wondering if this is a problem in WTP code, or it should be left to server runtime to handle it completely. However, I wonder if a server runtime could check the JVM version, which the server instance runs with? I think not, at least because a server instance may not be created yet. In this case, if I know that my server runs with JVM 1.5 and I set the Java facet version to 5.0 in the EJB project wizard, I would like to have the Java facet version in EJB Client project set again to 5.0, not to 6.0.
I just tried it and I am seeing the java facet version of the EJBClient project correctly set based on the target runtime. In my setup, Eclipse was started with Java 6 (this makes version 6.0 be default version if runtime is not specified). I defined WLS 10.0 runtime, which happens to require Java 5. If I create an EJB project with a client and specify WLS 10.0 during EJB project creation, the client is created targeting that runtime with Java 5 facet installed. If I do not select a runtime when creating EJB project, the EJBClient is created with the default Java 6 facet version. I believe this scenario is working correctly and consistently with other parts of WTP. Even if user intentionally lowers EJB project's java version to a level lower than the highest supported by the runtime, it is not clear that the same should be done on the client project. In fact, trying to do that will interfere with the default facets facility that runtime vendors use to specify additional facets that should be selected by default when a project is created. Consider the case where the additional facets require the default version of the java facet. In general, we rely on the runtime to accurately model the facilities of the server (including the jvm version). If runtime allows the condition where the jre specified in runtime is different than what's actually used by the server, then that's a validation problem for the runtime vendor. For instance, in the case of WLS, we don't even allow the user to specify a JRE when defining a WLS runtime. Instead, we detect the actual JRE that the server installation is configured to use and make the runtime refer to it.
Thanks for all the clarifications, Konstantin! This seems to be an issue that runtimes should handle themselves. Therefore, I close this bug as INVALID and will try to broadcast this information in the mailing list and newsgroups.
Closing
