don't be an ignorant bastard on your own idea and its actual implementation.
|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! wow, which means it is the first time you use that (remember the mails from Bill/me about 6 month ago?) and we already have a solution just drop the jboss-service.xml in deploy reference the jar that has the file in the classpath of the service.xml they will be deployed as independent jar (and cycled accordingly) |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. As Frederick Brier pointed out in response to this, it is useful for shipping self-contained configuration of beans. End of story, very useful, get off the wanking box. + all the examples you give below. |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. Jason WTF are you doing, are you trying the negative publicity thing to remind the group that the idea was yours and that it works??? why this email. |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. IT IS ALREADY SEE ABOVE, SEE MY MAILS FROM THE BILL THREAD ON THE "PACKAGING NIGHTMARE"... GEEZUS |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... Ok I am really tired of everything/everyone DOES THE SIMPLE NUMBERING OF DEPLOYMENTS WORK??? I WANT A YES/NO ANSWER. If I do 01first.sar and 02second.war do I get 01 first and 02 second? YES=NO ? marcf | |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
