EJB3 model and GWT
Andrew Law
I have a Java domain model which I persist using EJB3.0 and Toplink. I
have used this in various other circumstances and it works fine. I
package this model up as a jar which contains both the model, and
session facade class files as well as META-INF directory which
contains the persistence.xml file. In the session facade I have a
constructor which can be called with the name of the persistence unit
to use (there are multiple in the persistence.xml file) to create the
database connection.
I am trying to use this in a GWT application I am writing. I have
placed the jar file in the classpath so that the classes can be seen
but there seems to be a problem in the GWT debugger finding the
persistence.xml file. When I run my application, and i make a call to
the session facade constructor ("GrumpyService") I get the following
error:
[WARN] StandardContext[]Exception while dispatching incoming RPC call
javax.persistence.PersistenceException: No Persistence provider for
EntityManager named GrumpyMySQLDatabase
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:89)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
at com.grumpytummy.service.GrumpyService.<init>(GrumpyService.java:64)
at com.grumpy.gwtui.servlet.DataServlet.getData(DataServlet.java:33)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:262)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:146)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
I would appreciate it if someone could help me out by pointing out my
obvious mistake.
TIA,
Andrew
Luciano Broussal
you can't use any java jar in GWT without modification.
you can only use a java subset classes and complex other classes based
on this subset.
the classes subset supported by gwt is :
charlie...@gmail.com
resource in GWT *client* side code. In addition to having the limited
JRE subset that Luciano noted you also have to remember that "GWT
compiles Java source that is compatible with J2SE 1.4.2 or earlier."
You can however use any Java, and stuff that is newer than 1,4, with
GWT server side code.
It looks like, from your stacktrace, that you are already aware of this
and have the JPA stuff in server side RPC code - but just in case I
will say it anyway, make sure all of your JPA stuff is in server side
code.
If your JPA and session facade for your entities is in server side
code, service servlets, etc, then it should work fine. If the problem
you are seeing happens in Hosted Mode, using the GWTShell, then you may
need to make sure that the development mode Tomcat instance (the one
GWT creates - look in your projects directory) has the drivers and
dependencies *it needs*. This one is a bit tricky with GWT, the
development mode tomcat will NOT (not automatically) get your web.xml
or context.xml from your application, so it will not have any Oracle or
other drivers. (You can pretty easily add them to the Tomcat
structure, or you can have build tools such as Ant or Maven automate
the process of setting up the Hosted Mode tomcat instance as well as
your deployable artifacts.)
Andrew Law
Cheers for the info and the help. I think I've done it how you propose
> It looks like, from your stacktrace, that you are already aware of this
> and have the JPA stuff in server side RPC code - but just in case I
> will say it anyway, make sure all of your JPA stuff is in server side
> code.
When you say "server side code" do you mean in the same project but in
the com.myorg.server package rather than the com.myorg.client package?
If so, yes I have done this. What I havn't done is package up the
server side bits and pre deploy them to another instance, but I don't
think this is what you mean.
>
> If your JPA and session facade for your entities is in server side
> code, service servlets, etc, then it should work fine. If the problem
> you are seeing happens in Hosted Mode, using the GWTShell, then you may
> need to make sure that the development mode Tomcat instance (the one
> GWT creates - look in your projects directory) has the drivers and
> dependencies *it needs*.
This is the situation where I am seeing the problem.
> This one is a bit tricky with GWT, the
> development mode tomcat will NOT (not automatically) get your web.xml
> or context.xml from your application, so it will not have any Oracle or
> other drivers. (You can pretty easily add them to the Tomcat
> structure, or you can have build tools such as Ant or Maven automate
> the process of setting up the Hosted Mode tomcat instance as well as
> your deployable artifacts.)
Am I correct in thinking that the "tomcat structure" you are referring
to is the ./tomcat directory that is created when I run in hosted mode?
If so, where within should I put my domain model .jar file (which
contains the persistence.xml file as well as the classes themselves) -
in ./tomcat/webapps/ROOT/WEB-INF/lib/ ?
Andrew Law
./tomcat/webapps/ROOT/WEB-INF/lib/) and I'm still getting the same
error. Is there anywhere I can look to get more of an understanding of
the embedded Tomcat and what I need to put where?
TIA
Regs, Andrew
charlie...@gmail.com
few days. Lame excuse, I know.
Anyhow, you are correct on all fronts with what I was saying. The
tomcat created as ./tomcat is the one you want to put datasource
drivers and such in. And ROOT/WEB-INF/lib should work for placement
of resources needed by the hosted mode dev server.
That said, you have apparently already figured all that out and stuff
is still broken.
I would try putting the GWT server side code in a different tomcat
instance, outside of hosted mode. What I mean is, take the GWT service
servlets, and a web.xml deployment descriptor that specifically defines
them (you have to get rid of the GWTShellServlet for actual deployment
and create servlet and servlet mappings, etc) and place them, along
with the needed classes and so on in a standard off the shelf tomcat.
Then hit the service servlets from a GWT client app that refers to that
*separate* outside of hosted mode Tomcat instance.
This may sound like a pain, but really it's a good habit to be in
anyway and may help solve this problem - I mention this path because if
you do this, you can control the classpath and ensure Java 5 is in
place, etc, easier than when working with the stripped down auto
generated tomcat structure for hosted mode (you can even have separate
GWT projects for your server vs client side code - with mock ups in the
client code - allowed in the gwt module file).
The tomcat GWT provides is really intended for client side code to host
simple HTML/JavaScript and to contain the GWTShellServlet which
automatically maps module defined service servlet entries (auto proxies
them if you will). When working with more complicated setups, such as
with JPA, etc, it might be a good idea to avoid the hosted mode tomcat
- unfortunately it is not really setup to easily accommodate that (it
could, but you would have to keep mucking with the classpath and such,
and you would have to do it every time you install your project on a
new dev machine, so on).
I know that's not really a direct answer to your question, but it may
help you get through the problem, and it's the way I like to approach
GWT server side resources in general anyway (mocks in the hosted mode,
mostly, separate actual container for server side stuff).
And on a side note, I have been working on a Maven 1.x plugin with a
few other folks that will sort of help with this. It will not help
setup the classpath on the hosted mode tomcat instance (that's still a
manual exercise - if you go that direction) - but it will allow you to
create a deployable "war" that you can just pop in an off the shelf
tomcat from a GWT project. In case you use Maven, and you happen to
still be using 1.x like myself - http://code.google.com/p/gwt-maven/
(the 2.x version is still in heavy dev at the moment).
Andrew Law
Excellent. Thanks very much for this. I haven't tried it yet but it
makes perfect sense. I'll also check out the maven plugin. 1.x is my
flavour of choice.
I'll get back to you once I've tried it out.
Regs, Andrew