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
