yes this is correct, Is jetty configured through the jboss-service.xml?
if yes --> jetty-service.xml if no --> use diretory structure exploded 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
