Again, respect for your incredibly clear-cut way of analysing technical
issues ...
>-----Urspr�ngliche Nachricht-----
>Von: Rickard �berg [mailto:[EMAIL PROTECTED]]
>Gesendet: Montag, 11. Dezember 2000 08:52
>An: jBoss Developer
>Betreff: [jBoss-Dev] Complex J2EE deployment
>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.
yes, it sounds very ok.
My proposal was just going a bit further for ease of implementation and
minimisation of annotations: If we could agree on ejb-ref having
class-consistency as a side-effect (i.e., if we have two versions of the
same class in two dependent jars, then one of them is shadowed - what does
the spec or the JSR say to this issue?), 1) would be subsumed by 2) since
the tree would be just a clique-normalisation of the graph that exactly
implements the stated redeployment rules. All we need is the deployer to
compute and update the dependency tree ...
However, if ejb-ref should be usable without class consistency (i.e.,
different class versions should be runna ble simultaneously in ejb-referred
jars - and that is what seems to be the common understanding and need) ,
then we certainly need a separate annotation in a separate xml
(ejb-consistency-ref in jboss-application.xml?) saying "this reference
should be furthermore class-consistent and optimised". In this case, give me
a few days to come up with a combined deployment/classloader policy ...
>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?
right, exactly our thoughts when trying to apply the EJB component model to
the ERP domain ... exactly our motivation to write the modified deployer ...
if this moves to
the JBoss mainline, I�m really happy.
BTW: I�m trying to push forward a BOF-proposal at next years JavaOne under
the buzz "Internet Business Components" about that and related issues (e.g.,
using XML/SOAP for communicating between independent components). If you are
interested, I would appreciate any comment to the abstract ...
I�m trying to catch up with Marcs intermediate mails ...
CGJ
