Sacha, this is configuration for JBoss4.0.
The fact is that for *production* the one file is good. For actually administering and configuring a server the many files is better, yes, but they are different world, the notion of "locking down" a server is VERY REAL. In the admin/configuration category, the persistence of the configuration above and beyond the current xml is not done right now the fact that it is mixed with the creation is a weakness we are carrying over from the 2.0 days. One step at a time, when we finalize 3.x releases i.e. in a couple of weeks, I say we move on 4.0 development and the overhaul of the admin with persistence through the modelmbeans will require some tweaking of the XMBeans (I believe the current implementation lacks) where you put your own persistence in there. There are some ideas as to how to make the the persistence transparent and distributed in the MMBeans. That is the way to go and that is where we should think. The "readers" of the centralized file are aware of what they are monitoring. A given EJB persistence (one of the ideas) would know that it is monitoring changes in that particular configuration for that bean, and it can also come with some knowledge of that format so you don't need to go with the "bare XML". That will enable you to provide defaults for example so you can override say the JCA configuration of datasources and just specify the bare minimum. I repeat that this discussion is premature. At this point we are running on empty when it comes to user feedback as the limits of the current system are not known by the users we are guessing based on our abilities, this always fails. We see them, we think about them but we need the user. Time to put it out and let the users say "this would be good" "that would be good". Wait for more datapoint to come to our group and then we will sit down and think about JBoss4.0 configuration. We will make the new app-server generation easy to use, I will prove it. Being Admin friendly is the key to success. Don't forget that. marcf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Friday, April 26, 2002 6:30 AM |To: marc fleury; Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |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
