Hi!
"Jung , Dr. Christoph" wrote:
> 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?),
No, hang on! If you have two dependent jars, then they need to have the
same parent which holds the classes that tie them together. The only
graph that has clear semantics is the Java2 classloader delegation
model, which is a tree. The decision to redeploy can be done on ejb-ref
basis (i.e. general graph), but the classloading is still tree-based.
This way there is always clear semantics on what class is visible.
Example: Child apps A and B, parent app C. A and C has class X. A B uses
X. Due to classloader delegation model A will see C.X and not A.X, which
is also what B will see so there is no shadowing problem, only a
redundancy problem with regard to A.X (i.e. it can be removed without
any effects whatsoever).
> 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 ...
Yes, the dependency *set* (consisting of relations "A depends-on B",
where app A needs redeployment if app B is redeployed) is the union of
the rules of 1) and 2).
Example: Child apps A and B, parent app C. Foo in A relies on Bar in B
through ejb-ref. Dependency set is:
A depends-on C (because of classloading tree)
B depends-on C (because of classloading tree)
A depends-on B (because of ejb-ref set)
results in the following rules:
A redeploy -> {A} redeployed
B redeploy -> {A,B} redeployed
C redeploy -> {A,B,C} redeployed
> 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)
No, now you're in murky waters. You want inconsistent classes within the
system??
> 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 ...
Well, for the classloader delegation model dependency you definitely
need this. In the above example no beans in A or B rely on beans in C,
so with only ejb-refs a redeploy of C would not cause A and B to be
redeployed.
As stated in earlier post, a jboss-application.xml with a pointer to the
parent application could solve this by implementing a tree through
child->parent pointers.
> 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.
Yes, if we talk about the above child-parent thingy it should definitely
be integrated in the core J2EE/JBoss deployer. It is a critical piece to
the puzzle for larger systems I think.
> 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 ...
Hit me. :-)
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
