I am afraid I beg to differ. I think that the SAR is an excellent concept and approach. First of all it is simple. Simple is good. Sometimes simple doesn't cover all the bases, but being too complex can make something unusable. In JBoss 2.4x, I had created an alternate solution, but it was more complicated (I'll describe it at the end as an aside). Second, the example you are using with Jetty is a special case of a singleton MBean. In other words there is usually only a single servlet engine running in a JBoss instance. However, in the applications I am building, each deployed application archive is made up of several EJBs with many supporting MBeans. The categories of MBeans are functions such as incrementing keys, pre-populating database tables/tuning with additional SQL commands, and loading non-SQL data into MBeans from XML files contained within the .sar. So even within the same archive, there might be 5 instances of the same MBean class. And there could be many different applications deployed on the same server using the same approach.
Here is an alternate idea, something that would co-exist with the .sar concept. Each MBean has a name that makes it unique. Build an XML file with a name space, essentially an element for each MBean that has had its configuration changed from the original .sar archive's jboss-service.xml file. It is basically <cringe> a Windows Registry. If an MBean's configuration is modified via, say the port 8082 HTML interface, an entry is created if there wasn't one. When an MBean is deployed, the SAR deployer checks the name space. If there is one, the MBean is initialized with those parameters, rather than the ones in the file. Note: only writable properties from the original MBean attributes can be configured. There could even be a "Revert to Defaults" button to switch back to the original values in the .sar. To clear the entire configuration, delete the registry file. But this idea can get complex when we consider versioning. What do you do when a new MBean has or is missing attributes in a previous version? How do you even know it is a different version? Another simpler idea, is to write a tool that opens a .sar, lets you examine the MBean attributes, change them, and re-bundle them. No more pains in the ass, and not very difficult. ASIDE: My JBoss 2.4x approach utilized the MBean Notifications for the J2eeDeployer that I believe David Jencks was kind enough to add to the code base for me. I had an MBean DeploymentManager defined in the jboss.jcml whose sole purpose in life was to register with the J2eeDeployer and listen for new deployments. It then looked in the root of the archive for different named XML files: mbean.xml (the exact same format as David's jboss-service.xml file), an rdbms.xml, and two others. Each was processed by a different handler. Now this isn't that big a deal, but my method required the DeploymentManager to look at every archive to determine whether the special files were present. It also had to play games to figure out if the old temporary hot-deploy directory was sitting around which was the new real one. Finally, I had to write XML parse routines for the mbean.xml file (I would have had to write one for the additional file types anyway). Maybe if the .sar JSR gets modified, maybe we will end up with .jar(s), .war(s), and .ear(s) specifying if a *-service.xml file exists in the root directory or the WEB-INF directory, a deployment manager will process it. But for the time being, .sar deployment is a useful component. Frederick N. Brier Sr. Software Engineer Multideck Corporation At 12:51 AM 4/21/2002, you 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
