> don't be an ignorant bastard on your own idea and its actual > implementation.
Whatever dude... I am enlightened to users needs, to the needs of IT professionsals who need ease of configuration managment... I am enlightened to the possibilities of creating a super system around JBoss which will dynamiclly generate xml configuration for anonymous hosts in a mega cluster. I am thinking outside the box, outside the archive... and trying to get the usage of .sar back on track to what those fucking birds were saying... which was seperation of code and configuration. My email suggested that each service archive contain some config to show what classes of services were provided by it. So taking the jetty example it might have a list like [ "JettyService" ]. Then an *external* configuration system (be it xml, database, whatever) could be used to create an instance of that service. If say you have a database which stores this information you might then create a configuration entry name "MyJettyService", which is linked to the "JettyService" by name and has a text field for storing the actual xml config. When the system starts up it loads archives, finds the jetty-plugin.sar parses its descriptor, finds out that there is a "JettyService" service class in here, then asks the ConfigurationService for all configs for "JettyService" and starts up each instance it has. Now this isn't an ideal design, nor was the original months back, but one of the core concepts was seperation of configuration... or rather seperation of service instance configuration. Clearly we have lost that direction... which is why I wrote this thread and is why I have continued to respond trying to communicate why it is better for this seperation to exist and why we should ship our product with config seperated by default. * * * > |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! > > wow, which means it is the first time you use that (remember the mails from > Bill/me about 6 month ago?) and we already have a solution No I don't remeber the emails... is there a link in the forum? > just drop the jboss-service.xml in deploy > reference the jar that has the file in the classpath of the service.xml > they will be deployed as independent jar (and cycled accordingly) BUT MY POINT IS that we should ship like this BY DEFAULT... it is EASIER and SIMPILER for users to change the config... the alternative is only more complicated. Shipping components like this vilotates your beloved K.I.S.S. principle... unless you mean to say that we won't expect users to change the config at all... but that is just plain ignorance. > |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. > > As Frederick Brier pointed out in response to this, it is useful for > shipping self-contained configuration of beans. End of story, very useful, > get off the wanking box. + all the examples you give below. Yes, it is useflu I am not arguing that is isn't... I think that it would be better to have them cleanly seperated, but if you want them all in one, then go for it... (see BUT MY POINT IS) > |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. > > Jason WTF are you doing, are you trying the negative publicity thing to > remind the group that the idea was yours and that it works??? why this > email. Whatever... I don't need to stoop to such levels to boost my ego... and if I did this would have been a rather backassward method todo so. I believe that we can make the system better, more managable & more coherent by keeping the seperation clean. I want to help move the core system in positive directions, which is why I wrote the email, not to remind anyone of anything. > |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. > > IT IS ALREADY SEE ABOVE, SEE MY MAILS FROM THE BILL THREAD ON THE > "PACKAGING > NIGHTMARE"... GEEZUS No it isn't... not in the downloadable from SF.NET. Go download the RC1 and then chnage the jetty port. Or enable ssl.... or change the jmx html adapter porty or enable authentication. Take a look at what the user of the product will have to go through change the config... or if you prefer what the customer will have to go through. We have the power to make it easier for them out of the box... which will increase the chances that they will have a good experence and will stay with it and not go to another vendor. Why not make it easier? --jason ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
