This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : 200905120201 ] [ JDK VERSION : 1.6.* ] Using GlassFish 2.1 external copy (i.e. not NetBeans bundled version). The server is registered with NetBeans. With dev builds from the last week or so (first noticed this on 05/07), I frequently see failures when deploying an enterprise app. If I go to the Services tab and undeploy the app from there, I can deploy normally. This is what I see in the output window: Building jar: /home/glennh/netbeans/phoenix/dist/phoenix.ear post-dist: dist-directory-deploy: pre-run-deploy: Distributing /home/glennh/netbeans/phoenix/dist/phoenix.ear to [localhost:4848_server] Start registering the project's server resources Finished registering server resources deployment started : 0% deployment finished : 100% Deploying application in domain completed successfully Rollback failed Trying to create reference for application in target server failed; Application reference phoenix already exists in server instance server. /home/glennh/netbeans/phoenix/nbproject/build-impl.xml:275: The module has not been deployed. BUILD FAILED (total time: 23 seconds)
I have seen things like this, but have never been able to reproduce it at will. That means that getting the server's log file is going to be critical for doing the analysis. If you could attach the ear or projects necessary to create the ear would be awesome, but obviously may be impossible in this forum. A description of the content of the ear would be better than nothing.
Created attachment 82319 [details] NetBeans log file
Created attachment 82320 [details] GlassFish server log
I've attached the NetBeans and GlassFish log files right after an occurrence. The project is an enterprise app with EJB module and two WAR modules, being deployed to an external copy of GlassFish 2.1 (i.e. not the one bundled with NetBeans). If I go to the Servers node in the Services tab in NetBeans and undeploy the app from there first (or from the GlassFish admin app), I can then deploy successfully. This extra step was not necessary until recently.
Are you deploying onto a 'cluster' profile server or a developer profile server? How have you registered this 'external' server.... as a remote server?
Developer profile. Not sure about your second question; by "external" I mean outside of NetBeans; the server is running on the same machine as NetBeans. I've attached a screenshot of the config dialog.
Created attachment 82325 [details] screenshot of config dialog
Created attachment 82327 [details] config dialog (re-attached with correct MIME type)
It looks like you have registered the external server as a remote server... Did you install this external server as root (or some other user id)? If you installed this external server with your regular user id, you may want to consider registering it 'the normal way'... 1. Enter the path to the installation directory of the server bits that has the domain... do not use the 'pre-filled' value of the field... 2. select the domain from the combo box of local default domains... I will be able to use the info you have given me so far to get started on analysis. I am going to treat this as a p2 issue.
GlassFish is in /usr/share/glassfish, which is owned by user glassfish and group glassfish, writable by user and group. I am running NetBeans as myself, and my user is in the glassfish group, but NetBeans shows me "No registerable default domains available. Check permissions". My domain is in /usr/share/glassfish/domains/shadow. This is why I set it up on localhost:4848.
I have not been able to reproduce this issue. Based on the content of the log, this is a random problem.... but it is reproducible once you encounter it, right? Are you using Deploy or Run on the project when you encounter this problem? It looks like the undeploy of the app fails and the domain.xml is left in an inconsistent state... That is hard to fix from the IDE. I did notice that most of these problems happen after an ST that involves this 'root'.... at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:16) at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.renderCycle(ReceiveSendUpdates.java:114) at com.icesoft.faces.webapp.http.core.ReceiveSendUpdates.service(ReceiveSendUpdates.java:66) at com.icesoft.faces.webapp.http.core.RequestVerifier.service(RequestVerifier.java:28) at com.icesoft.faces.webapp.http.common.standard.PathDispatcherServer.service(PathDispatcherServer.java:24) at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:160) at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$1.service(SessionDispatcher.java:42) at com.icesoft.faces.webapp.http.servlet.GlassFishAdaptingServlet.service(GlassFishAdaptingServlet.java:60) at com.icesoft.faces.webapp.http.servlet.EnvironmentAdaptingServlet.service(EnvironmentAdaptingServlet.java:63) at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:62) at com.icesoft.faces.webapp.http.servlet.SessionVerifier.service(SessionVerifier.java:22) at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:23) at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:153) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:56) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:333) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:313) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:199) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:282) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:754) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:684) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:682) at java.lang.Thread.run(Thread.java:619) Can you try an experiment... after you do something in your app that triggers an ST like these, try to redeploy the ear using the asadmin command, instead of the IDE...
Reproducible once it occurs, yes. Happened just now, but without any stack trace. Using "Deploy" context menu item on main project (blue triangle icon). "asadmin deploy <ear-name>" works after this happens (without --force argument). So does deploy from NetBeans Services pane or either GlassFish admin webapp.
make an honest value of the TM
Vince, why this issue is marked as INCOMPLETE?
i forgot to unset it...
Glenn: are you still running into this?
No, haven't seen it in some time.
okay. I am going to drop this to p3 and keep an eye open for it...
pushing down to p4. Have not been able to replicate lately and reporter has not seen it recently either.
closing as works for me. open a new issue if you run into something like this again