Marc,
I see your point and the interest of such a solution. Nevertheless, there is another
problem in fact that *currently* favor the multiple files approach: persistent
modification of configuration.
Currently (as of 3.0), when you want to modify some service/bean/datasource/whatever,
you take its corresponding snippet, modify it and zou, it is re-deployed. First
problem: re-deploy should not be, in some cases, undeploy+deploy. Second problem:
everything that is in the file is re-deployed. => if you have a single file, you
redeploy everything => we tend to have many files now because, currently, "many files
=> fine granularity of redeploy".
The second category of problems is about persistence of changes. If you say: "F*ck the
files, we go through JMX anyway", then any modification made through JMX is *not*
persisted (i.e. transient modification). This is a problem, a real problem. The old
solution of keeping the old version didn't seem to work well, so it wasn't good
either.
=> IMHO, the problem is not about one vs. multiple files, it is about granularity and
persistence of changes (=> granularity of redeploy) => maybe the repository approach
is a good solution.
But *Currently*, with these issues, the multiple-file approach is the best (only?) way
to get fine-grained modification of our app server.
Cheers,
Sacha
> -----Message d'origine-----
> De : marc fleury [mailto:[EMAIL PROTECTED]]
> Envoye : vendredi, 26 avril 2002 15:19
> A : Sacha Labourey; Juha-P Lindfors;
> [EMAIL PROTECTED]
> Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
>
>
> You do, this is the "production" file.
>
> There is the development files that really has their own snippets and all
> and then there is the one big file for the production server approach. I
> believe we can do this in several steps
>
> 1- as today we recommend locking down the server configuration
> once you are
> done with development by merging the jboss-services into one big STATIC
> jboss-services
>
> 2- merge ejb-jar jboss jboss-cmp in one big file so your beans are
> configured in one file. There are many advantages to this
> approach, namely
> you get rid of 100% of the indirection. Also it is all well.... in one
> page. We did discuss with David in January as to how to do that.
>
> 3- merge all of them, mbean,bean so the root tag is
> <jboss>
> <mbean>
> <bean>
> bla bla bla
>
> 4- the last gripe from the thread I am not convinced it had to do
> with being
> intimidated by mbean configuration files. I would have to think about this
> one, there are problems with separating creation and configuration (but it
> should be done imho) where the creation references a
> configuration by name,
> then the XML syntax usage should be simplified as much as possible, avoid
> XML verbosity, nobody likes it.
>
> 5- gui? pfffff it would need to be a JMX gui in our case, why not, but
> everybody talks about these and no-one does jack.
>
>
> marcf
> |-----Original Message-----
> |From: Sacha Labourey [mailto:[EMAIL PROTECTED]]
> |Sent: Friday, April 26, 2002 5:55 AM
> |To: marc fleury; Sacha Labourey; Juha-P Lindfors;
> |[EMAIL PROTECTED]
> |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
> |
> |
> |Well, it really depends IMHO. Would you really want to have
> |security information (users, groups, ...) in the same file as the
> |services (jboss-services.xml) ? I am not sure...
> |
> |> -----Message d'origine-----
> |> De : marc fleury [mailto:[EMAIL PROTECTED]]
> |> Envoye : vendredi, 26 avril 2002 14:53
> |> A : Sacha Labourey; Juha-P Lindfors;
> |> [EMAIL PROTECTED]
> |> Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
> |>
> |>
> |> I totally agree with the article, I believe we should merge our
> |> configuration files today, and get rid of the unreadable XML,
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
