linking webapp with ejb in ear

[Tom Griffith]

Hello. If anybody has a minute, I've been messing with this all day. What I am trying to do is deploy an ear that uses a javabean called by jsp (both deployed in a war within the ear) to call an ejb session facade...and subsequently various entities. I can't seem to get the javabean to get a handle on the session facade object...ie...

javax.naming.InitialContext ctx = new javax.naming.InitialContext();

Object obj = ctx.lookup("java:comp/env/cmp/CnFacade");

if (obj == null) {
System.out.println ("Object is null");
}

CnFacadeHome home = (CnFacadeHome)javax.rmi.PortableRemoteObject.narrow(obj, CnFacadeHome.class);

I am printing "Object is null" and the error on the jsp is "Cannot locate class com.cn.CnFacadeHome". The javabean itself is in the com.cn package inside the web app so I think it is just looking in the package as a default after it can't get a handle on the ejb object via jndi.

I've tried all sorts of tinkering but to no avail. Does anybody have an idea, at least initially, about what could be the disconnect here? I feel I've tried just about everything. Thank you very much for reading this post.
[ April 18, 2005: Message edited by: Tom Griffith ]

[Jeanne Boyarsky]

Tom,
It could still be a classpath setting. What app server are you using?

[Valentin Tanase]

Hi Tom,

There are several things you’d like to check:

Did you pack your application correctly? I mean do you have your ejb packed in its own jar, the web app with its own war and both of them within the same ear?

Does your bean deploy correctly? Use your container’s tools in order to check if your bean binds into the jndi tree correctly.

Did you set bean references in your deployment descriptors?

Regards.

[Tom Griffith]

Hello everybody. Thank you for reading my thing. I believe the classpath is ok because I check individual ejbs by deploying them standalone in war and they seem to work ok.

I think the ear deployment is ok because the war containing the webapp does it's thing and deploys into appropriate file directories (just like a standalone war)...and all the jsps and javabeans are working ok. I also don't get errors on the server console...it sez "EnterpriseApplication[nctims] starting". I have a feeling the disconnect is due to either the individual ejb deployment descriptors or perhaps the web.xml in the webapp...cuz I'm not exactly sure where the jndi connection between the webapp and the ejb jars lies. Anyways, it's probably best to give a very brief summary of my descriptors and junk, focusing on "bridging" the javabean in the webapp to the facade ejb, whcih is inside it's own jar...

1. After deploying, the war containing the webapp, as I said, unbundles and the server puts jsp and javabeans into the appropriate directories within the indicated context root under the webapps directory. Here is the web.xml...

<web-app xmlns="http://caucho.com/ns/resin">

<session-config>
<session-timeout>120</session-timeout>
</session-config>

</web-app>

The calling javabean is located in com/cn directory within the web app, and it's package is com.cn.

2. The jar (cnf.jar) containing the session facade ejb (CnFacade) is located in the root directory of the enterprise bean. This jar contains three classes...CnFacade, CnFacadeHome, CnFacadeBean. All three classes have package com.cn indicated. This is the desployment descriptor for this ejb...

<ejb-jar>
<enterprise-beans>

<session>

<ejb-name>CnFacade</ejb-name>
<jndi-name>CnFacade</jndi-name>
<local-home>com.cn.CnFacadeHome</local-home>
<local>com.cn.CnFacade</local>
<ejb-class>com.cn.CnFacadeBean</ejb-class>

<session-type>Stateless</session-type>
</session>

</enterprise-beans>
</ejb-jar>

3. As I said, the jar (cnf.jar), in 2 above, containing the CnFacade ejb is in the root of the enterprise app, and this is the application.xml...

<application>
<display-name>NCTIMS</display-name>
<module>
<ejb>cnf.jar</ejb>
</module>
<module>
<web>
<web-uri>nctims.war</web-uri>
<context-root>/nctims</context-root>
</web>
</module>

</application>

4. When I deployed the ear, the server wanted the ejb server and database jndi stuff in it's configuration file. When I was testing ejb in individual wars, this stuff was in the web.xml of the war. Here is the ejb server tag in the server config file...

<ear-deploy path='deploy'>
<ear-default>

<ejb-server>
<config-directory>WEB-INF</config-directory>
<jndi-name>java:comp/env/cmp</jndi-name>
<data-source>java:comp/env/jdbc/test</data-source>
</ejb-server>


</ear-default>
</ear-deploy>


5. As was stated at the start of the thread, this is the calling javabean that is trying to create a jndi reference to CnFacade...and I am printing Object is null...

javax.naming.InitialContext ctx = new javax.naming.InitialContext();

Object obj = ctx.lookup("java:comp/env/cmp/CnFacade");

if (obj == null) {
System.out.println ("Object is null");
}


In summary, my suspicions lie in three places...

a. How does the webapp (deployed in 1 above) use jndi to bridge to the ejb stored in the root in a jar (cnf.jar)? Is there supposed to be something in the web.xml of the web app to indicate jndi info? Like I said, when I deployed the ear, it wanted that info in the config file for the server, so I figured that would cover it.

b. Do the ejb jars have to be put into a com/cn directory somewhere within the enterprise app as opposed to the root?...since they are all in com.cn package.

c. This line within the ejb server tag in the server config file...

<config-directory>WEB-INF</config-directory>

I don't know about this one since all the ejb jars are in the root of the ear, not within Web-inf.


I hope that this isn't too confusing...I really appreciate any help. What concerns me with tinkering with this stuff is stepping the wrong way and getting deeper into a quagmire (like being lost in a forest) since there are so many parts to the ear. Forgetting to reset something as I attempt the next experiment, etc. It could also be a combination of two factors. Thank you so much again.
[ April 19, 2005: Message edited by: Tom Griffith ]

[Valentin Tanase]

Tom,

In my opinion your problem relies here:

<ejb-name>CnFacade</ejb-name>
<jndi-name>CnFacade</jndi-name>
<local-home>com.cn.CnFacadeHome</local-home>
<local>com.cn.CnFacade</local>
<ejb-class>com.cn.CnFacadeBean</ejb-class>

And you basically have to rely on the jndi global name of your ejb. Not a good practice though, because you�ll couple your application code to the jndi names. I also suppose that your lookup:

Object obj = ctx.lookup("java:comp/env/cmp/CnFacade");

Will not return the desired value, because your bean is not bound under this name: "java:comp/env/cmp/CnFacade". I�m not a resin user and I�m not be able to tell you what is the real jndi name for your bean, but you can find out exploring the tree at runtime.
However there is a much flexible solution to your problem: use bean references. Hence you might consider defining this reference in your web.xml file:

<ejb-local-ref>
<ejb-ref-name>ejb/CnFacade</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local-home>com.cn.CnFacadeHome</local-home>
<local>com.cn.CnFacade </local>
</ejb-local-ref>

Once you did this you might use the bean�s reference name given to the component in the jndi environment naming context (ENC) and this lookup must be successful:

Object obj = ctx.lookup("java:comp/env/ejb/CnFacade");

Also you might remark that you can change your bean�s jndi name the way you like and your lookup will still be successful. I hope this will answer to all your questions.
Regards.

[Tom Griffith]

Valentin, when I package all ejb classes into a single war, with a single ejb deployment descriptor and the war's web.xml, it gets a handle on all objects with no problem via jndi lookup (although I do want to use references on them now) and everything runs as expected. However, with ear, the ejb deployment descriptors are now distributed to each ejb jar, and unlike war, it no longer has a single ejb deployment descriptor...

<ejb-server config-directory="WEB-INF">
<jndi-name>java:comp/env/cmp</jndi-name>
<data-source>java:comp/env/jdbc/test</data-source>
<ejb-descriptor>WEB-INF/cn.ejb</ejb-descriptor>
</ejb-server>

Instead of the single Web-inf/cn.ejb deployment descriptor in the war, the ear has three deployment descriptors and they are packed in each of the three ejb jars. I'm thinking that could be the root problem....before converting everything to references that is (which will be a headache cuz resin has minimal documentation and the tags have changed)...at least from the war test it appears the jndi lookup should work as it is now. I think it's a matter of somehow pointing the container to the three ejb descriptors in the jars. I've tried to put three ejb descriptor tags in the server config file within the ejb-server tag but it yells that I can't have multiple instances of the same tag.
[ April 19, 2005: Message edited by: Tom Griffith ]

[Valentin Tanase]

However, with ear, the ejb deployment descriptors are now distributed to each ejb jars, and I don't really have a central web.xml to specify where to find ~each~ deployment descriptor...

Actually you have a central configuration file that glues all your components together. Your ear has a deployment descriptor, application.xml located under the META-INF folder. Here you�ll specify all components that are part of your enterprise application, including web apps and ejbs like this:

    <module>
        <ejb>myejb.jar</ejb>
    </module>
    <module>
        <web>
            <web-uri>mywebapp.war</web-uri>
            <context-root>/mywebapp</context-root>
        </web>
    </module>

When you deploy the ear, the container will read this deployment descriptor, identifies all the components and start deploying them as well. Therefore the container will deploy your beans and bind them to the jndi tree using the names specified inside the ejb-jar.xml file.

Instead of the single Web-inf/cn.ejb deployment descriptor in this war, the ear has three deployment descriptors and they are packaged in the ejb jars.

Add all three modules to application.xml and the container will deploy them for you, reading their deployment descriptors, binding them to jndi, etc.
I specially wrote this at the end:

when I package all ejb classes into a single war, with a single ejb deployment descriptor and the war's web.xml,it gets a handle on all object with no problem via jndi lookup (although I do want to use references on them now) and everything rtuns as expected, or so it seems.

Because you�ve lost me here. Beans don�t get deployed in the war file with web apps and normally it should raise class loading issues. If this is a resin specific feature, then I�ll give up since this is not a standard J2EE approach.
Regards.

[Tom Griffith]

Valentin, yeah, i created the application.xml as you specified the other day. When i deploy, I see on the server console "EnterpiseApplication[nctims] is running" with no errors, so I have to assume the ejb jars are deployed. When you say this...

"Therefore the container will deploy your beans and bind them to the jndi tree using the names specified inside the ejb-jar.xml file."

do you mean the names specified within each ejb-jar.xml file, ie. one for each ejb jar?

One other thing I've noticed on deployment...while the war is unnbundled and tossed into the webapps directory of the ear, the ejb jars remain in the root, and I don't see their classes and deployment descriptor get unbundled. Is that normal?...I guess if I can figure out how to view the jndi tree on resin I could see. But I would think the ejb classes and descriptors would be visibly deployed somewhere in the enterprise app...but all I see are the ejb jars and I get no errors on deployment...

Thank you...
[ April 19, 2005: Message edited by: Tom Griffith ]

[Valentin Tanase]

Hi Tom,

I did some brief reading on resin packing and deployment stuff and I could see that resin does actually things very differently. It looks like resin needs to specify the <ejb-server> parameter in order for the EJBs to be recognised and bound to jndi. It�s something like configuring the ejb server, which is a resin specific feature. At this point I believe it might be better if you follow their specification and pack the app accordingly to resin specifications. Here there is an extract from resin documentation that makes me to back off:

This name, of course, only makes sense if the EJB is put into a jar. Jars are inconvenient during development, so Resin lets you rename the ejb-jar.xml file as *.ejb and put it in WEB-INF. We'll name it WEB-INF/hello.ejb. You can have as many *.ejb files as you want, Resin will use them all (for example WEB-INF/hello.ejb, WEB-INF/goodbye.ejb).

This makes me to believe that you were right from the beginning and I set you on the wrong path. You can read the complete article here:
http://www.caucho.com/resin-3.0/ejb/tutorial/ejb-stateless-hello/index.xtp
However the question still remains whether resin has a j2ee license or not, because if it has then it must allow packing enterprise archives and conforms to current j2ee standards.
Sorry for any inconvenience, I only wanted to help...
Regards.

[Tom Griffith]

Hi Valentin...I wouldn't be anywhere without your help. I picked resin to start down this path because it was free for development and I kinda liked doing everything from the command line in order to learn it (sans server based compiling tools). It's generally done everything its needed to do, and from what I can tell is has a j2ee license (it is running this ear) because I read in some release notes somewhere along the line that they started packaging the j2ee server with the regular jsp server. What I find annoying about it is what you specified...it's tagging conventions are out there on thier own on top of recently being changed and the *.ejb notation (whenever you were saying ejb-jar.xml, I was assuming *.ejb anyways). I'm so frustrated because I know this is close...and their ejb examples tend to be application level as opposed to enterprise deployment. Thank you for taking the time to read into it and for that link...I'll continue to hammer this...(the ear deployment is the final thing I need to do to get this down)....thank you again...
[ April 19, 2005: Message edited by: Tom Griffith ]

[Tom Griffith]

Geesh, I have everything working except the container isn't seeing my ejb jars. If I toss the ejb jars into the default lib directory for the server then the ejbs load...and the workflow I hcoded for is working. Do servers have some sort of configuration setting in their config file to enable it to read jar files elsewhere? I don't really think the config file is the answer because of the fact that numerous ears can be deployed. Anways, thank you...just thinking out loud...

Either that or the container is ignoring my tags for the ejb modules in application.xml. It's expanding the war though, and I'm seeing no error stating the container hates the ejb tags...it's just blowing them off, it appears...
[ April 22, 2005: Message edited by: Tom Griffith ]

[Valentin Tanase]

Thank you for keep us posted. Please let me know if you find the solution.
Regards.

[Tom Griffith]

Well, I am concluding this must be a classpath thing. I kinda blew it off when Jeanne mentioend if above but I was confusing PATH with CLASSPATH. I'm trying to set classpath in the environment but what has me confused is how to do this when ear expansion on the server creates it's own subdirectory. FOr instance, in resin...this is the directory path to where the ear gets dumped...

c:\resin-3.012\resin-3.0.1\deploy

then when it deploys, an additional directory is created, something like

c:\resin-3.012\resin-3.0.1\deploy\ear_whatever

where whatever denotes whatever.ear

so the portion after ...deploy\ is random. I've tried setting classpath to...

c:\resin-3.012\resin-3.0.1\deploy
c:\resin-3.012\resin-3.0.1\deploy\*

with no success...so I've been running this app by throwing my ejbs into the server lib directory until I can get this worked out...thank you again for reading...
[ April 22, 2005: Message edited by: Tom Griffith ]

[Tom Griffith]

Welp, I wound up adding a library loader to the resin configuration file (resin.conf) to load any library in the directory where ears are expanded (deploy) along with the context root of this individual ear...

<library-loader path='deploy/mywebapp'/>

Everythign is fine, but I have to think that this setting, along with the database and jndi stuff, should be stored somewhere locally in the ear (like in some kinda web.xml that is on the ear level), rather than in the server configuration file. But it seems as though resin wants it there. Welp, if anything new comes up with this, I'll post it.