|2. I think Sacha's point about granularity and location of changes and |persistence is REALLY IMPORTANT!!!!! I've made a couple of suggestions |about how mbean persistence relates to the files, only Jason responded.
juha is the man for the mmbean persistence, sacha will be lead on this for 4.0 :) we are aware of the problem let's hold our horses for now. Soon enough (like in a month or so). marcf |Basically I think to use mbean persistence we have to think of the mbean |server like a database that remembers its current state, even over |shutdown/restart. Then the xml config files need to be viewed as update |scripts to this database. I don't really know if this is a good idea, it |is certainly a different way of thinking than we have now, but I think it |is worth considering and experimenting with. | |thanks |david jencks | | |On 2002.04.26 09:29:36 -0400 Sacha Labourey wrote: |> 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 |> |> _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
