> i think this is generally an antipattern. its never a good idea to put
> jars
> like wicket,spring into server's shared lib dirs because anything
static
> then becomes shared across all webapps. it can have some strange
> sideffects.
> 
> for example take wicket's springbean injection stuff. it keeps the
> injector
> in a static field, and the injector is tied to the application. so if
you
> do
> this then webapp A can get an injector that works with webapp B
because
> they
> now shared the static field that is shared across the webapps.

Yeah I don't think sharing these jars is a good idea either now. I
remember I had a problem once before - I got a run time exception when
casting from a base class in a framework jar in shared or common lib
(can't remember) to a derived class in my app. I was pulling my hair out
trying to work it out. 

I eventually discovered that when two classes are loaded by different
class loaders they are treated like two completely separate classes
(even if the package and class names are identical) - very strange. To
fix the problem I moved the framework jar to my apps own lib dir and
everything was fine - except for the hair loss.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to