Ole,
I had not considered the case where value classes ( return or parameters)
used by an interface do not exist on the client. Thanks for pointing that
out. I believe that your approach of adding the interface JAR to the
manifest classpath in the implemetation JAR will work as well.
If you follow that approach, you could have a separate directory for all
interface JARs;
the implementation JAR would contain only the EJB implemetation classes, and
all interface and value
classes would reside in the interface JAR. Nice.
David, regarding the approach you outlined below:
>> That said, there is a way to do it relatively painlessly. Suppose you
have
>> classes A and B as above. Instead of putting main() in A, put main in
some
>> 3rd class C. Then load A dynamically with URLClassLoader, and instaniate
it
>> using reflection. B will then be loaded by the same classloader and
>> everyone is happy. This is just what Jboss does, right? It creates a
>> classloader that sees your ejb jar. Then it instantiates the ejb class
in
>> classloader, and the rest of the classes are brought along
>> automatically. Again, dynamic classloading is appropriate here BECAUSE
>> jboss doesnt know what classes it will be dealing with.
That's exactly the conclusion I reached! Implicit class-loading via a
"bootstrap" class that loads
everything else using a URLClasLoader w/ system class loader as its parent,
and reflection rather than direct
reference to instantiate classes, invoke methods, etc.
Thanks to everyone on the list (Rikard, Tom, Ole, Alexander, others) that
helped clear this up for me.
cheers,
Joe Barefoot
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Ole Husgaard
Sent: Thursday, February 15, 2001 6:30 PM
To: JBoss-User
Subject: Re: [jBoss-User] DYNAMIC CLASSLOADING
Hi,
Joe Barefoot wrote:
>
> I'm trying to get dynamic loading of the interface classes using the
> webserver to work also...
>
> Ole, you say that classes in the EJB JAR are not served by the web server?
Sorry, I was wrong here.
> If this is true (I'll take your word for it), dynamic class loading is
only
> useful if one
> adopts your approach and just put the interface jars in the class path.
> Unfortunately, there's no way to add
> a JAR to the classpath at runtime (as far as I know), so you would have to
> bounce the server
> or use a custom class loader.
I guess that the interface jar can be
added to the manifest classpath of the
implementation jar and any other bean
jars that use the interface.
> Also, why is there no "sure way" to differentiate between interface
classes
> and implementation classes?
> Seems to me that you could just check the type of classes in the JAR and
> only serve those that are of
> type EJBOjbect or EJBHome, which would only be the interface classes.
The home and remote interfaces are easy
to identify as interface. Also primary
key for entities.
But value classes are not handled that
easily: Consider the remote interface
having a method:
void doSomething(Work toDo);
Now, if the bean jar has classes:
class Work { ... }
class ExtWork extends Work { ... }
class IntWork extends Work { ... }
Clearly, class Work belongs in the
interface, but how about the subclasses?
It could be that IntWork is for the
bean to use internally only, while
ExtWork is meant to be used from the
client. But there is not sure mechanical
way of finding out, given an EJB jar
only.
Best Regards,
Ole Husgaard.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
