was Re: [jBoss-Dev] Proposed refactoring of ContainerFactory-Ch 
ainingDeployment services in general

To me it sounds like we're after two things re: the above thread:
1) Class consistency.
2) Bean dependencies between EAR files

1) is a tree. 2) is a general graph, possibly containing cycles.

IMHO, 1) should be done by being able to determine the parent
application as outlined in previous post.
2) is done simply by looking at the ejb-ref's and what their respective
ejb-link's point to. If bean A in app 1 point to bean B in app 2, then
app 2 needs to be redeployed if app 1 is redeployed. If app 2 is
redeployed then app 1 does not need redeployment. 

If app 1 and app 2 have app 3 as parent, then all three are redeployed
if app 3 is redeployed, but if only app 1 is redeployed then that is all
that happens. This is only to ensure classloading consistency.

Christoph, does this sounds right? If yes, then we have something
implementable. AFAIK this would be truly unique, since it would allow
not primarily the execution of large systems, but the development and
management of such a system. I.e. without this it would be hard to do
anything large at all, no matter how cool the runtime execution of the
server is. One alternative would be to create several separate EAR
files, which would not give you the class sharing features, and would
also be easier to break dependency wise. The other alternative would be
to have one large EAR file for the entire application, but this would
obviously not work for LARGE systems for system management reasons.

Am I correct in the above assumptions/conclusions?

/Rickard

-- 
Rickard �berg

Email: [EMAIL PROTECTED]

Reply via email to