Sections 5.7 and 8.7 of the spec describe the mechanism to obtain Handles
and show examples of serializing and deserializing them to streams. The
examples don't show the actual construction of the Object I/O streams
themselves.
Question is this:
Is the mechanism expected to work with ordinary
ObjectOutputStreams/ObjectInputStreams?
If so, it will be necessary for clients to have copies of the server Handle
implementation classes on their local classpath. This is because the base
java.io implementation of ObjectInputStream resolves classes using the
application class loader hierarchy.
This restriction seems neither practical nor desirable. I see no other
requirements placed on EJB clients to have local copies of server
implementation classes. If this is required, it will involve some server
specific client deployment mechanism. Clients using a variety of servers
will need to keep a repository of all the Handle implementations provided by
the various vendors. Seems bad and works against world wide EJB deployment
and ease of use.
An possible approach to removing this restriction would be for javax.ejb to
provide classes which implemented subclasses of the java.io Object I/O
streams along with an interface that Handle implementations could use to
return a codebase capable of resolving the Handle classes. It would go
something like this:
// in javax.ejb
// optionally implemented by server's Handle implementation
public interface CodeBase {
// can return URLs from its own URLClassLoader.getURLs() or some other
server // specific urls
public URL[] getCodeBase();
};
// also in javax.ejb
public class EJBObjectOutputStream extends ObjectOutputStream {
...
protected void annotateClass (Class cl) throws ...
{
// Use reflection on cl to test for CodeBase impl in the class
implementation
// If class implements CodeBase, call getCodeBase, mark outputstream
as annotated // and annotate outputstream with URLs
}
...
}
public class EJBObjectInputStream extends ObjectInputStream {
...
protected Class resolveClass (ObjectStreamClass v) throws ...
{
// read marker from inputstream and if marked, then resolve class
with
// annotated URLs, else call super().resolveClass
}
...
}
This would give the Handle implementation control over the class annotation
process or to not participate at all if desired (in the latter case,
server's Handle impl would need to be on client's classpath).
Clients would need to use these EJB Object I/O subclasses rather than the
base java.io Object I/O streams.
===========================================================================
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".
