Re: A few things

[Doug Collinge <dc...@abyssnet.com>]

It suddenly strikes me that, if you used a Javabean as the source
of your configuration properties, you could very easily serialize
it to XML with one of those XML serializers.  Then you would have
the properties in an XML file in a reasonable format (depending
on the serializer) and someone else could come along later with a
GUI builder and take about an hour to write a nice Swing control
panel for your configuration bean.

Of course, if you didn't like the XML you were getting from your
serializer you could easily roll your own format with any XML
parser you had handy. The GUI wouldn't have to change.

(now back to lurking...)

James Todd wrote:
> 
> comments included ...
> 
> - james
> 
> Brill Pappin wrote:
> 
> > ----- Original Message -----
> > From: James Todd <jw...@pacbell.net>
> > To: <ge...@jakarta.apache.org>
> > Sent: Sunday, December 05, 1999 5:00 AM
> > Subject: Re: A Few things
> >
> > I don't think you have to worry about being arrested... the XML police don't
> > get started until after the new year.
> 
> phewww ... that is one less warrant out for my arrest i need worry about :)
> 
> >
> > Seriously, XML is a great tool and I use it often myself, however I think
> > because its new and popular, it sometimes gets used in situations that don't
> > really need it. Lets face it, XML can be a cumbersome beast if used
> > improperly, or where its not needed.
> 
> i'm on the other side of the fence on this one. with respect to prototypes,
> the work i'm involved with at the moment, i'm finding that unvalidated xml
> structures allow for a huge amount of flexibility ... when things have to be
> tightened up a bit (ie development/production cycle) then i will consider
> validating the xml to improve integrity or removing the "stub" with the
> better albeit likely more heavy-weight replacement.
> 
> >
> > This is true, the data can be self-documenting to some degree, however, I
> > don't think it makes it any more simple to change, when you don't know what
> > the model is supposed to look like,  it just make you deal with a different
> 
> one perspective is indeed the data model ... what i was actually talking
> about was more to the perspective that a "well described" (ie intuitive
> element and attribute names) xml document is likely tobe more readily
> understandable merely from a contextual perspective then most other
> document formats available. eg: application prop files over xml constructs.
> i've done *lots* of pretty wild "dynamic application" prop stuff in the past,
> so much so that folks started bitching about the complexity of the prop file
> format. i have a feeling that had i formatted the data in xml folks would've
> welcomed it better simply for the "perceived understandability" i mentioned
> above. they would've had nice xml editors to use as well. from this experience
> it was the same data yet the presentation makes all the difference. more on
> that in a moment.
> 
> >
> > set of ideas... that have their own drawbacks. I don't think "new-eyes" will
> > find it all that easy, unless they are new XML'ized eyes. I mean, it would
> > be very easy to screw up an XML documented, so it was no longer well formed,
> > and not be able to see the problem.
> 
> it is really easy to screw up most configuration, this is the example i had in
> mind, let alone xml formatted files. from the developer's perspective we at
> least have the chance to provide intelligable messages when things go awry
> with xml formatted data all the while using "standard" api's.
> 
> from the consumer's perspective xml formatted data, i believe, is much more
> digestable then alternatives.
> 
> >
> > Basically, with the library I was talking about, XML would work, but would
> > not be the only or best solution... not that it wouldn't be a good solution
> 
> more then one solutions is a good thing is a good thing indeed.
> 
> when i floated the idea of an "admin config" project months back followed
> by a baseline ascertion (eg: http/servlet/xml) folks had, well, concerns. after
> batting about some clarification messages stating the recommended baseline,
> an understanding that it was only a baseline (a starting point) with which
> "peer" solutions should be able join in and discussing all issues concerning
> the basline decisions i believe a happy consensus was met ... then i got busy
> with the servlet 2.2 thingy and had to step back.
> 
> >
> > though... The fact is, that in a robust registry system... allowing the user
> > to edit the file directly could cause serious problem... i.e. a serialized
> > array may look editable, but how would anyone know?
> 
> in my initial proposal i addressed the "folks can still edit the config file
> while
> others use the sexy ui" directly without compromise the data integrity. it can
> and should be done. some folks don't want to or can't always use ui's.
> 
> in my previous-previous gig i had "file watcher" that would signal when
> the contents changed.
> 
> >
> > system... In fact, we all know that most of the world makes it decisions on
> > the look of software, and not always on its ability. Not that we do, but
> 
> yep ... and a nice admin tool would help out greatly although i believe having
> a nice enough admin tool would 1) showcase servlet and other server-side
> java technologies nicely and 2) would be quite pratical for the developer if
> done slick'n mean.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org

Re: A few things

[co...@eng.sun.com]

Brill Pappin wrote:

> Someone mentioned using JNDI for the configuration registry... Anyone taken
> a look at InfoBus? it would work well with an XML model... Actually, it
> might be a good idea to incorporate the bean model into all components of
> the server... that way each piece could be notified that *the* or *its*
> properties had changed... allowing property changes on the fly, without
> restarting.

JNDI can work with XML data too.

Yes, I think that using bean model is the best way to decouple the
agent ( RMI, http, etc) and  managed components ( Context, etc).
That also means tomcat will have no dependencies on a particular
configuration/admin mechanism.

JNDI would be very nice because it allows you to use a directory service
to store configuration data - and use generic ( and existing ) tools.
XML is great for storing and exchanging config data, but it is no substitute
for a real directory service. ( IMHO :-)


> BTW- A little off topic, but I'd like to see a hook into the servlet
> classloader, to force a reload and/or re-compile of the servlets and JSP
> manually. (just another way to speed it up developers).

I'm working on it, after we have a stable build and we mark the wokspace
I'll check in some code.

Costin

Re: A few things

[Paul Lamb <pa...@redfork.com>]

> BTW- A little off topic, but I'd like to see a hook into the servlet
> classloader, to force a reload and/or re-compile of the servlets and JSP
> manually. (just another way to speed it up developers).
>
Bill,

I think the front-end is a great idea. But this would be amazingly helpful
right now. I would like to see an actual interface exposed for section 9.7
"Replacing a Web Application" in the 2.2 spec; while I can see this being
something added by container providers, something standard would be optimal.

Paul Lamb

Re: A few things

[Brill Pappin <br...@jmonkey.com>]

Someone mentioned using JNDI for the configuration registry... Anyone taken
a look at InfoBus? it would work well with an XML model... Actually, it
might be a good idea to incorporate the bean model into all components of
the server... that way each piece could be notified that *the* or *its*
properties had changed... allowing property changes on the fly, without
restarting.

BTW- A little off topic, but I'd like to see a hook into the servlet
classloader, to force a reload and/or re-compile of the servlets and JSP
manually. (just another way to speed it up developers).


- Brill Pappin
  www.jmonkey.com

  The sooner you fall behind,
  the more time you will have
  to catch up."

----- Original Message -----
From: James Todd <jw...@pacbell.net>
To: <ge...@jakarta.apache.org>
Sent: Tuesday, December 07, 1999 5:35 AM
Subject: Re: A few things


>
> yep ... let me see if i can recap in as few words as possible my
> "baseline" perspectives on this:
>
>     centralized "admin service": servlet
>
>     transport protocol: http/s
>
>     data exchange format: xml
>
>     persistent format: xml
>
>     ui: html/jsp/applet
>
> all of the above are pretty much tried'n true and should allow
> for maximum flexibility with which the various components can
> be designed/developed independently yet will not preclude
> fancier and possibly more robust api's/features being added to
> the mix as deemed appropriate.
>
> tomcat itself has an rmi hook to stop the server. the admin
> service could simply invoke this call and we'd have a fancy
> "stop" feature. next up it'd cool to take down a webApp
> followed by a webApp re-cycle (re-deploy). it should be
> quite trivial and actually a big help to a servlet developer.
>
> starting with the concept of the tomcat server.xml config file
> a framework could be built by which one could "register" the
> server instance/config file with the "admin service" after which
> one could manipulate the config data via one of the admin
> service's ui's, api's (ie http get/post) and/or editing the file
> directly) without losing data intergrity. nirvana perhaps but i
> do feel it is achievable. at one time i threw out a one-pager
> diagram which expresses this view ... better then some late
> night ramblings perhaps.
>
> Doug Collinge wrote:
>
> >
> > (now back to lurking...)
> >
>
> come out of the shadows ... the water is fine   :)
>
> - james
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>

Re: A few things

[James Todd <jw...@pacbell.net>]

yep ... let me see if i can recap in as few words as possible my
"baseline" perspectives on this:

    centralized "admin service": servlet

    transport protocol: http/s

    data exchange format: xml

    persistent format: xml

    ui: html/jsp/applet

all of the above are pretty much tried'n true and should allow
for maximum flexibility with which the various components can
be designed/developed independently yet will not preclude
fancier and possibly more robust api's/features being added to
the mix as deemed appropriate.

tomcat itself has an rmi hook to stop the server. the admin
service could simply invoke this call and we'd have a fancy
"stop" feature. next up it'd cool to take down a webApp
followed by a webApp re-cycle (re-deploy). it should be
quite trivial and actually a big help to a servlet developer.

starting with the concept of the tomcat server.xml config file
a framework could be built by which one could "register" the
server instance/config file with the "admin service" after which
one could manipulate the config data via one of the admin
service's ui's, api's (ie http get/post) and/or editing the file
directly) without losing data intergrity. nirvana perhaps but i
do feel it is achievable. at one time i threw out a one-pager
diagram which expresses this view ... better then some late
night ramblings perhaps.

Doug Collinge wrote:

>
> (now back to lurking...)
>

come out of the shadows ... the water is fine   :)

- james