If we fall back to the "traditional" jboss view, then: 1) Invoking on a template for copying static libs into ./lib is not the best way. It'd be more straightforward to have on the DeploymentService something like:
| String[] listStaticLibs(); | boolean uploadStaticLib(URL url); | (This doesn't solve the modifications issue, i.e. remove/update a lib) 2) From a design point of view, I believe it's much more clear to the admin to provide him an exact view of the system, it's restrictions and the ability to change it. In this sense you admit that the ./lib directory contains static libs that can only be changed with a reboot. So maybe a better interface is something like: | boolean scheduleLibUpdate(URL url); | boolean scheduleLibRemoval(String libname); | The 2 schedule methods will store the new lib/info for removal somewhere, then the server upon boot will have to make those changes. The thing is, the changes need to take place *before* ./conf/jboss-service.xml is loaded, because this is where the libs are "loaded". Maybe we could pass a new arg at command line, e.g. --update-libs to triger this behaviour. In any case we could proceed with (1) and optionally do (2). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3864265#3864265 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3864265 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
