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,
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
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.
jns:implements name=MyInterface/
jns:implements name=ThatOtherInterface/
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
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
(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
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
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:
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 :
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
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
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
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.
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
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
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
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
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
|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
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
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:
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
|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]
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,
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 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,
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
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
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.
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
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
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
32 matches
Mail list logo
