Hi Thiago, Maybe I'm missing something obvious but could you explain the reason for starting another thread to start the ejb container in? What the spec provides is -- you start the EjbContainer -- when that call returns you can use the EjbContainer e.g. to run tests -- when you are done you can destroy the EjbContainer.
It seems to me that adding another thread would just prevent you from knowing when the EjbContainer is fully started. Also, since you mention you are using jetty, I wonder if you actually want the EjbContainer. With web profile you get ejbs in a war without having to do anything in your code to start the ejb container, you just provide the ejbs e.g. with annotations on some classes. I think we're pretty close to having this working in geronimo. I'm not sure how openejb would provide this functionality without repackaging and adding to/modifying jetty or tomcat; in geronimo that's what we do. thanks david jencks On Aug 3, 2010, at 5:18 PM, Thiago Veronezi wrote: > Hi David, > ************************************************************************* > On Tue, Aug 3, 2010 at 2:42 PM, David Jencks <[email protected]> wrote: > >> Hi Thiago, >> >> There seem to be more jira issues on this than I was aware of, but I think >> i've pretty much completely implemented this (based on david blevins start >> on the provider class). I haven't written any tests for or found the tck >> bits for the javax.ejb.embeddable.modules property however. Review would >> certainly be great. >> >> ************************************************************************** > OK... I can test it. I have a good system to use this new code. Im pretty > excited about that actually. My personal project uses an embedded openejb, > and I was looking forward to have this standard implementation done. tkx... > ************************************************************************** > >> It's possible that we could do something better with the classloaders since >> at the moment you need to manually put a lot of openejb jars and dependency >> jars on the classpath. I don't see any instructions in the spec on how this >> is supposed to work. Maybe we could come up with something that figures out >> how to load most of the openejb classes and dependencies if only the >> provider is on the classpath. I'd be tempted to use osgi but that might not >> be completely appropriate for all scenarios. >> >> ************************************************************************* > If we want to avoid conflicts between the users jars and opejbs jars, we can > create an Utility class that creates a brandnew classloader (openejb and dep > jars here) and starts a new thread using this classloader. This my personal > project already to this. > > Let me explain this proj: Its one jvm with 2 servers - openejb and jetty. > So, I have 3 classloaders: one global and one for each server. Below a > snapshot of the method that creates the server threads... > > ******************************************************************************* > private void startThread( > String serverClassName, //name of the server thread class > Resource rZipJars, //a zipfile with all needed jars > String serverName) { > final ClassLoader myLoader = getMyClassLoader(serverName, rZipJars); > this.myLoaders.add(myLoader); > try { > Class<?> mycls = Class.forName(serverClassName, true, myLoader); > Object treadinst = mycls.newInstance(); > Method start = mycls.getMethod("start"); > start.invoke(treadinst); > serverThreads.add(treadinst); > serverThreadsClasses.add(mycls); > } catch (Exception e) { > throw new SystemException("serverClassName: \"" + serverClassName > + "\"", e); > } > } > > private ClassLoader getMyClassLoader(String serverName, Resource rZipJars) { > File zipLibPath = new File(SystemParams.tempFolder, "serverlibs"); > if (!zipLibPath.exists()) { > zipLibPath.mkdirs(); > } > File serverLib = new File(zipLibPath, serverName); > if (serverLib.exists()) { > FileUtils.delete(serverLib); > } > serverLib.mkdir(); > > File zip = FileUtils.getFile(zipLibPath, rZipJars); > FileUtils.unzipFile(zip, serverLib); > > File[] myLib = serverLib.listFiles(); > URL[] ulrs = new URL[myLib.length]; > try { > for (int i = 0; i < myLib.length; i++) { > File lib = myLib[i]; > ulrs[i] = lib.toURI().toURL(); > } > } catch (MalformedURLException e) { > throw new SystemException(e); > } > return new URLClassLoader(ulrs); > } > > ******************************************************************************* > hope it helps... > []s, > Thiago. > > >> thanks >> david jencks >> >> >> On Aug 3, 2010, at 6:27 AM, Thiago Veronezi wrote: >> >>> Is there anyone coding "EJB 3.1 Embeddable EJB Container API" ( >>> http://openejb.apache.org/ejb-31-roadmap.html) already? >>> Can I play with it? >>> tkx, >>> Thiago. >> >>
