I am not a sys-admin anymore. And your emails about jetty.xml, jboss-service.xml and jetty-service.xml make no sense... perhaps you have meant something different, but as you have written (several times and inconsistently) makes no sense.
My problem is that I care to much about getting things done right... and I believe that I am right... that is my problem. Any ways... I have given up trying to explain. I will go work on something else and leave this to someone else... --jason On Monday 03 June 2002 05:02 pm, marc fleury wrote: > what the fuck is your problem? > > stop throwing your experience around, I am not the bad widtch around here, > > what I am saying in my mail is > > |> Is jetty configured through the jboss-service.xml? > |> > |> if yes --> jetty-service.xml > |> if no --> use diretory structure exploded > > and the jetty service is configured through jetty-service.xml > > you are not a math-buff, just a sys-admin, but if you turned the common > sense on, the only material worth anything in the first place (I know a > math buff that lack a lot of it :) you would see that the above statement > and bla bla is saying... you are right. > > so get off the heroin of insecurity, sniff the brain common sense and stop > feeling so lonely > > marcf > > |> marcf > |> > |> |-----Original Message----- > |> |From: [EMAIL PROTECTED] > |> |[mailto:[EMAIL PROTECTED]]On Behalf Of > |> | Jason Dillon > |> |Sent: Monday, June 03, 2002 3:16 PM > |> |To: [EMAIL PROTECTED]; lsanders > |> |Subject: Re: [JBoss-dev] Where should the Jasper jar live ? > |> | > |> | > |> |Thanks for the recap, but it is in correct. > |> | > |> |> deployment type | Advantages | Disadvantages > || > ||------------------------------------------------------------------------- > ||- > || > |> |- > |> | > |> |>- - > |> |> .sar archive | 1 file | Pain in the ass > |> | > |> |to configure > |> | > |> |> | digital signature | > |> |> | It already works | > |> | > |> |digi sigs will not work when you need to change the config. it is > |> |only useful > |> |if you have static config and want to ensure that the contents do > |> |not change. > |> |the second you need to chagne the config, you must resign... > |> | > |> |> exploded sar | All files organized | Multiple files are > |> |> exposed > |> |> > |> |> | within one directory | (potentially > |> | > |> |many jarfiles) > |> | > |> |> | Uses same structure as | Can not use > |> |> | jar-signing .sar archive | techniques > |> |> | Easy to configure | > |> |> | It already works | > |> | > |> |The major disadvantage of this is the added complextity of the > |> |configuration... there are no other directories in deploy... > | > |there do not > | > |> |need to be more directories there. Using an explosed archive here just > |> |complicates. Though this does simplify, it does not simplify > | > |completly... > | > |> |there is still some complexity to be factored out. > |> | > |> |> external config | 2 files | Must distribute as 2 > |> |> files > |> |> > |> |> | Easy to configure | Not set up like j2ee > |> |> | archives > |> |> | > |> |> | | Doesn't work yet > |> | > |> |So, this does work. Why do you believe it does not? > |> | > |> |Fuck J2EE config, that is a fucking mess. If you want J2EE-like > |> |config then > |> |put it back in the single .sar. I belive that users would rather > |> |have easy > |> |to config, easy to understand than J2EE-like... fuck that. > |> | > |> |This is the situation where digi signature could be used to ensure the > |> |validitiy of the impl code and resources and allow the config to vary. > |> |Consider a company which provides a plugin and they provide > |> |support for it. > |> |They could sign the impl archive to ensure that users have not > | > |mucked with > | > |> |it. > |> | > |> |An must distribute as 2 files? What? Now you are talking about > |> |distribution, > |> |or do you mean deployment? For distribution you will want to > |> |zip/tgz these > |> |up with a simple install guide, other docs, whatever. > |> | > |> |For deployment, copy files x and y to deploy/... big deal. This > |> |is the most > |> |complicated part of this option... copying 2 files. All of the are > |> |significantly more complex. > |> | > |> |> I propose we allow the following: For any configuration file (or > |> |> deployment descriptor) that exists within an archive, we allow > |> | > |> |an external > |> | > |> |> version to override it. Ex: > |> |> > |> |> jetty.sar (fully compressed, with META-INF/jboss-service.xml) > |> |> jetty_jboss-service_override.xml (Or something. I suck at > |> | > |> |coming up with > |> | > |> |> names.) > |> | > |> |No, why do we need this at all? Who are we trying to cater too > |> |here? Who > |> |will beninfit most from the simple solution (option c), and how > |> |will beninift > |> |from the others. I am not suggesting we make it impossible to get > |> |a or b if > |> |they want... but I am suggestion that users who want a or b > | > |have specific > | > |> |needs which we can not and must not assume that all of our users will > |> | have. > |> | > |> |> This would give us the best of all solutions. Sar's can be > |> | > |> |shipped with an > |> | > |> |> embedded factory default configuration, and the user can > | > |easily override > | > |> |> those settings by adding a configuration if they need it. Also, > |> | > |> |this gives > |> | > |> |> a simple place for MBean configuration changes to be > | > |persisted. What do > | > |> |> you think? > |> | > |> |Um... users can already override each of these... all of the above are > |> |possible with JBoss3 today... ALL OF THEM. > |> | > |> |The matter is which is the simplest... which is going to be the > |> |easiest and > |> |most intuitive for the largest number of users who download the > |> | release. > |> | > |> |We want to make JBoss easy to use for the masses... and > |> |configurable todo as > |> |you please for everyone else. > |> | > |> |Option C, 2 files, provides the most coverage for all of these > |> |problems, and > |> |does not introduce any added release management complexity. > |> | > |> |It is the clear and simple solution... why complicate any further? > |> | > |> |--jason > |> | > |> | > |> |_______________________________________________________________ > |> | > |> |Don't miss the 2002 Sprint PCS Application Developer's Conference > |> |August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > |> | > |> |_______________________________________________ > |> |Jboss-development mailing list > |> |[EMAIL PROTECTED] > |> |https://lists.sourceforge.net/lists/listinfo/jboss-development > |> > |> _______________________________________________________________ > |> > |> Don't miss the 2002 Sprint PCS Application Developer's Conference > |> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > |> > |> _______________________________________________ > |> Jboss-development mailing list > |> [EMAIL PROTECTED] > |> https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
