> 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