Hi Evan,
Thanks for your suggestion for the resolution of my concern about
local interfaces and classloaders.
By an "application-level classloader," I assume you mean one
common to all the files in an enterprise archive. If you can point to
something in the PFD2 specification that limits the use of local
interfaces to the archives in which they are deployed, be they J2EE
EARs or EJB JARs, that would certainly solve the problem (but see
below). I didn't see any such limitation in the specification,
although I admit I have only read through it once.
(This is the question I was asking. The phrase "deployment unit"
can refer to either a stand-alone J2EE module, or a J2EE
application, consisting of one or more J2EE modules. See the
J2EE 1.3 PFD spec, section 8.4.)
If you didn't so limit the use of local interfaces, you would need a
classloader common to every component that uses the local
interface. For example, two EARs deployed in the same JVM
might both use the same local interfaces. Is this a legal usage? -
This is what I want to know. If legal, would you suggest it be
implemented with a common classloader? And if so, do you agree
that this would screw up things like hot deployment and
configurable Java security? For instance, how could you redeploy
one EAR and not the other? Or if you didn't use a common
classloader, do you agree that you are going to get class casts?
It seems to me that the sensible answer is that local interfaces are
an "implementation detail" for a particular deployment unit. But I
want to know where it says this in the spec. And I want to know if
the implications of this answer have been considered. For instance,
the same 8.4 of the J2EE spec says that any J2EE platform must
be able to accept a J2EE application delivered as an EAR file or a
module delivered as a .jar, .war, or .rar file. But now we potentially
have an EJB JAR that must be delivered in an EAR file with the
source of its local interfaces. So should local interfaces be limited
to the EJB archive in which they were defined, like dependent
objects were?
I hope you continue to take an interest in this question, because
I'm interested in your opinion.
-Dan
On 1 May 01, at 9:31, Evan Ireland wrote:
> Daniel OConnor wrote:
> >
> > Version two of the proposed final draft for EJB 2.0 introduces the
> > concept of local interfaces, which use pass-by-reference
> > semantics. These local interfaces are required to be co-located in
> > the same JVM as their clients (obviously). However, apparently
> > local interfaces can be located in a different deployment unit from
> > their client--or can anyone point to something in the specification
> > which contradicts this?
> >
> > It seems to me that this introduces an implementation issue. If
> > multiple deployment units are deployed into the same JVM,
> > wouldn't they have different class loaders? This would be the most
> > obvious way to implement features such as hot deploy and
> > configurable Java security, anyway. But interface and value-object
> > (e.g. view object) instances passed by reference across class
> > loaders would result in a ClassCastException, wouldn't they?
> >
> > I'm guessing I'm missing something obvious...
>
> Like application-level classloaders.
>
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> --
> ________________________________________________________________________________
>
> Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
> Wellington, New Zealand +64 4 934-5856
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
