tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vikrant Yagnick <>
Subject RE: OpenEJB Startup Performance
Date Tue, 08 Sep 2009 12:50:21 GMT
Hi All,

Thanks for the replies.

We already have a ejb-jar.xml since we have been using EJB 2.1(not 3.0 unfortunately...:().
The number of EJB's are going to remain pretty static since it has already been developed.

This won't really be that big a problem in Production, as once openejb initializes there is
no more delay. I need to figure out a way to initialize it automatically when the main container
starts-up (rather than on the first request to the application).

The pain really is while we are in development as for any small change requiring a container
re-start openEJB needs to re-create the entire application assembly.

We initialize openEJB using openejb.conf and set the following:
<Deployments dir="classes" />

The "classes" folder contains a META-INF folder which in-turn has the ejb-jar.xml.

I apologize if this sounds like a real newbie question, but is there a better way for us to
do this?


-----Original Message-----
From: Jonathan Gallimore []
Sent: Tuesday, September 08, 2009 6:01 PM
Subject: Re: OpenEJB Startup Performance

On Mon, Sep 7, 2009 at 10:30 PM, Quintin Beukes <>wrote:

> Hey,
> I'm no EJB master either, but I can answer your questions with what I do
> know.
> 1. Perfectly fine. If you run it in something like Geronimo, it's
> basically just embedded in Geronimo. Your web server is nothing more
> than a Java Application, and OpenEJB has 2 modes, Standalone and
> Embedded (I think there is another one I can't recall). So you're just
> initializing the OpenEJB application inside your VM, and have the same
> stability/functionality provided in any other mode. In fact, I would
> recommend doing this with OpenEJB any day.

This is absolutely right, it should work fine for you, and will basically
just run like the Embedded container. I do this at work for the day job - we
functionally test our app using Jetty and OpenEJB, and then we can just
access our app as if it were running in JBoss or Geronimo. Its not used in
production (yet - but we have considered it) but it works very well. (I
wrote it up here:
you're interested).

Let us know if have any problems with this setup.

> 2. How many EJBs do you have for it to take this long? If you have a
> huge classpath you can try trimming down the search to only the
> desired JARs. See:
> .
> Alternatively you can try and specify static bean configurations in
> ejb-jar.xml. They would be something like this:
> <?xml version="1.0" encoding="UTF-8" ?>
> <ejb-jar xmlns="" version="3.0"
>         xmlns:xsi=""
>         xsi:schemaLocation="
>   <enterprise-beans>
>      <session>
>         <ejb-name>TestBean</ejb-name>
>         <local>net.kunye.test.TestLocal</local>
>         <remote>net.kunye.test.TestRemote</remote>
>      </session>
>      <session>
>         <ejb-name>PersonnelBean</ejb-name>
>         <local>net.kunye.platform.personnel.PersonnelLocal</local>
>         <remote>net.kunye.platform.personnel.PersonnelRemote</remote>
>      </session>
>   </enterprise-beans>
> </ejb-jar>
> When you do this all the beans that are listed will be loaded from XML
> (no annotation interpretation afaik) and the rest of the beans will be
> loaded the normal way.
> What you can do is perhaps hook in a compile-time task to generate
> this list for you. If you already have such a file with other
> configurations, you can perhaps make a template and generate the
> ejb-jar.xml everytime you compile.
> I'm not sure how much this will help. I've never really had to deal
> with this problem. The most EJBs I've loaded was around 50 I think,
> and it went quick. Some of the other guys might be able to help with
> this.
> Q

I agree with what others have said here - it might be spending a long time
searching the classpath for EJBs - changing
openejb.deployments.classpath.include/exclude settings might help. If you
can let us know how many EJBs you have, how many Jars are on your classpath,
and maybe a log as well we might be able to help tune this a bit.


Mastek is in NASSCOM's 'India Top 20' Software Service Exporters List.
In the US, we're called MAJESCOMASTEK

Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited,
unless specifically indicated to that effect. Mastek Limited does not accept any responsibility
or liability for it. This e-mail and attachments (if any) transmitted with it are confidential
and/or privileged and solely for the use of the intended person or entity to which it is addressed.
Any review, re-transmission, dissemination or other use of or taking of any action in reliance
upon this information by persons or entities other than the intended recipient is prohibited.
This e-mail and its attachments have been scanned for the presence of computer viruses. It
is the responsibility of the recipient to run the virus check on e-mails and attachments before
opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop
and server.

View raw message