You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by freeway <fw...@qad.com> on 2009/11/13 18:37:30 UTC
Problems deploying EJBs in embedded Tomcat OpenEJB
I am new to OpenEJB and to EJBs in general, attempting to set up a Tomcat
6.0.16 environment to use embedded OpenEJB 3.1.2. My objective is port an
existing JEE application to run as a single webapp inside Tomcat, with
OpenEJB loading and managing access to its EJBs. All the EJB classes are
packaged in a single JAR file that is part of the webapp. The code is not
written with injection or any annotations, and I am defining the EJB objects
to the webapp entirely using the XML files WEB-INF/web.xml,
META-INF/context.xml, META-INF/ejb-jar.xml, and
$CATALINA-HOME/conf/openejb.xml.
The problem is that after Tomcat startup, which does not show any errors in
the Tomcat logs, the application is unable to access any EJBs from JNDI. I
expect I have configuration problems, and have searched the forums as well
as the OpenEJB documentation extensively for related posts and examples, but
the mixture of fragmentary current and stale information that available has
been difficult for an EJB newbie like myself to use.
Here is the JNDI error from the webapp at run-time. The application is
looking up the name 'lsbpm/LsBpmEjbFrontDesk', so I presume that the full
name is being constructed by OpenEJB.
javax.naming.NameNotFoundException: Name
"Deployment/lsbpm/LsBpmEjbFrontDesk/com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk!Remote"
not found.
Here is the relevant EJB reference from the webapp's web.xml.
<ejb-ref>
<ejb-ref-name>lsbpm/LsBpmEjbFrontDesk</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</home>
<remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</remote>
</ejb-ref>
Here is the relevant EJB configuration element from context.xml.
<Ejb name="lsbpm/LsBpmEjbFrontDesk" auth="Container" type="Session"
home="com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome"
remote="com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk"
factory="org.openejb.client.TomcatEjbFactory"
openejb.naming.factory.initial="org.apache.openejb.client.LocalInitialContextFactory"
openejb.ejb-link="lsbpm/LsBpmEjbFrontDesk"/>
Here is (I think) the relevant configuration from a much longer ejb-jar.xml.
<ejb-jar id="LsBpmEjb_jar">
...
<enterprise-beans>
<session id="LsBpmEjbFrontDesk">
<ejb-name>lsbpm/LsBpmEjbFrontDesk</ejb-name>
<home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</home>
<remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</remote>
<ejb-class>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
...
</session>
...
</enterprise-beans>
...
<ejb-jar>
Here is the loader servlet definition from the openejb webapp, which I did
not think was necessary but added nonetheless for testing purposes based on
some documentation that I found.
<servlet>
<servlet-name>LoaderServlet</servlet-name>
<servlet-class>org.apache.openejb.tomcat.loader.LoaderServlet</servlet-class>
<init-param>
<param-name>openejb.home</param-name>
<param-value>${catalina.base}/lsbpm/openejb</param-value>
</init-param>
<init-param>
<param-name>openejb.loader</param-name>
<param-value>LsBpmServer-webapp</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
The EJB JAR file, which contains a META-INF/ejb-jar.xml file, is saved in
the directory ${catalina.base}/lsbpm/openejb/apps/. I also left a copy in
the WEB-INF/lib/ directory of my webapp.
Finally, the $CATALINA_HOME/conf/openejb.xml file has not been modified, and
contains a Deployments element at the bottom referencing the EJB directory
location.
<Deployments dir="apps/" />
The Tomcat stdout log entries on startup are as follows.
OpenEJB init-params:
param-name: openejb.home, param-value: C:\Program Files\Apache Software
Foundation\Tomcat 6.0/lsbpm/openejb
param-name: openejb.loader, param-value: LsBpmServer-webapp
log4j:WARN No appenders could be found for logger (OpenEJB.options).
log4j:WARN Please initialize the log4j system properly.
Apache OpenEJB 3.1.2 build: 20091010-03:11
http://openejb.apache.org/
context path = /LsBpmServer
context path = /openejb
...
After startup, the JNDI viewer in the openejb webapp does not show any of my
EJBs. To compound the problem, I have been unable to increase the OpenEJB
log level by overriding the embedded.logging.properties file with my own
jndi.properties file as described in the OpenEJB documentation. Whether I
place the override file in the openejb lib/, openejb WEB-INF/classes, or
$CATALINA_HOME/lib directories, it does not affect the log output. Is this
a known OpenEJB issue?
Please provide any hints you can. I can obviously provide much more detail,
but did not want to overload this post until I knew what was most relevant.
I expect that I have simply misunderstood the configuration that is
necessary to use embedded OpenEJB.
Thx in advance.
--
View this message in context: http://old.nabble.com/Problems-deploying-EJBs-in-embedded-Tomcat-OpenEJB-tp26340393p26340393.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Problems deploying EJBs in embedded Tomcat OpenEJB
Posted by David Blevins <da...@visi.com>.
This is fantastic feedback! A project couldn't hope for better.
Thank you so much for taking the time to write all this. I had a good
laugh on your #4 as I've totally done that myself -- and you're right,
sometimes it works.
I'm neck deep in a new feature right now, but hopefully can find time
to update some of the docs.
If you're interested we could arrange to give you direct access to the
docs (a wiki) pretty easily and you could edit as you see fit. You
clearly have the perfect mindset for this kind of thing. I'd be happy
to IRC or Skype with you to get the info across and you just need to
write it. Realize you're still evaluating, but throwing it out there
anyway.
Glad things are working now!
-David
On Nov 18, 2009, at 3:10 PM, freeway wrote:
>
> Thanks very much for your prompt and helpful reply. After enabling
> Tomcat
> logging, we received enough information about the problems to debug
> our
> configuration. OpenEJB now appears to be working with our webapp,
> supporting the legacy EJBs without issues.
>
> To answer your question about documentation, here is a summary of the
> information sources I used with some suggestions.
>
> 1. I started by following the tomcat.html page instructions, which in
> hindsight was correct but still incomplete and unsatisfactory. The
> EJBs did
> not load during initial testing, and there was no reference here to
> troubleshooting or logging. The title 'Installation for the
> Impatient'
> raised my hopes that somewhere there was a longer and more explicit
> procedure for the patient, but apparently there is not.
>
> 2. After reading the rest of the product documentation at the web
> site, I
> tried to use the configuring-logging-in-tests.html page, but it is
> written
> to apply to the stand-alone rather than the embedded environment,
> with no
> reference to the latter. As I was not familiar with Tomcat's native
> logging
> at the time, it did not help.
>
> 3. I searched the openejb webapp's files, and found the following
> pages:
> howitworks.html, ejbclasses.html, ejbref.html, enc-help.html, re-
> help.html.
> They seemed very helpful in that they described some potential
> issues, use
> of the Tomcat classloaders, and so on; but I gather that they
> pertain to
> older releases and are now obsolete.
>
> 4. In increasing desperation, I searched your SVN repository as well
> as the
> web in general for more information of any kind about the workings of
> OpenEJB-inside-Tomcat. In most cases, the pages I found were marked
> as
> obsolete, but that did not stop me. Very often obsolete
> documentation still
> contains much useful information, particularly when no other
> information
> sources are available, and the package and environment as a whole is
> new and
> unknown. I assumed that my primary problem was an incorrect/
> incomplete
> configuration, and the old web pages showed examples that seemed very
> relevant, even if some of the details might have changed.
>
>
> Overall, I would suggest the following.
>
> 1. Update/organize all of your documentation to explicitly
> distinguish the
> stand-alone from the embedded installation, to avoid mix-ups.
>
> 2. Provide more references and links to relevant details about
> Tomcat, where
> applicable (for example, logging).
>
> 3. Provide a technical overview that describes what the openejb webapp
> actually does within the Tomcat environment, and how it uses or
> interacts
> with Tomcat's features. This is important, because I don't think
> that most
> users of projects like OpenEJB want a complete 'black-box'
> solution. They
> want at least some understanding of how it behaves within their target
> environment in order to have some idea of how to handle problems,
> particular
> when that environment is shared with applications and other external
> code.
> The openejb webapp clearly uses the Tomcat environment in a very non-
> typical
> way, introspecting the other webapps to find their EJBs, and so on.
> Without
> at least a high-level understanding of how it works, it is very easy
> for a
> user to fear the impact that OpenEJB might have on a shared Tomcat
> environment, to blame it for other unrelated problems, and generally
> to let
> our paranoia regarding unknown software get the best of us.
>
> 4. Provide at least one working example webapp with older, un-
> annotated EJB
> source code. Seeing such an example might have reassured me that the
> recommended approach is corrected, and would have prevented me from
> introducing unnecessary/harmful configuration.
>
>
> Again, thanks for your help. I will continue to post OpenEJB
> points/questions of interest to this forum.
>
>
>
> David Blevins wrote:
>>
>> I think this might be a case of doing too much. If we can retrace
>> your steps and find the sources of information you used, we should be
>> able remove or update them.
>>
>> The only steps required are the four steps listed here:
>>
>> http://openejb.apache.org/tomcat.html
>>
>>
>> On Nov 13, 2009, at 9:37 AM, freeway wrote:
>>
>>> All the EJB classes are
>>> packaged in a single JAR file that is part of the webapp. The code
>>> is not
>>> written with injection or any annotations, and I am defining the EJB
>>> objects
>>> to the webapp entirely using the XML files WEB-INF/web.xml,
>>> META-INF/context.xml, META-INF/ejb-jar.xml, and
>>> $CATALINA-HOME/conf/openejb.xml.
>>
>> Put the ejb-jar.xml in the jar where your ejbs live just like you
>> would if the war was an ear file.
>>
>> In the future this won't be required, but it is currently.
>>
>>> Here is the relevant EJB reference from the webapp's web.xml.
>>>
>>> <ejb-ref>
>>> <ejb-ref-name>lsbpm/LsBpmEjbFrontDesk</ejb-ref-name>
>>> <ejb-ref-type>Session</ejb-ref-type>
>>> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
>>> home>
>>> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
>>> remote>
>>> </ejb-ref>
>>
>> Good.
>>
>>> Here is the relevant EJB configuration element from context.xml.
>>>
>>> <Ejb name="lsbpm/LsBpmEjbFrontDesk" auth="Container" type="Session"
>>> home="com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome"
>>> remote="com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk"
>>> factory="org.openejb.client.TomcatEjbFactory"
>>>
>>> openejb
>>> .naming
>>> .factory
>>> .initial="org.apache.openejb.client.LocalInitialContextFactory"
>>> openejb.ejb-link="lsbpm/LsBpmEjbFrontDesk"/>
>>
>> This will cause problems and should be removed. We will actually do
>> all this kind of work for you automatically.
>>
>> We've tried to prevent people from doing this by wiping it from out
>> documentation leaving only a "do not use this" page:
>>
>> http://openejb.sourceforge.net/tomcat-object-factory.html
>>
>> If you can let us know where you saw this, we can try and get it
>> updated.
>>
>>> Here is (I think) the relevant configuration from a much longer ejb-
>>> jar.xml.
>>>
>>> <ejb-jar id="LsBpmEjb_jar">
>>> ...
>>> <enterprise-beans>
>>>
>>> <session id="LsBpmEjbFrontDesk">
>>> <ejb-name>lsbpm/LsBpmEjbFrontDesk</ejb-name>
>>> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
>>> home>
>>> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
>>> remote>
>>>
>>> <ejb-class>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskBean</
>>> ejb-class>
>>> <session-type>Stateless</session-type>
>>> <transaction-type>Container</transaction-type>
>>>
>>> ...
>>> </session>
>>> ...
>>> </enterprise-beans>
>>> ...
>>> <ejb-jar>
>>
>> Looks good.
>>
>>> Here is the loader servlet definition from the openejb webapp, which
>>> I did
>>> not think was necessary but added nonetheless for testing purposes
>>> based on
>>> some documentation that I found.
>>
>> Adding that will cause problems and it should be removed from your
>> webapp. If you can point us at the documentation you found that
>> recommended, we can definitely update it.
>>
>>> The EJB JAR file, which contains a META-INF/ejb-jar.xml file, is
>>> saved in
>>> the directory ${catalina.base}/lsbpm/openejb/apps/. I also left a
>>> copy in
>>> the WEB-INF/lib/ directory of my webapp.
>>
>> Having the jar file in the WEB-INF/lib/ should be all you need.
>>
>>> Finally, the $CATALINA_HOME/conf/openejb.xml file has not been
>>> modified, and
>>> contains a Deployments element at the bottom referencing the EJB
>>> directory
>>> location.
>>>
>>> <Deployments dir="apps/" />
>>
>> All relative directories in the openejb.xml are resolved relative to
>> openejb.base, which in Tomcat will be the same as catalina.base. So
>> you could put apps in ${catalina.base}/apps/. Though really it's far
>> more convenient to just include everything needed in the webapp.
>>
>>> The Tomcat stdout log entries on startup are as follows.
>>>
>>> OpenEJB init-params:
>>> param-name: openejb.home, param-value: C:\Program Files\Apache
>>> Software
>>> Foundation\Tomcat 6.0/lsbpm/openejb
>>> param-name: openejb.loader, param-value: LsBpmServer-webapp
>>> log4j:WARN No appenders could be found for logger (OpenEJB.options).
>>> log4j:WARN Please initialize the log4j system properly.
>>> Apache OpenEJB 3.1.2 build: 20091010-03:11
>>> http://openejb.apache.org/
>>> context path = /LsBpmServer
>>> context path = /openejb
>>> ...
>>
>> The output above will go away once you remove the LoaderServlet and
>> let the openejb.war do all the loading. As well any issues with
>> beans
>> not loading *should* go away.
>>
>>> I have been unable to increase the OpenEJB
>>> log level by overriding the embedded.logging.properties file with my
>>> own
>>> jndi.properties file as described in the OpenEJB documentation.
>>
>> Looks like we need to be more explicit and I can see where this
>> confusion could come from. Using OpenEJB in another server like
>> Tomcat or Geronimo or as a standalone server is very different than
>> embedding OpenEJB in a plain Java SE environment using the JNDI
>> InitialContext.
>>
>> For Tomcat, the logging configuration should be automatically added
>> to
>> ${catalina.home}/conf/logging.properties
>>
>> I hope this helps. Thank you for providing such a complete email.
>> It
>> definitely gives us some better on what issues we need to steer
>> people
>> away from and how to better define the Tomcat/OpenEJB path.
>>
>> -David
>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Problems-deploying-EJBs-in-embedded-Tomcat-OpenEJB-tp26340393p26417538.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
>
Re: Problems deploying EJBs in embedded Tomcat OpenEJB
Posted by freeway <fw...@qad.com>.
Thanks very much for your prompt and helpful reply. After enabling Tomcat
logging, we received enough information about the problems to debug our
configuration. OpenEJB now appears to be working with our webapp,
supporting the legacy EJBs without issues.
To answer your question about documentation, here is a summary of the
information sources I used with some suggestions.
1. I started by following the tomcat.html page instructions, which in
hindsight was correct but still incomplete and unsatisfactory. The EJBs did
not load during initial testing, and there was no reference here to
troubleshooting or logging. The title 'Installation for the Impatient'
raised my hopes that somewhere there was a longer and more explicit
procedure for the patient, but apparently there is not.
2. After reading the rest of the product documentation at the web site, I
tried to use the configuring-logging-in-tests.html page, but it is written
to apply to the stand-alone rather than the embedded environment, with no
reference to the latter. As I was not familiar with Tomcat's native logging
at the time, it did not help.
3. I searched the openejb webapp's files, and found the following pages:
howitworks.html, ejbclasses.html, ejbref.html, enc-help.html, re-help.html.
They seemed very helpful in that they described some potential issues, use
of the Tomcat classloaders, and so on; but I gather that they pertain to
older releases and are now obsolete.
4. In increasing desperation, I searched your SVN repository as well as the
web in general for more information of any kind about the workings of
OpenEJB-inside-Tomcat. In most cases, the pages I found were marked as
obsolete, but that did not stop me. Very often obsolete documentation still
contains much useful information, particularly when no other information
sources are available, and the package and environment as a whole is new and
unknown. I assumed that my primary problem was an incorrect/incomplete
configuration, and the old web pages showed examples that seemed very
relevant, even if some of the details might have changed.
Overall, I would suggest the following.
1. Update/organize all of your documentation to explicitly distinguish the
stand-alone from the embedded installation, to avoid mix-ups.
2. Provide more references and links to relevant details about Tomcat, where
applicable (for example, logging).
3. Provide a technical overview that describes what the openejb webapp
actually does within the Tomcat environment, and how it uses or interacts
with Tomcat's features. This is important, because I don't think that most
users of projects like OpenEJB want a complete 'black-box' solution. They
want at least some understanding of how it behaves within their target
environment in order to have some idea of how to handle problems, particular
when that environment is shared with applications and other external code.
The openejb webapp clearly uses the Tomcat environment in a very non-typical
way, introspecting the other webapps to find their EJBs, and so on. Without
at least a high-level understanding of how it works, it is very easy for a
user to fear the impact that OpenEJB might have on a shared Tomcat
environment, to blame it for other unrelated problems, and generally to let
our paranoia regarding unknown software get the best of us.
4. Provide at least one working example webapp with older, un-annotated EJB
source code. Seeing such an example might have reassured me that the
recommended approach is corrected, and would have prevented me from
introducing unnecessary/harmful configuration.
Again, thanks for your help. I will continue to post OpenEJB
points/questions of interest to this forum.
David Blevins wrote:
>
> I think this might be a case of doing too much. If we can retrace
> your steps and find the sources of information you used, we should be
> able remove or update them.
>
> The only steps required are the four steps listed here:
>
> http://openejb.apache.org/tomcat.html
>
>
> On Nov 13, 2009, at 9:37 AM, freeway wrote:
>
>> All the EJB classes are
>> packaged in a single JAR file that is part of the webapp. The code
>> is not
>> written with injection or any annotations, and I am defining the EJB
>> objects
>> to the webapp entirely using the XML files WEB-INF/web.xml,
>> META-INF/context.xml, META-INF/ejb-jar.xml, and
>> $CATALINA-HOME/conf/openejb.xml.
>
> Put the ejb-jar.xml in the jar where your ejbs live just like you
> would if the war was an ear file.
>
> In the future this won't be required, but it is currently.
>
>> Here is the relevant EJB reference from the webapp's web.xml.
>>
>> <ejb-ref>
>> <ejb-ref-name>lsbpm/LsBpmEjbFrontDesk</ejb-ref-name>
>> <ejb-ref-type>Session</ejb-ref-type>
>> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
>> home>
>> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
>> remote>
>> </ejb-ref>
>
> Good.
>
>> Here is the relevant EJB configuration element from context.xml.
>>
>> <Ejb name="lsbpm/LsBpmEjbFrontDesk" auth="Container" type="Session"
>> home="com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome"
>> remote="com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk"
>> factory="org.openejb.client.TomcatEjbFactory"
>>
>> openejb
>> .naming
>> .factory
>> .initial="org.apache.openejb.client.LocalInitialContextFactory"
>> openejb.ejb-link="lsbpm/LsBpmEjbFrontDesk"/>
>
> This will cause problems and should be removed. We will actually do
> all this kind of work for you automatically.
>
> We've tried to prevent people from doing this by wiping it from out
> documentation leaving only a "do not use this" page:
>
> http://openejb.sourceforge.net/tomcat-object-factory.html
>
> If you can let us know where you saw this, we can try and get it
> updated.
>
>> Here is (I think) the relevant configuration from a much longer ejb-
>> jar.xml.
>>
>> <ejb-jar id="LsBpmEjb_jar">
>> ...
>> <enterprise-beans>
>>
>> <session id="LsBpmEjbFrontDesk">
>> <ejb-name>lsbpm/LsBpmEjbFrontDesk</ejb-name>
>> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
>> home>
>> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
>> remote>
>>
>> <ejb-class>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskBean</
>> ejb-class>
>> <session-type>Stateless</session-type>
>> <transaction-type>Container</transaction-type>
>>
>> ...
>> </session>
>> ...
>> </enterprise-beans>
>> ...
>> <ejb-jar>
>
> Looks good.
>
>> Here is the loader servlet definition from the openejb webapp, which
>> I did
>> not think was necessary but added nonetheless for testing purposes
>> based on
>> some documentation that I found.
>
> Adding that will cause problems and it should be removed from your
> webapp. If you can point us at the documentation you found that
> recommended, we can definitely update it.
>
>> The EJB JAR file, which contains a META-INF/ejb-jar.xml file, is
>> saved in
>> the directory ${catalina.base}/lsbpm/openejb/apps/. I also left a
>> copy in
>> the WEB-INF/lib/ directory of my webapp.
>
> Having the jar file in the WEB-INF/lib/ should be all you need.
>
>> Finally, the $CATALINA_HOME/conf/openejb.xml file has not been
>> modified, and
>> contains a Deployments element at the bottom referencing the EJB
>> directory
>> location.
>>
>> <Deployments dir="apps/" />
>
> All relative directories in the openejb.xml are resolved relative to
> openejb.base, which in Tomcat will be the same as catalina.base. So
> you could put apps in ${catalina.base}/apps/. Though really it's far
> more convenient to just include everything needed in the webapp.
>
>> The Tomcat stdout log entries on startup are as follows.
>>
>> OpenEJB init-params:
>> param-name: openejb.home, param-value: C:\Program Files\Apache
>> Software
>> Foundation\Tomcat 6.0/lsbpm/openejb
>> param-name: openejb.loader, param-value: LsBpmServer-webapp
>> log4j:WARN No appenders could be found for logger (OpenEJB.options).
>> log4j:WARN Please initialize the log4j system properly.
>> Apache OpenEJB 3.1.2 build: 20091010-03:11
>> http://openejb.apache.org/
>> context path = /LsBpmServer
>> context path = /openejb
>> ...
>
> The output above will go away once you remove the LoaderServlet and
> let the openejb.war do all the loading. As well any issues with beans
> not loading *should* go away.
>
>> I have been unable to increase the OpenEJB
>> log level by overriding the embedded.logging.properties file with my
>> own
>> jndi.properties file as described in the OpenEJB documentation.
>
> Looks like we need to be more explicit and I can see where this
> confusion could come from. Using OpenEJB in another server like
> Tomcat or Geronimo or as a standalone server is very different than
> embedding OpenEJB in a plain Java SE environment using the JNDI
> InitialContext.
>
> For Tomcat, the logging configuration should be automatically added to
> ${catalina.home}/conf/logging.properties
>
> I hope this helps. Thank you for providing such a complete email. It
> definitely gives us some better on what issues we need to steer people
> away from and how to better define the Tomcat/OpenEJB path.
>
> -David
>
>
>
--
View this message in context: http://old.nabble.com/Problems-deploying-EJBs-in-embedded-Tomcat-OpenEJB-tp26340393p26417538.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Problems deploying EJBs in embedded Tomcat OpenEJB
Posted by David Blevins <da...@visi.com>.
I think this might be a case of doing too much. If we can retrace
your steps and find the sources of information you used, we should be
able remove or update them.
The only steps required are the four steps listed here:
http://openejb.apache.org/tomcat.html
On Nov 13, 2009, at 9:37 AM, freeway wrote:
> All the EJB classes are
> packaged in a single JAR file that is part of the webapp. The code
> is not
> written with injection or any annotations, and I am defining the EJB
> objects
> to the webapp entirely using the XML files WEB-INF/web.xml,
> META-INF/context.xml, META-INF/ejb-jar.xml, and
> $CATALINA-HOME/conf/openejb.xml.
Put the ejb-jar.xml in the jar where your ejbs live just like you
would if the war was an ear file.
In the future this won't be required, but it is currently.
> Here is the relevant EJB reference from the webapp's web.xml.
>
> <ejb-ref>
> <ejb-ref-name>lsbpm/LsBpmEjbFrontDesk</ejb-ref-name>
> <ejb-ref-type>Session</ejb-ref-type>
> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
> home>
> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
> remote>
> </ejb-ref>
Good.
> Here is the relevant EJB configuration element from context.xml.
>
> <Ejb name="lsbpm/LsBpmEjbFrontDesk" auth="Container" type="Session"
> home="com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome"
> remote="com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk"
> factory="org.openejb.client.TomcatEjbFactory"
>
> openejb
> .naming
> .factory
> .initial="org.apache.openejb.client.LocalInitialContextFactory"
> openejb.ejb-link="lsbpm/LsBpmEjbFrontDesk"/>
This will cause problems and should be removed. We will actually do
all this kind of work for you automatically.
We've tried to prevent people from doing this by wiping it from out
documentation leaving only a "do not use this" page:
http://openejb.sourceforge.net/tomcat-object-factory.html
If you can let us know where you saw this, we can try and get it
updated.
> Here is (I think) the relevant configuration from a much longer ejb-
> jar.xml.
>
> <ejb-jar id="LsBpmEjb_jar">
> ...
> <enterprise-beans>
>
> <session id="LsBpmEjbFrontDesk">
> <ejb-name>lsbpm/LsBpmEjbFrontDesk</ejb-name>
> <home>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskHome</
> home>
> <remote>com.oakgrovesystems.reactor.frontDesk.EJBFrontDesk</
> remote>
>
> <ejb-class>com.oakgrovesystems.reactor.frontDesk.EJBFrontDeskBean</
> ejb-class>
> <session-type>Stateless</session-type>
> <transaction-type>Container</transaction-type>
>
> ...
> </session>
> ...
> </enterprise-beans>
> ...
> <ejb-jar>
Looks good.
> Here is the loader servlet definition from the openejb webapp, which
> I did
> not think was necessary but added nonetheless for testing purposes
> based on
> some documentation that I found.
Adding that will cause problems and it should be removed from your
webapp. If you can point us at the documentation you found that
recommended, we can definitely update it.
> The EJB JAR file, which contains a META-INF/ejb-jar.xml file, is
> saved in
> the directory ${catalina.base}/lsbpm/openejb/apps/. I also left a
> copy in
> the WEB-INF/lib/ directory of my webapp.
Having the jar file in the WEB-INF/lib/ should be all you need.
> Finally, the $CATALINA_HOME/conf/openejb.xml file has not been
> modified, and
> contains a Deployments element at the bottom referencing the EJB
> directory
> location.
>
> <Deployments dir="apps/" />
All relative directories in the openejb.xml are resolved relative to
openejb.base, which in Tomcat will be the same as catalina.base. So
you could put apps in ${catalina.base}/apps/. Though really it's far
more convenient to just include everything needed in the webapp.
> The Tomcat stdout log entries on startup are as follows.
>
> OpenEJB init-params:
> param-name: openejb.home, param-value: C:\Program Files\Apache
> Software
> Foundation\Tomcat 6.0/lsbpm/openejb
> param-name: openejb.loader, param-value: LsBpmServer-webapp
> log4j:WARN No appenders could be found for logger (OpenEJB.options).
> log4j:WARN Please initialize the log4j system properly.
> Apache OpenEJB 3.1.2 build: 20091010-03:11
> http://openejb.apache.org/
> context path = /LsBpmServer
> context path = /openejb
> ...
The output above will go away once you remove the LoaderServlet and
let the openejb.war do all the loading. As well any issues with beans
not loading *should* go away.
> I have been unable to increase the OpenEJB
> log level by overriding the embedded.logging.properties file with my
> own
> jndi.properties file as described in the OpenEJB documentation.
Looks like we need to be more explicit and I can see where this
confusion could come from. Using OpenEJB in another server like
Tomcat or Geronimo or as a standalone server is very different than
embedding OpenEJB in a plain Java SE environment using the JNDI
InitialContext.
For Tomcat, the logging configuration should be automatically added to
${catalina.home}/conf/logging.properties
I hope this helps. Thank you for providing such a complete email. It
definitely gives us some better on what issues we need to steer people
away from and how to better define the Tomcat/OpenEJB path.
-David