1. Related to these problems is the question of how we should store "persistent" mbean attributes and the desired relationship between these persistent attributes from storage and those from a possibly modified config file. Remember the bad old days of jboss-auto.jcml? That is gone but no replacement has arrived....
2. You should be able to deploy jetty stuff as a (bunch of) jars + jetty-service.xml all in deploy. The mbean config should wait for its classes, if it happens to get deployed first. Is this not working properly? Have you tried it? 3. IMO there is no reason not to have everything (not explicitly on the boot classpath (?)) in lib redeployable. I'm not sure exactly what is needed, but I doubt it is a large change. If you are seeing specific mbean dependency problems, please let me know what they are. thanks david jencks On 2002.04.21 00:51:59 -0400 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
