You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Thiago Veronezi <th...@veronezi.org> on 2010/08/03 15:27:00 UTC
EJB 3.1 Embeddable EJB Container API
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.
Re: EJB 3.1 Embeddable EJB Container API
Posted by Thiago Veronezi <th...@veronezi.org>.
Hi David,
On Wed, Aug 4, 2010 at 2:24 AM, David Jencks <da...@yahoo.com> wrote:
> 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
>
*********************************************************************************
I needed to start this other thread to be able to use
another completely different classloader. This way, I can have different
versions of the same jar running on the same jvm.
*********************************************************************************
> -- 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.
>
>
*********************************************************************************
Indeed, but in my case it does not matter.
*********************************************************************************
> 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.
>
>
*********************************************************************************
Yes. In my real life (work :O) ) the system Im implementing (Its already on
prod actually) uses this feature. Its an Tomcat/Openejb server. In order to
get hibernate running I needed to do some ugly stuff: I've added hibernate
jars to the Tomcat's lib forder (hmmmm). It is running fine, but I need to
figure out a more elegant way to do it.
This my personal project is just something to play with and to learn
something new. Im trying to create file server that is going to run on my
personal server. The server infra side is pretty much done. Now Im working
on the "business" :O) layer. I can send you the code if you are interested
to see your new code running and how all this classloader stuff works... :O)
[]s,
Thiago.
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 <da...@yahoo.com>
> 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.
> >>
> >>
>
>
Re: EJB 3.1 Embeddable EJB Container API
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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.
>>
>>
Re: EJB 3.1 Embeddable EJB Container API
Posted by Thiago Veronezi <th...@veronezi.org>.
Hi David,
*************************************************************************
On Tue, Aug 3, 2010 at 2:42 PM, David Jencks <da...@yahoo.com> 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.
>
>
Re: EJB 3.1 Embeddable EJB Container API
Posted by David Jencks <da...@yahoo.com>.
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.
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.
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.