When I try to run my Java EE program in Netbeans consisting of servlets (java pages), JSP's, beans(java pages) and HTML pages I get this error in the output:
In-place deployment at C:\Users\Derek\Documents\NetBeansProjects\EJBProject\EJBProject-war\build\web
Initializing...
deploy?path=C:\Users\Derek\Documents\NetBeansProjects\EJBProject\EJBProject-war\build\web&name=EJBProject-war&force=true failed on Personal GlassFish v3 Domain
C:\Users\Derek\Documents\NetBeansProjects\EJBProject\EJBProject-war\nbproject\build-impl.xml:611: The module has not been deployed.
BUILD FAILED (total time: 1 second)
And then in the command prompt when I run asant run in the appropriate directory, I get:
C:\Users\Derek\Documents\NetBeansProjects\EJBProject\nbproject\build-impl.xml:19: Class org.apache.tools.ant.taskdefs.condition.Not doesn't support the nested "antversion" element.
Do you know why this would be? Why won't netbeans deploy my application so I can run and test it?
EDIT:
ant version is actually came up with...
Apache Ant version 1.6.5 compiled on June 2 2005
The glassfish output logs say:
SEVERE: Exception while loading the app
java.lang.RuntimeException: EJB Container initialization error
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:219)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:197)
at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:63)
at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
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:619)
Caused by: java.lang.RuntimeException: Error while binding JNDI name x.results#x.results for EJB : resultsBean
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1530)
at com.sun.ejb.containers.StatefulSessionContainer.initializeHome(StatefulSessionContainer.java:214)
at com.sun.ejb.containers.ContainerFactoryImpl.createContainer(ContainerFactoryImpl.java:161)
at org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:207)
... 32 more
Caused by: javax.naming.NameAlreadyBoundException: Use rebind to override
at com.sun.enterprise.naming.impl.TransientContext.doBindOrRebind(TransientContext.java:275)
at com.sun.enterprise.naming.impl.TransientContext.bind(TransientContext.java:214)
at com.sun.enterprise.naming.impl.SerialContextProviderImpl.bind(SerialContextProviderImpl.java:79)
at com.sun.enterprise.naming.impl.LocalSerialContextProviderImpl.bind(LocalSerialContextProviderImpl.java:81)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:586)
at com.sun.enterprise.naming.impl.SerialContext.bind(SerialContext.java:602)
at javax.naming.InitialContext.bind(InitialContext.java:404)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:206)
at com.sun.enterprise.naming.impl.GlassfishNamingManagerImpl.publishObject(GlassfishNamingManagerImpl.java:187)
at com.sun.ejb.containers.BaseContainer$JndiInfo.publish(BaseContainer.java:5484)
at com.sun.ejb.containers.BaseContainer.initializeHome(BaseContainer.java:1515)
EDIT:
It seems to be regarding my 'stateful' session bean, as when I delete it, it runs perfectly.
My best guess is that you downloaded and installed the 'Web Profile' of GlassFish Server 3 OR you have created a web app that has a deployment descriptor that forces the server to treat it as a Java EE 5 (or even J2EE 1.4) and then created an EJB in that web app... which would probably lead to these sorts of errors.
It seems you have some fields on your Stateful session bean that may have the same name of another Stateful Session bean fields. It just a guess. There is no much info about your EJBS to make a deep analysis. Hope it helps
Related
After ensuring that all the libraries (only newer) seemed to exist on Wildfly 9, and checking the RestEasy migration page, I tried to deploy an app that works find on AS 7.1.1 (uses Resteasy 2.3.2) to WF9 (Resteasy 3.0.11) but it was unable to deploy due to this error:
Caused by: java.lang.NoClassDefFoundError: org/jboss/resteasy/core/ResourceMethod
Caused by: java.lang.ClassNotFoundException: org.jboss.resteasy.core.ResourceMethod from [Module \\\"deployment.CodecMapper.war:main\\\" from Service Module Loader]\"}}"
I jarfinded the class and looked in the catalog of resteasy-jaxrs-3.0.11-Final.jar but didn't find it (it was in the 2.3.2 version). Is it in a new jar or failed dependency? Or is this a migration issue I'll need to address in my code (even though it's not listed as one on the Resteasy migration page)?
I have also reviewed the Wildfly migration page specific to Resteasy, but I don't see any changes required.
I'm trying to make new icefaces project which generated using: ICEfaces 3.3.0 project integration for Eclipse.
I didn't modify anything on the project. but when i try to run on the server, i got an error:
cannot Deploy MyProject
Deployment Error for module: MyProject:
Exception while loading the app : java.lang.Exception:
java.lang.IllegalStateException: ContainerBase.addChild:
start: org.apache.catalina.LifecycleException:
java.lang.NoSuchFieldError: SKIP_ITERATION
before that, I'm using ICEfaces 3.2.0 project integration for Eclipse and no problem.
I'm using Eclipse Indigo, GlassFish server 3, Mojarra 2.1.6
Thanks before
java.lang.NoSuchFieldError: SKIP_ITERATION
As per the javadoc, that field was added in JSF 2.1.
So, this error suggests that your webapp's runtime classpath is polluted with a JSF 2.0 API JAR file. Perhaps in the /WEB-INF/lib? Get rid of it. Glassfish already ships with JSF bundled, you don't necessarily need to supply your own. Or, from the other side on, this can also happen if you deploy to an ancient Glassfish instance which bundles JSF 2.0 and JSF 2.1 was actually bundled in your webapp in an attempt to upgrade it. If so, then you should edited the Glassfish config file sun-web.xml or glassfish-web.xml, depending on GF version. See for detail the answer to this related question: How to update Mojarra version in GlassFish
I have a generated jax-ws web service client that runs fine when I run it as a java standalone project. However if I add it to a web application (war) deployed on JBoss 7.1.1 and call the web service it throws the following exception:
Caused by: java.lang.NoClassDefFoundError: com/ctc/wstx/io/DefaultInputResolver
at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:628)
at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:139) [jboss-modules.jar:1.1.1.GA]
at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1176)
at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:104)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:795)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1626)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1493)
at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1401)
at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:648)
at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263)
at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:531)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:461)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:364)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:317)
at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
at $Proxy189.getcodelists(Unknown Source)
Idea what I may be missing?
As the error says, the App server is unable to find the said class file. Is it possible in your standalone app your classpath has the library but JBoss AS 7 is unable to find it.
If you can isolate where this library is, you can either bundle it with your WAR file or create a jboss_module to satisfy the dependency.
Good luck!
I want to use Atmosphere XMPP but i need to load native connector APR. I am not very familiar as of yet with JBoss 7 so i was wondering if anyone knows how to do this? WIndows x64 or Linux x64 environment. Doesn't matter. Thanks
Assuming Linux x64 here. I am using Ubuntu 11.04 x64.
Download JBoss7 distribution and unzip it to a suitable directory ( from here I am assuming that you have it in your '/home/myname/tools/jboss701/' folder.
Start it using /jboss701/bin/standalone.sh and verify that it started properly ( check localhost:8080 url). Close the jboss for now.
Download the native libraries from here http://www.jboss.org/jbossweb/downloads/jboss-native-2-0-9.html . I have downloaded this one jboss-native-2.0.9-linux2-x64-ssl.tar.gz
Unpack it to the '/home/myname/tools/jboss701/' folder. You should see the contents of the archive in '/home/myname/tools/jboss701/bin' folder. Also, verify that you have 'native' folder under the '/home/myname/tools/jboss701/bin'
IMPORTANT: unfortunately, it doesn't work out of the box. You must make the following change: add the
JAVA_OPTS="$JAVA_OPTS
-Djava.library.path=/home/myname/tools/jboss701/bin/native:$PATH"
string to your 'standalone.conf' file.
Start JBoss with the 'standalone.sh' script. Verify that you have the following line in the console during the JBoss startup: 'org.apache.coyote.http11.Http11AprProtocol'. If you see 'org.apache.coyote.http11.Http11AprProtocol' instead of 'org.apache.coyote.http11.Http11Protocol' then everything is working as expected.
Thanks man, i got it working. I do see these lines now in my startup script. `15:13:09,687 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-7) An older version 1.1.20 of the Apache Tomcat Native li
brary is installed, while Tomcat recommends version greater then 1.1.21
15:13:11,110 INFO [org.apache.coyote.http11.Http11AprProtocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080` Atmosphere unforunately, is still throwing the same error.
java.lang.IllegalStateException: JBoss failed to detect this is a Comet application because the APR Connector is not enabled.
Make sure atmosphere-compat-jboss.jar is not under your WEB-INF/lib and
there is no context.xml under WEB-INF
org.atmosphere.container.JBossWebCometSupport.<clinit>(JBossWebCometSupport.java:66)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
org.atmosphere.cpr.DefaultCometSupportResolver.newCometSupport(DefaultCometSupportResolver.java:178)
org.atmosphere.cpr.DefaultCometSupportResolver.resolveWebSocket(DefaultCometSupportResolver.java:223)
org.atmosphere.cpr.DefaultCometSupportResolver.resolve(DefaultCometSupportResolver.java:217)
org.atmosphere.cpr.AtmosphereServlet.autoDetectContainer(AtmosphereServlet.java:900)
org.atmosphere.cpr.AtmosphereServlet.init(AtmosphereServlet.java:530)
org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70)
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
java.lang.Thread.run(Thread.java:662)
I've set everything up as in the demos. too
I've created a very simple "Enterprise Application" project with about 7 entity beans and one stateless session bean. I've also configured an instance of Glassfish v3 to run as my application server. Unfortunately, when I attempt to publish the EAR to Glassfish, I'm getting the following response:
SEVERE: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
java.lang.NullPointerException
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:104)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:644)
at org.glassfish.javaee.full.deployment.EarDeployer.prepareBundle(EarDeployer.java:269)
at org.glassfish.javaee.full.deployment.EarDeployer.access$200(EarDeployer.java:79)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:131)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:129)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnBundles(EarDeployer.java:197)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllTypedBundles(EarDeployer.java:206)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllBundles(EarDeployer.java:232)
at org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:129)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:644)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:296)
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)
This NPE looks somehow close to Issue # 11387 (it's not exactly the same issue but it could be the same cause... or another bug in the deployment subcomponent). My suggestions would thus be to:
Try with a recent nightly build (the mentioned issue has been fixed 3 days ago in the trunk and I didn't look closely enough to confirm it's completely unrelated).
Fill a new issue with the stack trace and your ear ideally if the issue is still there.