another solution is to provide with our lib/ (provisioning, ssh) scripts (or sthg storable) to add/remove additional libs.
- Romain 2012/7/25 David Blevins <[email protected]> > Note that moving libraries out of the lib/ directory breaks most of the > Tomcat based tools like Eclipse WTP. > > We could do it, but there'd be some sacrificing of our Tomcat nature > involved. > > > -David > > On Jul 25, 2012, at 6:27 AM, Jean-Louis MONTEIRO wrote: > > > Hi devs, > > > > Was wondering if we could manage kinda plugin mechanism in a simple way. > > I mean, a way to add a resource, to ass the ssh extension or the > > provisioning one, without having to push/extract a set of jars in the > > catalina.home/lib (ie. in the same place where we also put our TomEE > jars). > > > > The point is that, when pushing ssh, provisioning or if an end user wants > > to push a new resource let's say, it will have to deploy and mix his jars > > with our. It makes it difficult to update, or remove a new > > resource/extension (ssh, provisioning). > > > > Sometime, it also make sense to have a single catalina.home distro and > get > > different catalina.base configuration per application where the set of > > plugins won't be the same. > > > > As we are not in OSGi, and we don't want to be in TomEE, we won't have a > > classloader hierarchy with a separate classloader per plugin. > > So it's only a matter of getting things separated to ease > > update/activation/deactivation and so on. > > > > So, i just would like to be able to have a catalina.base|home/plugins > > directory, where each plugin has its own directory like > > > > tomcat.home/ > > conf/ > > * plugins.properties* > > webapps/ > > mywebapplication/ > > WEB-INF/ > > ... > > lib/ > > openejb-XXX > > tomcat-YYY > > ... > > * plugins/ > > myplugin-A/ > > conf/ > > lib/ > > myplugin-B/ > > conf/ > > lib/* > > > > WDYT? > > > > Jean-Louis > >
