I've created a Dynamic Web Project in Eclipse. I have 2 beans, 1 #Entity and the other #Stateless. I've deployed the war to Geronimo 2.2.1 with Tomcat 6 with a warning:
Unresolved ejb reference "com.myconnection.servlet.AddServlet/srvc" in bean
"GeronimoEnc". Will attempt resolution again at runtime.
I have a form on a .jsp with an action to a servlet (AddServlet). The servlet is trying to reference my #Stateless bean (via interface). However, once I hit submit on my form to go to the servlet, I get this error:
java.lang.InstantiationException: Some objects to be injected were not found in jndi:
[javax.naming.NameNotFoundException: No EJB found for reference "com.
I also have my persistence.xml file in src/META-INF, I'm not positive if that's where it should be.
What could I be doing wrong? Thanks
Support for deploying WAR files with EJBs is fixed (but possibly not available; see the following text) in Geronimo 3.0, going by bug report 5117. Going by this report, dependency injection in 2.2.1 is likely to fail.
There is one report on the mailing list, suggesting that Geronimo 3.0 M1 might be used for validating whether dependency injection works for EJBs deployed in a web-application; this is however against a query raised with respect to a failure on the same topic. Reproducing the salient contents of the mail:
Łukasz:
Geronimo is not able to inject #EJB
into a servlet. Both SLSB and my
serlvet are packaged in war. ... By
looking at the release notes I know
that EJB 3.1 is supported only
partially. I take it that the part
that is not yet implemented in
deploying EJBs inside war package?
Ivan:
Hmm, IIRC, the EJB injection should
work in the M1 release, although it
have some bugs in EJB 3.1
integration. I would suggest to use
the latest trunk codes (just update
some codes to try to work around the
address binding issue on the building
machine, hopefully a snapshot build
could be generated in the next round),
as we got a much better TCK result
comparing with M1 release. JCDI
related packages are definitely
included in the latest trunk build.
Going all of the above, 3.0 M1 would be the release to attempt this at the moment, but there is surely some possibility of this feature being absent (given that bug 5117 does not appeared to be in the list of fixed bugs in the release notes).
Related
I'm trying to troubleshoot a GWT-based app I'm writing in Eclipse. It currently uses Spring Framework 3.1.1 and Hibernate 4.1.6 on the back-end side. I'm currently having troubles with the dreaded "javax.validation.ValidationException: Unable to find a default provider" that seems to plague a lot of folks but is caused by different problems. I've tried the various solutions of using different versions of the JSR 303 implementation (e.g. diff. versions of Hibernate Validator) but it doesn't seem to make a difference.
And after debugging, I'm seeing why. Once execution gets to javax.validation.Validation.getValidationProviders():317 (in validation-api-1.0.0.GA), the app (running on an Eclipse internal Jetty server) attempts to read the META-INF/services/javax.validation.spi.ValidationProvider resource from the classpath and comes back empty. I am absolutely certain that the different validator implementations I've put (e.g. hibernate-validator-4.3.0.Final.jar) have that resource and it does contain a value (e.g. org.hibernate.validator.HibernateValidator), but is not appearing to the classloader in question. The way I've included the JAR in the classpath is by adding it to the project's Build Path which seems to add it to the Jetty runtime when I execute the applications.
My question is: Is there a way to view the classpath in Eclipse debug mode visible to a certain classloader? Secondly, does anyone know why the Hibernate Validator's resource is not first and foremost in the classloader that Validation is using?
The webapp classpath is composed by the directory WEB-INF/classes and by all the jars in WEB-INF/lib. If you want a jar to be available at runtime, you must NOT add it to the build path, but to WEB-INF/lib.
Dropping a jar in WebContent/WEB-INF/lib in Eclipse will make it automatically part of the buid path of your webapp, and available at runtime.
I'm just about migrating from JBoss 6.1 to Glassfish 3.1 (don't ask why). The following occurs:
Invalid ejb jar [mmsUserMgmtAct-0.0.1-SNAPSHOT.jar]: it contains zero ejb
...
Note:
1. A valid ejb jar requires at least one session, entity (1.x/2.x style), or message-
driven bean.
2. EJB3+ entity beans (#Entity) are POJOs and please package them as library jar.
3. If the jar file contains valid EJBs which are annotated with EJB component level
annotations (#Stateless, #Stateful, #MessageDriven, #Singleton), please check server.log
to see whether the annotations were processed properly.
As everything was running perfectly with Jboss I can swear there are EJBs within the jars. The only thing which might cause the error is the fact, that I splitted the interfaces (#Remote and #Local) plus the entities (#Entity) into a package xyzService.jar and the stateless bean (#Stateless, #Remote(XyzService.class)) into another archive named xyzServiceImpl.jar.
All packaging was generated by maven, so no issues with this. Maybe I should mention that I simply copied the things into autodeploy folder.
Any glues?
Thx in advance
El Subcomandante
After reading about it for so long, I now have chance to get my hand dirty with EJB. I use Glassfish+Eclipse 3.7 on Ubuntu.
I first created an EJB that just returns a greeting message. Then I create the application client to access this EJB using InitialContext. This works exactly like expected.
Then, I created a servlet to access to that EJB. Neither access with #EJB nor InitialContext works.
When I use #EJB, the 404 page appear with this description: "The requested resource () is not available."
When I use InitialContent, an ClassNotFoundException is thrown. Apparently, the class loader of the servlet cannot access to the EJB class. I tried to add EJB jar file to the servlet's lib folder and I got the error message that the JNDI name already exists. Apparently, Glass Fish tries publish the EJB in the Servlet's lib folder too.
The only way to get this to work is to publish the EJB with the servlet. This way, both I can get the servlet and a stand-alone application to access to that EJB. The problem is that I need to always employ the servlet with the EJB which is not desirable since my client may not want to use web front end.
Anyway, my question is what is appropriate way to have the servlet access to the EJB employed outside its class loader without repeatedly publishing the EJB.
P.S. It is also possible that the problem might be the way Eclipse configure and employ those components.
Thank a lot for any helps.
Perhaps you need to treat the EJB component as if it were remote. And maybe it really is since you don't give a lot of detail on how you are deploying. Try the directions at http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#nonJavaEEwebcontainerRemoteEJB.
A few pointers:
you may need to put the webapp and the ejb-jar in an .ear (enterprise application) and deploy it to glassfish
you may need the remote interfaces on the classpath of the webapp (if they are not available at runtime, but they were at compile time, you can't expect it to work)
NetBeans is generally better with enterprise stuff and wizards for creating and deploying applications. Give it a try.
After try out a while, I found that I can do by referring it as "/". This even works with injection.
I try to create JPA persistency module and access it from OSGI WAB in glassfish 3.1.
The way to do it in non-OSGI WAR is to copy the persistency jar into WAR.
However when I deploy the OSGI WAB with jpa jar, I get the exception:
[#|2011-02-01T18:29:10.035+0200|SEVERE|glassfish3.1|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-1;|java.lang.RuntimeException: java.util.zip.ZipException: duplicate entry: META-INF/maven/com.test/test-web/pom.properties
at org.glassfish.osgijavaeebase.OSGiBundleArchive$1.run(OSGiBundleArchive.java:366)
Should the JPA jar contain some special entries in a manifest? It must be defined as OSGI bundle? Please consult.
Update:
The issues was resolved:
To avoid ZipException, I removed the "." from Bundle-Classpath in bundle Manifest.
To get more detailed logs with exceptions, I upgraded Glassfish 3.1 build to 41 (I was working with build 35).
JPA with Hibernate inside bundle started to work after I fixed several classpath problems
To use JPA in a WAB, you just have to drop the persistence jar containing entities and persistence.xml in WEB-INF/lib/ of your WAB. Tell us how the Bundle-ClassPath manifest entry in the WAB looks like. I don't watch this forum; I watch glassfish forum. Can you post your question at users#glassfish.java.net if you want faster response?
Does anyone know any sane reason for such bundling decision? Google engineers act wisely in most cases, so this kinda surprized me.
This would cause collisions with other versions of servlet API pulled via Maven dependencies:
webapp classpath will likely contain
version which is bundled with GWT;
container may refuse to load the GWT
jar as it contains the javax.servlet
package;
in most cases this will
likely deviate classpaths across your
IDE's debugger and the really
executing VM.
Link to the jar in question (just so you see the same thing after unzipping as I do, if you don't believe that GWT contains servlet API classes in the same jar):
http://repo1.maven.org/maven2/com/google/gwt/gwt-user/1.7.0/gwt-user-1.7.0.jar
You shouldn't be including gwt-dev.jar or gwt-user.jar in your war file. You only need gwt-servlet.jar in your war, and that too only if you are using RPC. If you notice, gwt-servlet.jar (ironically) does not contain any of the servlet classes.
gwt-dev.jar contains the compilers and linkers. Your code will never need this to compile.
gwt-user.jar contains the gwt framework that ultimately gets translated to javascript. You only need this during development mode.
gwt-servlet.jar contains the server side code that is needed if you use RPC framework. This is the only jar that should be present in your war file.
The reason the classes are in the package is to provide a full working solution for users who only use the gwt-user file in development. Without it GWT RPC wouldn't compile. This is/was the general view of the GWT team as can be found in this lively discussion on the GWT issue tracker: http://code.google.com/p/google-web-toolkit/issues/detail?id=3851
However, GWT 1.7 also contains the javax source files, which can cause additional problems. For example for maven and probably also for the points you mention. This was addressed in the GWT issue and in later version of GWT the javax source files have been removed from the gwt-user jar file.
For deployment you should use the gwt-servlet jar, which doesn't contain the javax classes or any other third party libraries. In the past several it could happen GWT files designed for client side use also used on the server side were missing from the gwt-servlet jar file. Losts of these issues have been addressed and classes were added to the servlet jar file. If you still find a GWT class you need is missing from the gwt-servlet you should file an issue report. In your case, assuming you're using 1.7, it might mean to upgrade to a newer version of GWT.