Hi Gregor,
thanks for this extensive answer. I deployed a very simple sample
application to JBoss but for any reason I cannot access my EJB from my
RPC service. Neither with the @EJB annotation nor with the @Resource
SessionContext ctx statement. That's what my service implementation
looks like:
package de.stsch.j2ee.gwt.server;
import javax.annotation.Resource;
import javax.ejb.EJB;
import javax.ejb.SessionContext;
import com.google.gwt.user.server.rpc.RemoteServiceServlet;
import de.stsch.j2ee.ejb.StSch;
import de.stsch.j2ee.gwt.client.GwtClientSrc;
public class GwtClientSrcImpl extends RemoteServiceServlet implements
GwtClientSrc {
@EJB
StSch bean;
@Resource
SessionContext ctx;
@Override
public String getName() {
StringBuffer sb = new StringBuffer();
if (ctx == null) {
sb.append("ctx is null");
} else {
sb.append("ctx is not null");
}
if (bean == null) {
sb.append(", bean is null");
} else {
sb.append(", bean is not null");
}
return sb.toString();
}
}
And it always returns that both ctx and bean is null :-(
Any idea why?
-Steffen-
On 25 Mrz., 16:26, gregor <[email protected]> wrote:
> Hi Steffen,
>
> The simplest way to do this is to add your GWT app as a module (WAR)
> to your EAR. The GWT RPC servlets will then have direct access to your
> session beans local interfaces (which you must define BTW).
>
> If you cannot do this for some reason, the situation is a bit
> trickier. Your standalone Java client probably uses RMI to call your
> session beans? Is so, then it is calling the beans remote interfaces
> and call parameters/return values are serialized over the wire. AFAIK
> you cannot call the local interface of a session bean from a class
> outside its EAR. You can always use JNDI to look up the remote
> interfaces of your session beans from a separate GWT module's RPC
> servlets (which mimics what happens with the Java client) but this
> involves your app server serializing and deserializing all objects
> passed betweeen the GWT app and the enterprise app, i.e. the app
> server will be serializing to itself, which is a serious performance
> drain you will want to avoid.
>
> BTW I think the reason why this is so is that each EAR or WAR deployed
> on your app server is allocated it's own classloader, so in this
> situation your session beans are not directly visible by reference to
> your GWT module classes and visa versa, so they must be called
> remotely (which means serialization).
>
> One way around this is to set up your EJB application as a Resource
> Adapter ARchive (RAR). This is not normally used in applications as
> such, and is usually associated with some external data source common
> to a number of applications in an enterprise situation (a bit like a
> database, it's comparable to a JDBC). Normally vendors use it, for
> example Apache Jackrabbit uses a RAR. However this complicates things,
> and I am not sure you will get optimal performance out of it anyway
> (although I am not sure, I use RAR's but have never written one
> myself), but it will probably perform better than using remote
> interfaces to your session beans.
>
> http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic...
>
> For these reasons, unless you have the strongest possible reasons for
> not doing so, I think your best bet is to include your GWT module in
> your main enterpise application (so it is a WAR inside the EAR) and
> then you will be able to call your session beans directly from GWT RPC
> servlets using their local interfaces. This should give you the best
> performance from the simplest code.
>
> regards
> gregor
>
> On Mar 25, 2:15 pm, stsch <[email protected]> wrote:
>
> > In Eclipse I have one project (j2eeEjb) containing the Enterprise Java
> > Beans, one projects (j2eeClient) contains the corresponding Remote
> > Interfaces and one project (j2eeEar) only assembles everything into an
> > ear-file. The resulting ear-file contains 2 jar-files, j2eeEjb.jar and
> > j2eeClient.jar; this is the corresponding application.xml of the ear-
> > file
>
> > <?xml version="1.0" encoding="ASCII"?>
> > <application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns="http://java.sun.com/xml/ns/javaee" xmlns:application="http://
> > java.sun.com/xml/ns/javaee/application_5.xsd"
> > xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/ap..."
> > version="5">
> > <display-name>j2eeEAR</display-name>
> > <module>
> > <ejb>j2eeEjb.jar</ejb>
> > </module>
> > </application>
>
> > and this is the corresponding ejb-jar.xml of the j2eeEjb.jar
>
> > <?xml version="1.0" encoding="UTF-8"?>
> > <ejb-jar
> > xmlns="http://java.sun.com/xml/ns/javaee"
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > xmlns:ejb="http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
> >
> > xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/ej..."
> > version="3.0">
> > <display-name>j2ee</display-name>
> > <enterprise-beans>
> > <session>
> > <ejb-name>StSchBean</ejb-name>
> > </session>
> > </enterprise-beans>
> > <ejb-client-jar>j2eeClient.jar</ejb-client-jar>
> > </ejb-jar>
>
> > I can call a stateless session bean from a stadalone Java client
> > without any problems.
>
> > To the experts: Does this structure make sense? Or any suggestions for
> > improvement?
>
> > To develop a GWT application I would create a new project in eclipse
> > and deploy it to my application server as a separate war-file. Does
> > that make sense? Or should I try to include it into the ear-file
> > extending the application.xml by a web module-entry?
>
> > Nevertheless I couldn't make a call from my GWT RPC service to my
> > session bean. What would be the best approach to do so? In my opinion
> > there are 2 options: use the @EJB annotation or use
>
> > @Resource
> > SessionContext ctx;
>
> > and do a lookup. Or is there any other option?
>
> > Thanks in advance for any help, I really feel a bit stuck now :-(
>
> > -Steffen_
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---