> Well, if you're going to use CMR which uses local interfaces and those
> interfaces use non-primitive parameters or return types, you're going to be
> stuck redeploying all referenced classes anyway. For example take the case
> of class A from ejb-jar 1 which has a reference to a class B in jar 2. If
> you attempt to undeploy jar 2 there is no way you can unload class B since
> it's referenced by class A in jar 1. So if the spec allowed CMR
true
> relationships between jars, they would have to use remote interfaces. But
> then, the container would have to maintain the relationships via remote
> calls.
which could be optimized automatically if intraVM as all decent containers do
at the moment.
>
> > 2) when looking into the deployment descriptor files you deal with
> > enormous monsters being a few Megs in size.
>
> You can deploy more than one ejb-jar file in an application (and hence one
> VM) if you package them in a EAR file. You would then be able to use CMR
> between entities in different jars. Of course, you still have to deploy as
no, current spec does not allow CMR between entities in different ejb-jars,
even if they are in the same EAR file, that's my point. The first time I
discussed this topic on this list (when pfd2 came out), I suggested having
the relationship-role-source use something logically equivalent to an
ejb-link, rather than an ejb-name. Again, I might not see all implications of
that but I didn't get any answers. One thing I know that this would make the
job harder for the CMP implementor but is that reason enough to rule it out?
Of course, I might not see all implications of allowing remote relationships.
> a single unit.
>
> > 3) we update changes to our production systems via rsync and would always
> > have to update the entire beast if the implementation code or deployment
> > settings were changed that only affect one part of the system.
>
> I don't see why, but then this probably isn't for forum for discussing
> custom deployment systems.
agreed
>
> So in summary, using local interfaces forces you to deploy in a single
> package.
agreed again
robert
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
This message was posted using eunum
To interact with a real-time, threaded interface to this e-mail list, clickthe link below:
[EMAIL PROTECTED]
