> yes, sometimes I think I don't yell loud enough, if you read the emails > back when the bird thing you will see that I was pushing for "classes" > outside the sar as it is a total pain, so the sar is just a service.xml > that defines one service and references jars separately and voila! done. > You can edit xml in the flesh and have it redeploy.
I think that perhaps it just takes a bit for things to sink in. > > This whole archive concept is kinda quirky in my > > oppionon. I think it has > > its merits, but the folks at sun who came up with > > this for EJB stuff (and > > now J2EE stuff) really didn't think about the full > > implications of it. > > we are doing it now, ear packaging is a pain in the ass, we are only > talking about packaging on the surface but 2 layers deep you have teh CL > architecture it is all one... This include reloading of dependency archives too? So, one might be able to touch command-mdb.jar, perhaps you have to touch the .xml too, and then it will reload with the new classes and config? > > The point is to link up small snippiets of > > configuration overrides, which > > this is the way that standardjboss.xml works with respect with > modifications, it is the "differential" approach, if we can come up with > something that would be good. I think that the xslt bits might be good for this, but I have not really thought about how exactly. > > By doing this, a user (or admin) does not need to > > touch the deployable > > archive. They only have to provide a configuration > > for the deployments, > > which link to the archive (so we know how to load the > > classes) and specify > > the deployment units and there configuration. > > yes, thank you Admins around the world will love us. > > distributing support components for JBoss too. We > > could provide the core > > server in one .zip, then provide plugins in seperate > > .zip's each of which > > contains an archive and example/default deployment > > configuration plus a > > simple README to show the users the simple steps to > > deploying the > > components. > > yes, the feature I see in the unified deployer/cl goes beyond ease of > development it is also a way to package the server once you are done, some > stuff will be dynamic during development but at deploy time you want one > big file to do the job, we support both these modes. At deploy time you might want to keep the same deployment units for development, or perhaps have larger grain deployables. This is to help ease upgrades... especially if parts of the system can vary independently. If you have one large archive, then the entire application must go down during upgrades. Take for example the website, if there was just one .ear, then each time the content or the forums varied, the entire site would be affected by a change to either. I definitely see the deployer/cl as a tool for managing production and development environments. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
