Hello,
I recently came across this thread:
http://forums.java.net/jive/thread.jspa?messageID=260369&tstart=0
It seems to be a Glassfish issue (I think) but I'm just curious if
there's anything Stripes can do to get around this issue. It
sounds like Struts 2 suffers too and I think they'd decided to not
do anything.
Being as that's my thread...
In this case it is a Glassfish issue, because of the way they choose
to manage their class loaders with applications loaded in an EAR.
There really isn't a lot that Stripes can do here, I don't think. For
me, the conflict was happening when I had two classes named the same,
but that were in fact different classes, loaded in the same EAR in 2
different WARs.
The only thing that Stripes could do here (assuming it is not) is be
more generous and forgiving during the server lifecycles.
Notably, it's very possible, for example, that any life cycle methods
tied to the WAR, but which perhaps are implemented ultimately by a
Singleton, could well have 2 different "init" methods called. Several
things could happen. 1) the second init call overwrites and destroys
any initialization done by the first call, 2) the second init call
"does nothing" seeing that it's "already initialized", 3) the second
init works fine and overwrites or stomps on any conflicts from the
first initalization.
As to what Stripes does in this case, I don't know. If it's
problematic, perhaps it could "behave better" in this edge case.
The final thing that Stripes could do is punt on the auto
configuration model, and rely on an XML config file, effectively
taking the classloader crawler process out of the equation, but I
don't see that happening either. The real trick is keeping the
classloader stuff separate from the web server contexts.
One thing that could be done (this may have been talked about before)
is for Stripes to keep its mapping information actually IN the
context, vs in a class/singleton (it may do this, I don't know).
But this wouldn't resolve conflicting classes with the same class
name. Nothing stripes can do about that.
I believe that I punted on the issue and deployed my second WAR
separately and relied on remote EJB calls, thus routing around the
problem completely.
Regards,
Will Hartung
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
