[GLASSFISH-18805] Redeploying should not alter application startup order Created: 14/Jun/12  Updated: 10/Apr/13  Resolved: 10/Apr/13

Status: Resolved
Project: glassfish
Component/s: deployment
Affects Version/s: 3.1.2
Fix Version/s: 4.0_b84_RC1

Type: Improvement Priority: Major
Reporter: Paul Benedict Assignee: Hong Zhang
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Application load order is defined in domain.xml by the ordering of <application> tags. When I redeploy an app, the app's <application> tag moves to the bottom of the list.

I think this behavior should be changed.

Current behavior is very annoying since I must maintain a strict ordering of EJB applications. For example, C depends on B depends on A, with regard to EJB resources. Therefore, after I deploy, I must go in and manually edit domain.xml to keep my server working.



 Comments   
Comment by Jeremy_Lv [ 24/Oct/12 ]

Hong:
The logic about setting the properties to the domain.xml are as follows:
1).it will cleanup the properties about the redeployed applications by executing DeployCommand#execute

Properties undeployProps = handleRedeploy(name, report);

2).Then it will do the same operation as deploy does. After load the deployment application it will setting the properties to the domain.xml by executing DeployCommand#execute

deployment.registerAppInDomainXML(appInfo, deploymentContext, t);

All in all,I think it is hard to locate the app's <application> tag to the original position before redeploy. The reason is that there's no symbol to perserv when deleting the app's <application> tag from domain.xml.
BTW, If it is necessary to enhance this scenario, I will look into it and try to attach my patch as soon as possible.

Comment by Hong Zhang [ 24/Oct/12 ]

Right, when an application is redeployed, it's appended to the last in the list of the applications in domain.xml (that list determines the loading order of the application during server start up). In GlassFish 4.0, one of the features we will add is the deployment order feature which has been requested a couple times in the past. With that, user could specify a deployment order when the application is deployed, and the applications will be loaded based on the order. So user could use that feature to resolve this problem s/he has. We will mark this issue as fixed when that feature is available.

Comment by Jeremy_Lv [ 10/Apr/13 ]

Hong:

It seems the new features about deployment order has been developed by GeraldIngalls.

IMHO, I think the application can be deployed as asadmin deploy --deploymentorder 1 test_sample1.war.

However, when I was trying the deployment command with option as --deploymentorder, NPE will occurred as follows:

[2013-04-10T21:12:35.938+0800] [glassfish 4.0] [SEVERE] [NCLS-ADMIN-00011] [javax.enterprise.system.tools.admin.security.authorization] [tid: _ThreadID=38 _ThreadName=admin-listener(5)] [timeMillis: 1365599555938] [levelValue: 1000] [[
  An unexpected exception occurred.
java.lang.RuntimeException: java.lang.NullPointerException
	at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:314)
	at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:184)
	at com.sun.enterprise.admin.util.CommandSecurityChecker$1.run(CommandSecurityChecker.java:180)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:356)
	at com.sun.enterprise.admin.util.CommandSecurityChecker.authorize(CommandSecurityChecker.java:180)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1203)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1762)
	at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
	at org.glassfish.admin.rest.resources.admin.CommandResource.executeCommand(CommandResource.java:396)
	at org.glassfish.admin.rest.resources.admin.CommandResource.execCommandSimpInMultOut(CommandResource.java:234)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:125)
	at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:152)
	at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:91)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:346)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:341)
	at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:101)
	at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:217)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:231)
	at org.glassfish.jersey.internal.Errors$1.call(Errors.java:227)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:275)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:257)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:227)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
	at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:191)
	at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:819)
	at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:325)
	at org.glassfish.admin.rest.adapter.JerseyContainerCommandService$3.service(JerseyContainerCommandService.java:161)
	at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:181)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
	at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
	at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
	at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
	at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
	at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
	at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
	at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
	at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
	at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
	at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NullPointerException
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:581)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$ArchiveJarEntrySource.<init>(InputJarArchive.java:573)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.createEntryEnumeration(InputJarArchive.java:451)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.entries(InputJarArchive.java:203)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.access$100(InputJarArchive.java:74)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$1.enumeration(InputJarArchive.java:166)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive$CollectionWrappedEnumeration.<init>(InputJarArchive.java:724)
	at com.sun.enterprise.deployment.deploy.shared.InputJarArchive.getDirectories(InputJarArchive.java:161)
	at org.glassfish.javaee.full.deployment.EarDetector.isEARFromIntrospecting(EarDetector.java:142)
	at org.glassfish.javaee.full.deployment.EarDetector.handles(EarDetector.java:110)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.getArchiveHandler(ApplicationLifecycle.java:211)
	at org.glassfish.deployment.admin.DeployCommand.preAuthorization(DeployCommand.java:246)
	... 52 more
]]
Comment by Jeremy_Lv [ 10/Apr/13 ]

I think the NPE shouldn't come out even I type the wrong command..

Comment by Hong Zhang [ 10/Apr/13 ]

Jeremy: I could not reproduce this, what exact command did you use when you saw the NPE? From the stack trace, it seems unrelated to the deploymentorder option, but something with the archive itself. You can try to just use deploy command with no options to deploy the archive, see if you still get the error. We still need to make the deployment code more robust (no NPE, but a good error message) if the archive is not constructed properly, but that's another issue.

Comment by Jeremy_Lv [ 10/Apr/13 ]

Hong:

Sorry, it is my fault to use the invalid test case, the error cames out because of the OS can't extract the invalid war file.

Yeah, I can find some configuration about deploymentorder written in the domain.xml. But I still confused about the situation the deploymentorder can be of the same value between different applications.

Thanks

Jeremy

Comment by Hong Zhang [ 10/Apr/13 ]

No problem. For the applications which are deployed with the same deployment order (either explicitly or they just both use default), whichever is deployed first will be loaded first during server start up.

Please see the man page for more detailed explanation (do asadmin deploy --help).

And I am marking this issue as fixed as the deployment order feature is in GlassFish 4.0 now.

Comment by Jeremy_Lv [ 10/Apr/13 ]

I see. I got to know some detailed information about it through the deployment one pager.
https://wikis.oracle.com/display/GlassFish/GlassFish+4.0+Deployment+One+Pager#GlassFish4.0DeploymentOnePager-DeploymentOrder

Thanks

Generated at Sun Apr 26 05:48:19 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.