Deploy war through netbeans onto glassfish v3 beta - java

The same .war file deploys fine onto Glassfish v2.1. I don't know the last time I tried v3, but I was wanting to check out hot-deploy functionality as it's rumored to be working in netbeans 6.8 with glassfish v3. So, I deploy just like usual and I get the following error:
SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method
....
SEVERE: Exception while loading the app
java.lang.RuntimeException: Unable to load EJB module. DeploymentContext does not contain any EJB Check archive to ensure correct packaging for c:\src\svn\trunk\gui\target\WEBAPP
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:134)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:64)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:153)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:220)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:314)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:169)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1159)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1207)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:362)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:241)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:951)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.doWork(FixedThreadPool.java:431)
at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:410)
at java.lang.Thread.run(Thread.java:619)
I don't understand why it's complaining about anything EJB related since this is a .war file. Any ideas?
UPDATE: I filed a bug with glassfish: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592. Either this is a bug in glassfish or at the very least the error message is not helpful in tracking the problem down.

https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592
From the bug:
Ok, found the cause (thanks much for providing the test case!):
EjbSniffer was retrieved after scanning the archive: one (or more) of the
library jars packaged in the archive contains EJBs with component annotations.
So the ejb container was asked to load the module later.
The ejb container was not able to find the corresponding metadata because the
web.xml is 2.4 version so the meta-data processing skipped the annotation
processing (we only process annotations for Java EE 5+ schema versions).
After I changed the web.xml to reference 2.5 schema (you can do 3.0 schema as well):
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
The app deployed successfully.
Please give it a try and let me know if it works for you.

I have 3_0 schema and I still get the error. What's more interesting is I have two wars, one is the example project from weld archetype, and the other is a customization of that. The custom war doesn't work.
I've checked side by side, it's the same except for more model classes and more properties in persistence.xml

Someone using the #Stateless annotations in ManagedBeans is reporting a similar problem on the java.net Forums.
I don't know if this applies to you but the given workaround was:
Go to the admin console, go to the update center, and install EJB.
I didn't test it myself so I can't confirm this will help.

Just my $0.02...
I had the same error after I added the JaxMe library (version 0.5.2) to my application. This caused a deployment failure on one of my war modules - which confused the hell out of me, because I didn't make any changes to that module. Removing JaxMe fixed the problem.

Related

Class case exception in weblogic 12c

I deployed a web application to weblogic 12c. But I got the error in Oracle weblogic configuration shows as below:
**java.lang.ClassCastException: weblogic.j2ee.descriptor.wl.WeblogicApplicationBeanImpl cannot be cast to weblogic.j2ee.descriptor.wl.WeblogicWebAppBean**
I didn't experience the same issue with the older version of weblogic.
Can anybody suggest how can I fix this issue.
Check your descriptors: do they have namespaces defined?
For instance, if you use a weblogic-application.xml descriptor, the root element should be:
<weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application” etc.
The older Weblogic (11) was not as strict about this.
I hope this will help you.
Descriptor error comes only when you use the old or wrong descriptor in the xml files. This issue comes either with weblogic-application.xml or weblogic.xml..
Use the latest weblogic12c descriptor to get away from the issue.

NoSuchMethodError: org.hibernate.SessionFactory.openSession()

I'm having hibernate3.jar and hibernate-core-4.2.0.CR1.jar in my classpath and I'm using Spring 3.1.3 version. Code got compiles sucessfully but while runtime I'm getting following error
2014-10-28 10:51:25,174 DEBUG [RMI TCP Connection(2)-10.126.30.203] -
Target method failed for RemoteInvocation: method name
'getPriceByKeys'; parameter types [java.util.List, java.util.Date]
java.lang.NoSuchMethodError:
org.hibernate.SessionFactory.openSession()Lorg/hibernate/Session;
I google it but not find any solution. Please note : My project needs hibernate3.jar but at the same time my project dependent on some other 3rd party jar which inturn using hibernet4.2.0 jar.
Any help Pls ??
You need to remove multiple hibernate JAR files from your classpath. Without doing this, your application may not work as you expect; which means you need to migrate the hibernate version of your application from 3 to 4.1.
Although Spring 3.1 uses Hibernate 3 JAR files, you can still migrate to Hibernate 4. Check out Spring blog gives a small tutorial to do so.
Migrating to Spring 3.1 and Hibernate 4.1
As part of the Core-Spring course, we have a lab application that we
use to show how to integrate Spring and JPA/Hibernate together. We
have just upgraded it to Spring 3.1 / Hibernate 4.1, and thought we
should share a few tips.
Just an update. The cause of problem is , I'm having two spring-context xml files in project (one of my project and one related to another module that I'm integrating). I'm loading context xmls from two different classes. So one of the DAO class loaded by one of spring-context xml not getting the hibernate Session.
Later on using import tag, I included 2nd spring application context file in 1st application context file and then loaded a Single application context file from the class. It solved the error.
Thanks,

JSF 2.0 app under Tomcat 6: "No Factories configured."

I am trying to run a JSF 2.0 webapp using Apache MyFaces 2.1.7 on a Tomcat 6 webserver. The App uses Tomahawk 1.1.11 and expression language 2.2 (el-impl-2.2.jar). For that purpose I've put the myfaces-api and myfaces-impl into Tomcats lib folder and exchanged Tomcats el-api.jar for the 2.2 variant.
When I call the first page of the app I always get the error:
java.lang.IllegalStateException: No Factories configured for this Application. This
happens if the faces-initialization does not work at all - make sure that you properly
include all configuration settings necessary for a basic faces application and that all
the necessary libs are included. Also check the logging output of your web application
and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use
some special web-containers which do not support registering context-listeners via TLD
files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
javax.faces.FactoryFinder._getFactory(FactoryFinder.java:286)
javax.faces.FactoryFinder.getFactory(FactoryFinder.java:206)
javax.faces.webapp.FacesServlet.init(FacesServlet.java:116)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
java.lang.Thread.run(Thread.java:679)
I definitely have the xml snippet mentioned in my web.xml. I tried to debug into the code and found that registeredFactoryNames on line 267 of javax.faces.FactoryFinder is empty which causes the error. I however do not understand why this is the case. What should be in there and how do I get it there?
The funny thing is that the webapp runs perfectly using embedded jetty 8. So it must be some dependency issue.
Hope someone with more insight into all of this can help me here.
Ok
I found the problem. The error results from having the myfaces-api.jar twice on your classpath. So for me the problem was I placed the myfaces-api.jar in the tomcat lib folder and in the WEB-INF/lib folder of the webapp.
While using an embedded tomcat with maven I had the myfaces-api.jar in the dependencies of the whole application and in the dependencies of the tomcat6-maven-plugin with scope compile both. I changed the scope from compile to provided in the global dependencies section and it worked.
I think it could be solved just adding an empty faces-config.xml file under /WEB-INF/ folder, to indicate the application uses JSF and MyFaces continue the initialization step. See the class org.apache.myfaces.ee6.MyFacesContainerInitializer for details.

GWT with JPA - no persistence provider

GWT with JPA
There are two projects in my eclipse workspace, let's name them:
-JPAProject
-GWTProject
JPAProject contains JPA configuration stuff (persistence.xml, entity classes and so on). GWTProject is an examplary GWT project (taken from official GWT tutorial).
Both projects work fine alone. That is, I can create EMF (EntityManagerFactory) in JPAProject and get entities from the database. GWTProject works fine too, I can run it, fill the field text in the browser and get the response.
My goal is to call JPAProject from GWTProject to get entities. But the problem is that when calling DAO, I get the following exception:
[WARN] Server class 'com.emergit.service.dao.profile.ProfileDaoService' could not be found in the web app, but was found on the system classpath
[WARN] Adding classpath entry 'file:/home/maliniak/workspace/emergit/build/classes/' to the web app classpath for this session
[WARN] /gwttest/greet
javax.persistence.PersistenceException: No Persistence provider for EntityManager named emergitPU
at javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
at javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)
at com.emergit.service.dao.profile.JpaProfileDaoService.<init>(JpaProfileDaoService.java:19)
at pl.maliniak.server.GreetingServiceImpl.<init>(GreetingServiceImpl.java:21)
...
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
[ERROR] 500 - POST /gwttest/greet (127.0.0.1) 3812 bytes
I guess that the warnings at the beginning can be omitted for now.
Do you have any ideas? I guess I am missing some basic point. All hints are highly appreciated.
Update: My persistence provider is well defined, the JPA project works well by itself.
I guess it's classpath related problem too. When running the GWT project, in WEB-INF/lib there is only gwt-servlet.jar.
Do you think that making custom Ant file to build whole thing up is the only solution (i.e. make jar out of the JPA project and copying it to WEB-INF/lib)? Or is there any Eclipse solution, so I could set the GWT project properties properly so GWT project would know to include persistence.xml file?
Update: OK, I got it working. I tried to put persitence.xml everywhere in war/WEB-INF where it was possible, but kept getting 'no persistence provider' error. It turned out that it wasn't about persistence.xml. I didn't copy the eclipselink jar to WEB-INF/lib, so it couldn't find provider class defined in persistence.xml. Copying all the jars did the thing.
Thank you very much Pascal.
Struggling a lot with the same error message, I solved the problem with copying all jars (eclipselink.jar, eclipselink-jpa-modelgen_2.1.0.v20100614-r7608.jar, javax.persistence_1.0.0.jar, javax.persistence_2.0.1.v201006031150.jar) from the EclipseLink zip to the .../war/WEB-INF/lib folder of my GWT project to make everything available for the Jetty in hosted mode.
As you can see from the list of files, I was using EclipseLink 2.1. Please adapt this list to your JPA implementation, if necessary.
Hoping, that this may help you as well.
Do you have a persistence provider declared in your persistence.xml? Something like this (I'm using Hibernate here, adapt it to whatever persistence provider you're using):
<persistence
<persistence-unit name="emergitPU" transaction-type="...">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
...
</persistence-unit>
</persistence>
If you do, then I suspect a classpath problem. Did you package the JPA project correctly in the webapp i.e. in WEB-INF/lib?

java.util.zip.ZipException in Glassfish (v3) application deployment

I've got a strange exception with my EJB3.1 application, a ZipException is thrown during the application deployment:
[#|2010-05-15T16:01:44.688+0100|SEVERE|glassfish3.0.1|javax.enterprise.system.container.web.org.glassfish.web.loader|_ThreadID=22;_ThreadName=Thread-1;|WEB9051: Error trying to scan the classes at /Users/kevin/Documents/netbeans/WebAlbums/trunk/WebAlbums3/WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar for annotations in which a ServletContainerInitializer has expressed interest
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:114)
at java.util.jar.JarFile.<init>(JarFile.java:133)
at java.util.jar.JarFile.<init>(JarFile.java:70)
at org.glassfish.web.loader.ServletContainerInitializerUtil.getInitializerList(ServletContainerInitializerUtil.java:255)
at org.apache.catalina.core.StandardContext.callServletContainerInitializers(StandardContext.java:5331)
at com.sun.enterprise.web.WebModule.callServletContainerInitializers(WebModule.java:550)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5263)
at com.sun.enterprise.web.WebModule.start(WebModule.java:499)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:928)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:912)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:694)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1947)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1619)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:90)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:126)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:241)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:236)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:339)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:637)
|#]
I don't really know how to investigate this error; I know that it's not related to the Glassfish installation (same problem on Ubuntu and Mac).
EDIT:
(the classpath details seem to be useless)
the problem with .../WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar is that this file is not actually present where Glassfish is looking for it ...
Instead, I've got a folder named WebAlbums3-Service_jar
(I'm using Netbeans 6.8, Glassfish v3, Servlet3, EJB 3.1, JPA/Hibernate)
Thank you for your help
EDIT: The issue (both ZipException and already loaded EJBs) was resolved by extracting the EJB interfaces outside of where the implementation was defined (the implementation classes were loaded with each of the modules, hence the EJB exception)
I've seen several mentions of this problem on the web like this one that mentions it as non blocking:
If you get the following error after deploying the EAR, don't worry, it's quite normal: "WEB9051: Error trying to scan the classes at .../eclipseApps/Seven/SevenEJB.jar for annotations in which a ServletContainerInitializer has expressed interest". See here.
And also in Issue 11149 or Issue 11341. Your case seems to be different but if it's not (if you have a jar with a '+' in the file name) it should be fixed in GF v3.0.1.
If this doesn't apply to you, I suggest creating an issue. Even if non blocking, this is clearly not normal.
Error trying to scan the classes at /Users/kevin/Documents/netbeans/WebAlbums/trunk/WebAlbums3/WebAlbums3-ea/dist/gfdeploy/WebAlbums3-Service.jar for annotations in which a ServletContainerInitializer has expressed interest
java.util.zip.ZipException: error in opening zip file
Look like the JAR file is corrupted. Recompile/replace it. If you're FTP'ing this during deploying, take care that you send binary files as binary data, not as text data.
This can also be caused by the temp storage being full or not writable.
Update: Google learns me that this may also be JDK specific. Try upgrading JDK to the latest.
Can you open the zip-file with winzip or 7zip?
Can you open the file programmatically using ZipFile?
I am sure one of these questions will evaluate to false.
I had some strange zip errors some time ago related to special characters in the names of the contained file (where special means, non-ASCII characters).
Having an '_' instead of a '.' is normal when you use exploded deployment (that's how the exploded artifact is supposed to be deployed)
It may be "normal" but GF is looking for a myEJB.jar file that's not there. There's only an exploded artefact, which then doesn't get deployed.
The issue (both ZipException and already loaded EJBs) was resolved by extracting the EJB interfaces outside of where the implementation was defined (the implementation classes were loaded with each of the modules, hence the EJB exception)
Not sure I understand how this cures the above problem. My implementation class is a solitary message bean.

Categories