I assume you are using an ee 5 ear with a lib directory so A and B
get the same copy of the common jar.
Assuming you can't just move all the classes into common....
I would have a factory interface and a provider in common:
public interface Factory {
...
}
public class FactoryProvider {
static Factory factory;
public static void setFactory(Factory factory) {
this.factory = factory;
}
public static Factory getFactoryInstance() {
return factory;
}
Then B can register a suitable Factory implementation with the
FactoryProvider when it starts up.
Hope this helps
david jencks
On Apr 8, 2008, at 2:30 PM, lsalotto wrote:
Hey Fran,
I've been struggling two days for similar issue, have you ever
solved the
situation? would you mind to share the way you did it?
My problem is very similar, have to Web (name them A and B)
modules, a jar
(named common since both web modules uses them), they are all
within the
same EAR. Web module A will call have the Factory to create objects
in Web
module B. Application get up to the Factory, when via reflection it
tries to
create object in w m B, then I get same exception Mark mentioned.
As you
we've been working with WAS and this works perfectly, however can't
make it
work in WAS-CE/Geronimo.
You may already forgot about this, but if possible, could you try
to search
for what you did that time to solve this?
Thanks in advance.
Luciano Salotto
Fran Varin wrote:
Hi David,
Thank you for your reply...I'll work with Mark to see if we can
work with
your suggestions.
In terms of your questions regarding my explanation, I'll
elaborate below.
The factory simply instantiates a concrete class at the request of an
object that is using the factory. The factory is in fact a singleton
instance. Once the Object is instantiated and returned to the
requester,
the requesting object simply access the public interface on the
object.
The factory returns a type java.lang.Object and the requester
typically
casts the Object to an Interface (polymorphism).
All of the WARs in question belong to a single Java EE EAR, we are
not
trying to have resources cross the "EAR" boundary. In our WAS
implementation we actually have the factory exposed as part of the
EAR. In
turn, the factory is able to see the classes in each WAR defined
to the
EAR. It sounds like your idea about a switch would be just what
the doctor
ordered in this case, it is a great feature for all of the reasons I
mentioned in my last post.
We'll give your suggestions a try and post back if we have any
questions/problems and again thanks for your time.
Fran Varin
Sr. Architect
Amica Insurance
--
View this message in context: http://www.nabble.com/Multiple-
Applications-within-one-Ear---Co-dependent-classes-
tp6758567s134p16574104.html
Sent from the Apache Geronimo - Users mailing list archive at
Nabble.com.
