yes clearly best of both worlds. marcf
|-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Larry |Sanderson |Sent: Sunday, April 21, 2002 9:13 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-dev] SAR... Sucky ARchive ? | | |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
