I currently deploy jetty-plugin.sar as an exploded archive. Best of both worlds: convenient organization, ability to modify jboss-service.xml on the fly, will automatically redeploy whenever the xml is touched.
-Larry > Well, perhaps not completly sucky, but as it is now it does suck. When I wrote that email long ago about those pesky birds, which eventually lead to .sar (and other things), I did not have this in mind. > > The idea was to make it *easier* to configuration components not complicate it. SAR as it is today only complicates... > > Take Jetty for example. I am a user and I want to change the port, or enable SSL or add a non-deployed webapp for development... how do I do that? I have to break open the jetty-plugin.sar, change jboss-service.xml, rejar it, then redeploy. What a huge pain in the ass! > > I think that the concept of a SAR is still useful and we should not cast it aside, but there are some limited cases where we would use one. > > For example, SAR is good for grouping like .jar's together. There are several jars needed for Jetty to work, and it makes sence to group them together inside of a super archive. When used in this manner it makes it easy to create an explicit classload hierachy (when we have that capability). > > SAR is also good if you want to distribute a set of native libraries. In this usage you would put in a version of the lib for all supported platforms. > > SAR is good to provide a static filesystem, or the intial structure for a dynamic filesystem which is needed. > > In all of these examples, SAR is used as a grouping tool, proving a wrapper around other files... but not specifing any service related configuration. > > Serivce config MUST be seperate from the archives. This is a huge defficeny with the EJB-JAR, EAR & WAR formats from SUN. While it was a good idea to group the support files, it plain sucks ass to put the config in there too. > > SUN was assuming that everyone would have some fucking GUI crap to handle the details of opening the jar, finding the files, editing them and rejaring. > > * * * > > Ok that said, there are still some dependecny issues(both class & MBean) in the current system which are holding us back... which I know people are working on solutions for... > > BUT we can work around some of those issues for the 3.0 release, pending some real hard thought and work into fixing this problem as well as other issues with the core system. > > Take Jetty as an example. jetty-plugin.sar is selfcontained and can be redeployed, so it is easy to develop that plugin with out having to cycle the server each time. > > The short-term solution to dropping this as SAR is to make a jetty-plugin.jar (in lib/) and jetty-service.xml (in deploy/). Since we don't (as far as I can remember) redeploy archives in lib/ we (or rather jules) looses some convienece when developing this. > > BUT... users gain the ability to simply edit the jetty-service.xml to change the config. AND we have the nice and simple answer to their questions about where do change this... instead of the alternative. > > * * * > > So, I think we need to rethink what SAR is good for and what it isn't. > > I think the list I mention above are really good uses for SAR and is why I think we should keep the concept around... BUT I really think we need to keep the seperation between support/code & configuration. By doing this we make users lives easier and make it possible to implement some really interesting things on the configuration side, which would be a nightmare if we had to deal with these local file archives. > > --jason > > * * * > > View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=13522 > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
