It is becoming clear that reason is not a key player in this issue, perhaps 
others as well.  It has been lost to cyrptic and non-sensical rambilings of a 
complicated world of cascading locations for configuration files.

For all of you who are math buffs out there, if you sit down and think through 
the steps a users must go through for each of the possible options, it should 
be clear what direction to move in.  It is simple math, shit I can even do it 
with out a calculator.

My experence as a system administrator, managing clusters of machines across 
the US, managing the configuration and distribution mechanisms for updating 
code and config, must have alluded the mass of you at some point.  Even my 
work on the website, where I painfully had to deal with the issues of config 
inside .sars, and even at my job where I had to write a layer ontop of the 
2.x config system to make it work in a multi vm/multi host environment... 
until I rewrote it to make more sence... and still no one listens to me.

Well, fuck it.  Do as you do.  It is very clear that my words do not hold any 
place in your minds as you go about your buisness of complication.

I do believe that all of you have missed the point.  I have spent several 
weeks trying to show you the error of your ways and I have grown tired, so 
very tired.

Do as you do...

--jason


On Monday 03 June 2002 03:27 pm, marc fleury wrote:
> 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


_______________________________________________________________

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

Reply via email to