> I was thinking last night about how crappy the whole > archive thing that sun > started is with respect to changing the configuration > easily. I was > thinking that it is a bitch to extract a .ear, edit > the application.xml, > then re-jar it and copy it to change where my .war > gets deployed too.
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. Part of the monster at the bottom of the ocean thing is the capacity to independenly watch classes and XML they are different beasts and that gets messed up in the XML. BTW this is what is really non-clean in the current David code and I took out. We will deal with cycling by other means, possibly automated. > 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... > command-mdb.jar > command-example-deploy.xml right see my mail above the xml says <classpath codebase="http bla" archive="command-mdb.jar"> I have been saying this since the very beginning. > 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. > 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 > 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. ______________________________________________________________________ View this jboss-dev thread in the online forums: http://jboss.org/forums/thread.jsp?forum=66&thread=5576 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
