Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Sun, 28 Apr 2002, Michael Robinson wrote: > Someone who was literate in XML, but with no prior exposure to > the syntax and semantics of Java, could get more meaning out of the > XML version than the Java version. Really? To me both would look like nonsense. > that language will be more concise which I believe is what was requested. -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Sun, Apr 28, 2002 at 10:54:43AM +0300, Juha-P Lindfors wrote: > And here I was thinking the point of XML was to make it easier for > the *machine* to parse structured data. In which case, it would all be ASN.1. > > Yeah, I'll bet it does. Your example is actually the exception that proves the rule. Someone who was literate in XML, but with no prior exposure to the syntax and semantics of Java, could get more meaning out of the XML version than the Java version. And here's a good example of "bad DTD": > > >
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
> XML is now the lingua franca of human-readable structured data. > XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web > applications must be proficient in reading and writing XML. > > Saying "unreadable XML" in the 21st century is like saying > "unreadable French" in the 18th century. It's a statement of one's > illiteracy, not an indictment of the method of representation. And here I was thinking the point of XML was to make it easier for the *machine* to parse structured data. -- Juha, the illiterate
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Fri, Apr 26, 2002 at 05:52:54AM -0700, marc fleury wrote: > I totally agree with the article, I believe we should merge our > configuration files today, and get rid of the unreadable XML, You keep saying "unreadable XML". XML is now the lingua franca of human-readable structured data. XHTML, JSTL, Ant configs, SOAP, etc., mean that any serious designer of web applications must be proficient in reading and writing XML. Saying "unreadable XML" in the 21st century is like saying "unreadable French" in the 18th century. It's a statement of one's illiteracy, not an indictment of the method of representation. You can have "bad XML" (or, more to the point, bad DTDs), in just the way that you can have "bad French"; in both cases the burden of clarity is on the author. -Michael Robinson P.S. And, in fact, that's more or less the point of the cited article. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
> The fact is that for *production* the one file is good. This is your assumption... not always the case... actuall should not matter too much if the folks running thr show know what they are doing. Further more the many file config now can be turned into a single file config if desired. I think this is a very weak argument. > 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. Yes, glad to hear toy say this. BTW, if we abstract the configuration completly into an isolated service which deals with an config API model, then we can implement any fashion of configuration... single file, multi file, database whatever. Then let the user pick what the end method of persistence is. --jason - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I think this is a very bad idea... Yet if it comes down to this then we will need to implement some xslt stuff into the build system so that each module can contain the snippets of xml that get merged into the huge monolithic config file otherwise managing the configuration when running a build is going to be a royal mess. --jason Quoting marc fleury <[EMAIL PROTECTED]>: > I totally agree with the article, I believe we should merge our > configuration files today, and get rid of the unreadable XML, > > marcf > > |-Original Message- > |From: [EMAIL PROTECTED] > |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha > |Labourey > |Sent: Friday, April 26, 2002 1:38 AM > |To: Juha-P Lindfors; [EMAIL PROTECTED] > |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? > | > | > |Oh yeahh!!! That would be so cool!!! Only one config file, and one > |bigg monolithic application server that you can configure in > |this only big file! That would be so cool!!! And if we could merge > |the database configuration file, OS configuration files and Doom's > |configuration file in one big file, that would be *really* cool. > | > |humpf... > | > |> -Message d'origine- > |> De : [EMAIL PROTECTED] > |> [mailto:[EMAIL PROTECTED]]De la part de > |> Juha-P Lindfors > |> Envoye : vendredi, 26 avril 2002 08:05 > |> A : [EMAIL PROTECTED] > |> Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? > |> > |> > |> > |> Critique on JBoss configuration. > |> > |> http://www.javalobby.org/thread.jsp?forum=61&thread=3254 > |> > | > | > |___ > |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 > - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
by "locking down" I mean not only one file with restricted access but one central place with full configuration. Many files is interesting for independently configuring parts, "locking down" means the server configuration is fixed, locked, no messing with upgrade here and there in many files. The thing is in one place, the server configuration is "locked down". Having one file makes it simple to see/analyze/replicate/distribute. It was a very popular feature of BEA in production, one central place. Easy. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of danch |Sent: Friday, April 26, 2002 2:03 PM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; |[EMAIL PROTECTED] |Subject: Re: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |marc fleury wrote: | |> 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. | | |Sure. I do that by setting permissions of the config and deploy |directories such that only the JBoss user can do anything (including |read). What good does having one big honking file do here? I agree |that it does no harm, but I don't see how it 'locks down' the server. | | |> 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. |> | |Right, to really fix that will have to be a 4.0 issue. Once that |works, JBoss will be administrable from whatever can use JMX - JSR 88 |based tools, SNMP management tools, etc. | |my .02$ |danch | | |___ |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
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
marc fleury wrote: > 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. Sure. I do that by setting permissions of the config and deploy directories such that only the JBoss user can do anything (including read). What good does having one big honking file do here? I agree that it does no harm, but I don't see how it 'locks down' the server. > 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. > Right, to really fix that will have to be a 4.0 issue. Once that works, JBoss will be administrable from whatever can use JMX - JSR 88 based tools, SNMP management tools, etc. my .02$ danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Andreas Schaefer wrote: > Hi George > > >>The view on the configuration should be task-oriented, not >>file-oriented. >> > > Do you have an example for that ? > I know BEA WL 5 and > IBM WebSphere 3.5 and both did not provide configuration > on their UI. Both now provide configuration UIs. > > >>It's so easy to understand why a GUI is necessary. And why XML is >>necessary. >> > > When I was working on BEA WebLogic (yes, I was) they had a > usable UI but I still configured the server through the file. Mostly > because the heavy configuration stuff is not added to the UI. WL 5 had a UI whereby you could change things, but did not persist the changes, IIRC. > > A UI makes sense to discover all the services and deployments > and get statistics out of it which JSR-77 should do so. But I am > convinced that configuring a server is advanced stuff and should > not be made too easy otherwise it will break all the time. An > application server is not a volatile system with respect to configuration. Which is a very good reason to have the configuration secured, but not necessarily a good reason to not have a GUI. Do we still provide the (unsecured) JMX web interface as default, as we did in 2.4.x? I don't necessarily see myself as being a big user of a GUI, but I do understand why people really want one - it will cut down the learning curve, and we are getting to the point where some of the people using JBoss are people who program computers for a living, not necessarily because they like it! Also, in a large organization, the people charged with management of servers are not generally programmers persay - they'll knock together a perl script, but a sysadmin who knows Java is rare. A normal sysadmin will look at the xml in JBoss configuration files and suddenly have a fond rememberance of the last time he had to 'correct' a make file for some daemon on one of his boxes. And that's on the Unix side of things - think about NT administrators! > > Have fun - Andy Always! danch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
you bet post it! marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |McLaughlin |Sent: Friday, April 26, 2002 1:03 PM |To: [EMAIL PROTECTED] |Subject: Re: RE: [JBoss-dev] [JL] Is it time for a new enterprise |solution? | | |I am working on web based management application, at this point it |only supports the currently implemented parts of the JSR 77 spec |that exist in JBoss, but I envision this to be expanded to support |all service related management offered by the JBoss platform. If |there is sufficient interest, I can post this once I fix a few minor bugs |* * * | |View thread online: |http://jboss.org/forums/thread.jsp?forum=66&thread=14061 | |___ |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
Re: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I am working on web based management application, at this point it only supports the currently implemented parts of the JSR 77 spec that exist in JBoss, but I envision this to be expanded to support all service related management offered by the JBoss platform. If there is sufficient interest, I can post this once I fix a few minor bugs * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66&thread=14061 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Hi George > The view on the configuration should be task-oriented, not > file-oriented. Do you have an example for that ? I know BEA WL 5 and IBM WebSphere 3.5 and both did not provide configuration on their UI. > It's so easy to understand why a GUI is necessary. And why XML is > necessary. When I was working on BEA WebLogic (yes, I was) they had a usable UI but I still configured the server through the file. Mostly because the heavy configuration stuff is not added to the UI. A UI makes sense to discover all the services and deployments and get statistics out of it which JSR-77 should do so. But I am convinced that configuring a server is advanced stuff and should not be made too easy otherwise it will break all the time. An application server is not a volatile system with respect to configuration. Have fun - Andy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I have been waiting for that one ;-) Seriously, my day-time job does not leave much room for coding anything else. This leaves me of course open to all kinds of attacks... especially being ignored. Georg -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 18:49 To: [EMAIL PROTECTED]; 'Joseph Olson'; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? |It's so easy to understand why a GUI is necessary. And why XML is |necessary. Having to argue about these things makes me feel desolate. don't feel desolate, code marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
|It's so easy to understand why a GUI is necessary. And why XML is |necessary. |Having to argue about these things makes me feel desolate. don't feel desolate, code marcf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
The view on the configuration should be task-oriented, not file-oriented. It's so easy to understand why a GUI is necessary. And why XML is necessary. Having to argue about these things makes me feel desolate. Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Joseph Olson Sent: Friday, April 26, 2002 15:53 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? Instead of Gnome how about a Java Application--Desktop. And have the application GUI centered around Naked Objects(www.nakedobjects.org) Each pull-down window would be the front-end of a JBoss config file. >>> Dave Smith <[EMAIL PROTECTED]> 04/26/02 08:23AM >>> The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: > 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 ___ 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
AW: [JBoss-dev] [JL] Is it time for a new enterprise solution?
He, he. Volunteers? In the meantime, I heard from my colleagues who had actually done some MMC programming that it would be a real nightmare indeed :-( So much for expectations. Wonder if VS.net makes it more handy ... CGJ -Ursprüngliche Nachricht- Von: marc fleury [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 26. April 2002 16:53 An: Christian Riege Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list Betreff: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? interesting, let's see what becomes real. I like the idea of the MS console plugin marcf |-Original Message- |From: Christian Riege [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 7:43 AM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |hi, | |> 5- gui? pf it would need to be a JMX gui in our case, why not, |> but everybody talks about these and no-one does jack. | |i think what Dr. Jung mentioned @ JBossOne would be a killer: expose |the MBeans via SOAP and construct a Microsoft Management Console Plugin |to configure/maintain JBoss from that beast. | |other than that, my 2 (albeit euro) cents on the subject of the config |files: | |i don't give one cent on how the config file looks like (i.e. XML, |key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. | |consolidation/deconsolidation of the configuration has its own pros and |cons. personally i would like to have both available: small files for |development/testing purposes (un-deploy of an MBean by simply issuing |'mv mbean.jar ../nodepoy') and one huge file for locking down my |production servers. | |i *think* you can achieve both by using several XML files which can be |merged (at the users option, with a *simple* command) into one big XML |file: develop/test with the small ones until you're happy. hit the |"lockdown config" button. get a large file which is the sum of the |small ones. xml namespaces might come in handy here?! | |rgds, | christian ___ 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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
interesting, let's see what becomes real. I like the idea of the MS console plugin marcf |-Original Message- |From: Christian Riege [mailto:[EMAIL PROTECTED]] |Sent: Friday, April 26, 2002 7:43 AM |To: marc fleury |Cc: Sacha Labourey; Juha-P Lindfors; JBoss Dev list |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |hi, | |> 5- gui? pf it would need to be a JMX gui in our case, why not, but |> everybody talks about these and no-one does jack. | |i think what Dr. Jung mentioned @ JBossOne would be a killer: expose the |MBeans via SOAP and construct a Microsoft Management Console Plugin to |configure/maintain JBoss from that beast. | |other than that, my 2 (albeit euro) cents on the subject of the config |files: | |i don't give one cent on how the config file looks like (i.e. XML, |key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. | |consolidation/deconsolidation of the configuration has its own pros and |cons. personally i would like to have both available: small files for |development/testing purposes (un-deploy of an MBean by simply issuing |'mv mbean.jar ../nodepoy') and one huge file for locking down my |production servers. | |i *think* you can achieve both by using several XML files which can be |merged (at the users option, with a *simple* command) into one big XML |file: develop/test with the small ones until you're happy. hit the |"lockdown config" button. get a large file which is the sum of the small |ones. xml namespaces might come in handy here?! | |rgds, | christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
hi, > 5- gui? pf it would need to be a JMX gui in our case, why not, but > everybody talks about these and no-one does jack. i think what Dr. Jung mentioned @ JBossOne would be a killer: expose the MBeans via SOAP and construct a Microsoft Management Console Plugin to configure/maintain JBoss from that beast. other than that, my 2 (albeit euro) cents on the subject of the config files: i don't give one cent on how the config file looks like (i.e. XML, key=value, ...) AS LONG AS I CAN EDIT IT WITH MY TEXT-EDITOR OF CHOICE. consolidation/deconsolidation of the configuration has its own pros and cons. personally i would like to have both available: small files for development/testing purposes (un-deploy of an MBean by simply issuing 'mv mbean.jar ../nodepoy') and one huge file for locking down my production servers. i *think* you can achieve both by using several XML files which can be merged (at the users option, with a *simple* command) into one big XML file: develop/test with the small ones until you're happy. hit the "lockdown config" button. get a large file which is the sum of the small ones. xml namespaces might come in handy here?! rgds, christian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
On Fri, 26 Apr 2002, marc fleury wrote: > 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 umm, we dont really have any implementation for persistence at the moment so yes it does lack :) -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
|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 |> > |> > |> > |> > 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? pf 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
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
1. I'm hoping to work on the "one file for ejb config" very soon as soon as testsuite errors = 0 and the jca is marginally more stable (i.e. I quit changing it, it seems to work OK). 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. 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 > > > > > > > > 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? pf 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 infor
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Instead of Gnome how about a Java Application--Desktop. And have the application GUI centered around Naked Objects(www.nakedobjects.org) Each pull-down window would be the front-end of a JBoss config file. >>> Dave Smith <[EMAIL PROTECTED]> 04/26/02 08:23AM >>> The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: > 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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I totally agree with this. One of the ideas I have been kicking around is developing some production tools, which would automate the steps you describe. Part of this is david's code to merge the xml files during deployment; once they are merged and defaults unrolled, we write the complete file back out to disk. Anyway, this is a 3.1 feature and we aren't 3.0 final yet. I just can't get over the fact this guy didn't have the stones to post this to a jboss list or forum. -dain marc fleury wrote: > 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 > > > > 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? pf 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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
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, mb
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
OK, I agree. (and, I wasn't aware of the "PRODUCTION-LOCKING" need.) > -Message d'origine- > De : marc fleury [mailto:[EMAIL PROTECTED]] > Envoye : vendredi, 26 avril 2002 15:51 > A : Sacha Labourey; Juha-P Lindfors; > [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? > > > Sacha, > > this is configuration for JBoss4.0. > bla... ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
I think that is better to have multiple conf files, this resolve the problems described by Sacha (deploy/redeploy). For the GUI problem, I think that we have already implemented jsr 77, we can start to implement jsr 88 and we can wait that SUN :-) extends netbeans to handle these specifications. Claudio > -Original Message- > From: Sacha Labourey [SMTP:[EMAIL PROTECTED]] > Sent: Friday, April 26, 2002 3:30 PM > 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 > > > > > > > > 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? pf 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
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 > > > > 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? pf 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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
The problem is not the configuration files its the interface. What you really need is a gnome control panel type interface which would allow you to configure and manage your jboss enviroment. This is bigest problem with open source projects, no-one likes writting front ends, it's boring and not sexy. Don't put the configs in 1 file, 20 piles of shit or 1 big pile of shit it is still a pile of shit. On Fri, 2002-04-26 at 08:54, Sacha Labourey wrote: > 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
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 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? pf 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
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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
no it means merging the configuration files, I will do it when I have the time as there is no direction in the configuration files today, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Georg |Schmid |Sent: Friday, April 26, 2002 2:05 AM |To: 'Juha-P Lindfors'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | |(How can one believe that it is possible to configure a whole enterprise |from one file?) | |The critique only means, that Jboss needs a configuration GUI (or at |least some command line tool like j2eeadmin). | |Sun's intention was from the start, that nobody is going to look at the |config files themselves. |In this way you can design the config files as required by technology. | |Otherwise you keep running into the conflict between readability/ease of |use for humans and |usability from the software's perspective. | |Jboss is a really great product with many features I could not do |without. | |But I cannot understand why the Jboss developers keep badmouthing |gui-based solutions. |(Don't get me wrong: I am not one of those, who have never seen a |command line, just the opposite. VI and |the command line have their limitations, though). | |I predict, that within the next year there will be Jboss-(G)UI, simply |driven by public demand. |(Look at the Veritas Volume Manager's Java/Swing GUI. Something like |that would be great). | |Regards |Georg | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]] On Behalf Of |Juha-P Lindfors |Sent: Friday, April 26, 2002 08:05 |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | | |Critique on JBoss configuration. | |http://www.javalobby.org/thread.jsp?forum=61&thread=3254 | |-- Juha | | | |___ |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
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, marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Sacha |Labourey |Sent: Friday, April 26, 2002 1:38 AM |To: Juha-P Lindfors; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] [JL] Is it time for a new enterprise solution? | | |Oh yeahh!!! That would be so cool!!! Only one config file, and one |bigg monolithic application server that you can configure in |this only big file! That would be so cool!!! And if we could merge |the database configuration file, OS configuration files and Doom's |configuration file in one big file, that would be *really* cool. | |humpf... | |> -Message d'origine- |> De : [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED]]De la part de |> Juha-P Lindfors |> Envoye : vendredi, 26 avril 2002 08:05 |> A : [EMAIL PROTECTED] |> Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? |> |> |> |> Critique on JBoss configuration. |> |> http://www.javalobby.org/thread.jsp?forum=61&thread=3254 |> | | |___ |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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
(How can one believe that it is possible to configure a whole enterprise from one file?) The critique only means, that Jboss needs a configuration GUI (or at least some command line tool like j2eeadmin). Sun's intention was from the start, that nobody is going to look at the config files themselves. In this way you can design the config files as required by technology. Otherwise you keep running into the conflict between readability/ease of use for humans and usability from the software's perspective. Jboss is a really great product with many features I could not do without. But I cannot understand why the Jboss developers keep badmouthing gui-based solutions. (Don't get me wrong: I am not one of those, who have never seen a command line, just the opposite. VI and the command line have their limitations, though). I predict, that within the next year there will be Jboss-(G)UI, simply driven by public demand. (Look at the Veritas Volume Manager's Java/Swing GUI. Something like that would be great). Regards Georg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Juha-P Lindfors Sent: Friday, April 26, 2002 08:05 To: [EMAIL PROTECTED] Subject: [JBoss-dev] [JL] Is it time for a new enterprise solution? Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61&thread=3254 -- Juha ___ 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
RE: [JBoss-dev] [JL] Is it time for a new enterprise solution?
Oh yeahh!!! That would be so cool!!! Only one config file, and one bigg monolithic application server that you can configure in this only big file! That would be so cool!!! And if we could merge the database configuration file, OS configuration files and Doom's configuration file in one big file, that would be *really* cool. humpf... > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Juha-P Lindfors > Envoye : vendredi, 26 avril 2002 08:05 > A : [EMAIL PROTECTED] > Objet : [JBoss-dev] [JL] Is it time for a new enterprise solution? > > > > Critique on JBoss configuration. > > http://www.javalobby.org/thread.jsp?forum=61&thread=3254 > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JL] Is it time for a new enterprise solution?
Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61&thread=3254 -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
