Community
Participate
Working Groups
Currently the J2EE Preview adapter, that ships with WTP, utilizes the embedded Jetty server and makes possible for users to develop and run Web application without the need to install additional J2EE runtime and servers. It would be useful if an EJB container is embedded in the J2EE Preview adapter, too. This will make possible EJB development "out of the box" the same way as web development. There is a suitable embeddable EJB container - OpenEJB - http://openejb.apache.org/. There is a guide how to embed OpenEJB in Tomcat - http://openejb.apache.org/tomcat.html. So, it should be possible to embed it in a similar way in the Jetty web container. In the end the J2EE Preview server adapter should be able to deploy and run WEB, EJB and EAR modules.
I am going to promote this enhancement as a Google Summer of Code 2009 project.
This enhancement was accepted as a project for Google Summer of Code 2009. I assign the bug to the student that will work on it - Marcelo Dias.
Tim, can we put this enhancement in the 3.2 plan? Marcelo did a great work on integrating OpenEJB with Jetty. His work is available here: http://code.google.com/p/embed-openejb-in-eclipse/wiki/Index Now this have to be integrated in the J2EE Preview server adapter. Some of the work is already done in the SVN repository of the GSoC project, but there is still some more polishing needed. I am going to do all the needed implementation and legal efforts in for this enhancement. All needed from you, Tim, is just the approval to do this for WTP 3.2.
From the GSoC site is says this will be complete next week(!). However, I can't find the current status and it is hard to tell how this is/was done by browsing SVN. Are there any design docs or information on the code changes or refactoring that needed to occur? Is Open EJB already included in platform or Orbit like Jetty is, or would this be a new dependency from WTP? It looks like OpenEJB is 25 Mb, which is a lot for a simple preview... do we need all of it, or are there ways to reduce that? This sounds like a great addition to WTP, just want to understand what I'm agreeing to. :)
Tim, the student actually finished his work already - before the last minute deadline. May be you did not noticed the "click here" link at the end of the wiki's index page that will lead you to the next one: http://code.google.com/p/embed-openejb-in-eclipse/wiki/Progress It explains quite well what has been done. OpenEJB is not yet in Eclipse. I will start the legal process once I clarify which of all jars we need for the preview adapter. We definitely don't need the whole OpenEJB stuff. An year ago I have evaluated it as something like 4 mb. Nevertheless, whatever the size is, my goal is to have this mainly for the Eclipse IDE for Java EE Developers distribution. May be we can change the current situation and have no server adapters distributed with the "normal" WTP binaries, but make them all downloadable. But this is another story...
Thanks, didn't see that link. I think this would be a good improvement to WTP. The next step should be determining how much of OpenEJB we'd need, how to package it, and getting IP approval to include it (I'm assuming in Orbit). Even at 4Mb I can see some adopters not wanting this extra size, so we should confirm that the packaging of WTP is appropriate, or look at moving this (and/or other) server adapters to downloadable only. It might also be worth seeing if we can make OpenEJB an optional dependency - that way the preview server works either way, but individual packages or adopters can decide how important this function is to them.
I had some time to go through the implemented code. The bundle that does the actual embedding of the OpenEJB container in Jetty is the one called org.eclipse.wst.server.preview.jetty.openejb. It implements some hooks to get the control from Jetty in the case EJB beans are found in the deployed WARs. This bundle is completely runtime implementation and have no dependency to WTP bundles. Therefore, I think the best place for it is to be contributed to the Eclipse Jetty project, or even appropriate subproject under Eclipse Jetty could be created. The Jetty-OpenEJB integration is very similar to the Tomcat-OpenEJB integration. It uses the same openejb.war that needs to be deployed on the Jetty server. The org.eclipse.wst.server.preview and org.eclipse.jst.server.preview.adapter are modified so they call Jetty in the J2EE Preview server adapter in a way that the OpenEJB container is embedded. In simple words, it configures Jetty in a way that the org.eclipse.wst.server.preview.jetty.openejb bundle becomes active and the openejb.war is deployed during the startup of the Jetty server. The complete list of binaries that the implementation currently uses and needs to be approved by the Eclipse IP process are: openejb.war (3.1.1) - 25.2 MB ejb-api-3.0.jar - 32 KB openejb-core-3.1.1.jar - 1.4 MB openejb-ejbd-3.1.1.jar - 55 KB openejb-javaagent-3.1.1.jar - 12 KB openejb-jee-3.1.1.jar - 770 KB openejb-loader-3.1.1.jar - 41 KB openejb-server-3.1.1.jar - 73 KB xbean-finder-shaded-3.6-r779512.jar - 39 KB jetty-annotations-6.1.15.jar - 12 KB jetty-naming-6.1.15.jar - 28 KB jetty-plus-6.1.15.jar - 64 KB The most problematic one is the openejb.war. In addition to the big size, it includes lots of JARs that are licensed differently - there are 7 (seven) different licences totally. I expect that there is no legal issue that Eclipse redistributes all these JARs, but at least it will take some time to be reviewed by Eclipse IP process. The other JARs in the list above should be fairly easy to be reviewed and included in Orbit. The jetty-* ones should be even needless for review if Helios moves to Jetty 7.0, which is already EPL code. On the packaging issue. The main goal of the Jetty-OpenEJB integration in the J2EE Preview adapter is to be available mainly for the Eclipse community and be optional for WTP adopters. It should be included in the Eclipse IDE for Java EE Developers distribution and as an optional feature on the Eclipse update site. It should not be available in the normal WTP package, so WTP adopters, that don't need it, are not disturbed. I am not quite sure how this will be technically realized right now, but this will be the goal of this enhancement.
Hi Kaloyan, Thanks for the thorough review. From a technical standpoint, what are the changes to the preview adapter plugins, and could they handle the case where this support is not available? What I'm thinking is we should deliver this as two separate parts: a) OpenEJB and related runtime plugins that need legal clearance. Would be in it's own feature and a separate JEE download, included in the JEE package, or for adopters that want it. b) compatible changes to the preview server that don't require legal clearance, can be released soon, and only change the behaviour when OpenEJB is available.
Tim, I agree with your statements in a) and b) The changes in the preview adapter plugins are: - change in the way Jetty is started, so it embeds the OpenEJB container. Affected classes: o.e.w.server.preview/PreviewStarter and o.e.j.server.preview.adapter/PreviewLaunchConfugrationDelegate. - o.e.j.server.preview.adapter/PingThread is modified to report "started" status when the OpenEJB has completed startup (which is a little bit later after Jetty completes startup). - o.e.j.server.preview.adapter/PreviewRuntimeClasspathProvider is changed to include the javax.ejb bundle in the classpath container of the preview adapter. I believe (but need to research) that all these changes could be reimplemented in a more flexible way - to take effect only when the OpenEJB bundles are available in the Eclipse installation.
Hmm, there is one more change. The plugin.xml descriptor is change, so the "jst.ejb" is supported by the J2EE Preview adapter. I am almost sure that this cannot be set dynamically in the case that OpenEJB bundles are available...
