Hi Quintin, Here is a typical startup log. There are a lot of EJB's for sure, but significant time is taken while assembling the app. (Is that when it searches for the EJB classes?)
Cheers, Vikrant -----Original Message----- From: Quintin Beukes [mailto:quin...@skywalk.co.za] Sent: Tuesday, September 08, 2009 7:15 PM To: users@openejb.apache.org Subject: Re: OpenEJB Startup Performance Like mentioned. Can you perhaps send us a log output of when OpenEJB starts up. Q On Tue, Sep 8, 2009 at 2:50 PM, Vikrant Yagnick <vikrant.yagn...@mastek.com> wrote: > 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? > > Cheers, > Vikrant > > -----Original Message----- > From: Jonathan Gallimore [mailto:jonathan.gallim...@gmail.com] > Sent: Tuesday, September 08, 2009 6:01 PM > To: users@openejb.apache.org > Subject: Re: OpenEJB Startup Performance > > On Mon, Sep 7, 2009 at 10:30 PM, Quintin Beukes <quin...@skywalk.co.za>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: > http://openejb.apache.org/functional-testing-with-openejb-jetty-and-selenium.htmlif > 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: >> http://openejb.apache.org/3.0/application-discovery-via-the-classpath.html >> . >> 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="http://java.sun.com/xml/ns/javaee"; version="3.0" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee >> http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd";> >> <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. > > Jon > > MASTEK LTD. > 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. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -- Quintin Beukes MASTEK LTD. 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
