I weighed up the pros and cons of how Jetty should be distributed and decided to leave it in a sar for the time being because it makes it much easier to redistribute and install updated versions of Jetty and Jetty is an independant project with a seperate release cycle, so this is a necessity.
I thought about the config angle and decided that people who wanted to change the config could either ; 1. unjar/edit/jar *N 2. unjar, move jars to lib (there are now no single classes in the) and edit dd in deploy. I tried this with emacs and vi and upset the deployer with both editors since they write backup files in the same dir. 3. unjar in-situ and edit the unpacked dd directly. I haven't tried this yet - should it work? If so, then I think that this is the answer. The only remaining argument I could see for losing the sar was that someone might want to run more than one jetty instance. In which case packaging impl with cfg didn't make much sense - but I figured that anyone doing this was advanced enough to figure it out. In Jetty's case the 'ease of redistribution' angle won the day. Which is why it is still packaged as a SAR. Comments ? Jules Jason Dillon wrote: > 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
