History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JEEAS-180
Type: Bug Bug
Status: Resolved Resolved
Resolution: Duplicate
Priority: Major Major
Assignee: Martin Fuhrer
Reporter: Arun Gupta
Votes: 9
Watchers: 9
Operations

If you were logged in you would be able to see more operations.
JEE Application Servers

Redploying an application to GlassFish throws Exception

Created: 09 Jul 08 23:51   Updated: 14 Apr 09 01:48
Component/s: Glassfish
Affects Version/s: None
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. Zip Archive GlassFishRocks.zip (9 kb)

Environment: Mac OSX 10.5.x / Intel-based
Issue Links:
Duplicate
This issue duplicates:
JEEAS-192 Deploy without undeploy should either... Normal Resolved
 


 Description  « Hide
Redploying an application on GlassFish v2 UR2 throws an exception:

[#|2008-07-09T12:15:56.499-0700|WARNING|sun-appserver9.1|javax.enterprise.system.tools.admin|_ThreadID=18;_ThreadName=httpWorkerThread-4848-1;_RequestID=0d06f54e-b551-45e6-be37-4ec7b65a9136;|ADM1082:Creating
the application reference failed - Detailed Message:
com.sun.enterprise.deployment.backend.IASDeploymentException:
Application reference GlassFishWSWeb already exists in server instance
server.
at
com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.getAndValidateDeploymentTarget(DeploymentServiceUtils.java:1212)
at
com.sun.enterprise.deployment.phasing.PEDeploymentService.associate(PEDeploymentService.java:452)
at
com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.createApplicationReference(ApplicationsConfigMBean.java:693)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at
com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at
com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)

It seems the right deploy sequence is not being called. More details/discussion at:

https://glassfish.dev.java.net/servlets/ReadMsg?list=dev&msgNo=7572



 All   Comments   Work Log   Change History      Sort Order:
Martin Fuhrer - 05 Aug 08 18:42
I didn't manage to reproduce this problem, redeploying works fine here. Do you have any further information on how to reproduce it?

Corporate Gadfly - 29 Aug 08 21:05

Martin Fuhrer - 05 Aug 08 18:42
I didn't manage to reproduce this problem, redeploying works fine here. Do you have any further information on how to reproduce it?

Sample project to demonstrate the re-deploy problem. Any changes to HelloServlet do not show up until the Web Facet is undeployed and deployed. Changes to index.jsp show up fine during a re-deploy. Of course, the aforementioned warning always appears in the Glassfish Log tab. I'm using IntelliJ build 8733.

I followed directions at:
http://weblogs.java.net/blog/arungupta/archive/2008/07/getting_started_4.html
to create the project.


Jim Driscoll - 18 Oct 08 01:03
I'm also seeing this issue, with the same error, on both GFv2 and GFv3, using the latest (Diana) build.

M.J.Milicevic - 27 Nov 08 20:35
quite easy to reproduce on any remote glassfish configuration. Deploy an application, restart glassfish, connect intellij debugger to it.

Last thing is very anoying, because, even if I stated to never deploy an app , without my knowing, (on rebuild etc.) when I connect with debugger, intellij automatically deploys my app.


J. Brisbin - 14 Apr 09 01:48
This is a frustrating issue. It takes forever for Glassfish v2 to restart, which is the only solution I've found for when this starts doing this. I'm using build 9805 (Diana) and I see this problem whenever the previous deployment failed. If I make a mistake in my spring config file (which causes an unsuccessful deployment) and hit Shift-F9, it will refuse to deploy thereafter. If the deployment is clean, however, it seems to let you keep deploying. Once it has given this error message, it never recovers until a restart.