I'm in the process of upgrading our applicaiton from 4.0.4 to 7.1.1. So far things have been going well, considering the chasm between versions.
We have a a fair number of 2.1 EJBs. We have a couple of sub-projects which each produce thier own jars/EJBs. Some of the sub-projects provide common libraries/services We have a couple of "top-level" projects / applications which depend on those those libraries/services In each project, there is an "-ejb.jar" which has just DDs for the EJB classes which live in a peer jar (legacy reason for that).
I've been trying to work out what the best way to package everything up and would really appreciate some input. Here's what I have now. I'm using the <initialize-in-order> tag in the application.xml to ensure the jar with all of the .classes deploys first.
- lib/thirdParty.jar* (many of these)
- common-ejb.jar (just EJB2.x deployment descriptors)
-MANFEST.mf has "deployment.common.ear export, deployment.common.jar export"
- MANIFEST.mf has "deployment.core.jar" (I've also tried adding deployment.core.ear)
This works (deploys at least) if I manually control the order (common, core, application), but if I just let JBoss start on it's own, applicaiton.ear will complain that the common.ear is not found. I was expecting that by adding the dependencies between the deployments it would control ordering. What am I doing wrong? Is there a better way to structure things?
Small nit, but why do I seem to need to specify both the toplevel ear (to pick up the lib) and the individual jars inside of it? It seems like application A shouldn't (have to) know about the internals of application B.
I imagine I could just dump all of this in a single ear and get it to work, but that doesn't seem right. Then I need to repear that whole structrue for applications qrs and xyz, I'd prefer that each sub-project was self contained and could just specificy what it's depencies are.
Thank you fellow JBossers...