I guess if you would *really* want explicit ordering you could patch the FileSystemDeploymentService and sort either the List<ScannerTask> scannerTasks in the ScanContext (or the resulting List<ModelNode> updates) based on some properties file containing the name of the deployments. You might also have to strangle the scheduledExecutor to handle only one operation at the time (or do sequential execute via some other route). And it will of course only work for standalone servers.
The scanner is in https://github.com/jbossas/jboss-as/blob/master/deployment-scanner/src/main/java/org/jboss/as/server/deployment/scanner/FileSystemDeploymentService.java (quite a largeish file)
Thanks Jason for replying to my question.
I cant do the EAR ...Let me give you some background, we have multiple portlets deployed as WARs and some PU deployed as jar. This PUs are shared by all the WARs.
I can't bundle all of these in to one EAR as in our PROD this portlets have deployed/re-deployed individually based on their release cycle. If we end-up making one big EAR this individual deployment wont be possible.
My hands are tied from all sides ...
Is there any way I control the order of deployment and have Jboss deploy all the jars first and then move on to WARs?
If you want to get really fancy, you could have an interface with sort(List<ScannerTask>) and then people can drop in Service-activated jars with various implementations like PropertyFileSorter, AlphabeticSorter, JarsFirstSorter etc. If no implementation would be found, the deployment would work as current, otherwise, the sorter would be called and deployment would be sequential. Or the deployer could have an attribute for scannerTaskSorter="com.acme.MySorter".
There is also a workaround using modules passed in the linked feature request.
I tried the workaround discussed on AS7-1769 and it did solve the issue but I don't understand how it solved the issue. I feel that the issue discussed in AS7-1769 and the issue that I am have are different, let me explain.
I have the following components
1. account-PU.jar (This registers the EM in the JNDI jndi-name="java:/web-configdb")
"myaccount-portlet.war" has the spring xml which has the following beans
<jee:jndi-lookup id="configDB" jndi-name="java:/web-configdb" lookup-on-startup="false" proxy-interface="javax.persistence.EntityManagerFactory"/>
<bean id="monitorDAC" class="com.myapplication.MonitorDACImpl" /> - DAC impl class which has the annotation @PersistenceContext(unitName = "configDB")
Scenario - 1: I have only "account-PU.jar" in the deployment folder and start the server the PU starts fine and once the server starts completely, I deploy "myaccount-portlet.war" it deploys perfectly fine and I am able to access myaccount portlet
Scenario - 2: I have both "account-PU.jar" & "myaccount-portlet.war" present under deployment folder and start the server and I get the following error.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'accountDAC': Injection of persistence dependencies failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'configDB': Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: Error looking up web-configdb, service service jboss.naming.context.java.web-configdb is not started
Now based on the NameNotFoundException i believe that in scenario-2 myaccount-portlet.war deployed first even before PU created the JNDI and fails.
Now what I don't understand is that, I am NOT getting any class not found exception as discussed in AS7-1769 but how come the the workaround sloved Scenario-2?
What does the workaround do to delay the JNDI creation from the PU in Scenario-2?
I will really appreciate if you can throw some points.
Even after applying the workaround specified in "AS7-1769" I still got the issue, but it was not consistent. Also my team wasn't really happy to add the entity classes to hibernate module as it will take away the dynamic deployment of the any changes to the entities in future releases.
So I took the advice from "Nicklas" and patched the https://github.com/jbossas/jboss-as/blob/master/deployment-scanner/src/main/java/org/jboss/as/server/deployment/scanner/FileSystemDeploymentService.java to deploy only the entities first and ignore the portlets on the first round, then the scanner will run again and deploy the portlets in the second round. This will guarantee that the entities are deployed & ready to use before the portlets are deployed.
This patch seems to work now. Thanks to all for your help.
Glad I could help. Since this requirement pops up from time to time, it would be handy if there would be some mechanism in the AS that could be activated that would provide this sequential deployment. Perhaps worth a feature JIRA.