Thanks, Larry, This is exactly the approach that I was suggesting.
Jules Larry Sanderson wrote: > 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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
