On Mon, Mar 24, 2008 at 4:33 PM, Wolfram Rittmeyer
<w.rittmeyer_at_jsptutorial.org> wrote:
> Jason Lee wrote:
> I think using asadmin create-jdbc-connection-pool and asadmin
> create-jdbc-resource already offer a simple way to add resources.
Right, and I have used those, but I don't think it offers the same
ease of use. For example, with the XML approach, not only can one
just drop in a single file and create one or more Connection Pools and
DataSources, but by simply removing the file, those same resources can
be quickly and easily removed in one simply, (mostly ;) error-proof
step. That's assuming a lot, but you should get the picture.
> I personally do prefer a scripting solution to xml but that's just me.
> Since you stated in your RFE that you are missing the xml-based
> configuration I wonder if it offers additional functionality. In other
> words: Is it just a matter of taste which solution to use (given that
> the xml-solution gets implemented) or are there use-cases where you
> think the xml-solution offers more flexibility or power?
It probably is just a preference, but I think it makes sense: I
think deploying an would be much simpler if we can provide a text file
which the user can edit and place in a deployment directory, as
opposed to telling a user to open a command prompt, run these series
of seemingly arcane commands (note that I LOVE the command line :).
Oh! You better make sure things are in the search path, and, oh yeah.
You'll need shell privileges on the server in question. With an XML
file, all one needs is (shudder) FTP access. Granted, such a scenario
may not be the norm, but I have seen hosting providers who do not
offer/allow shells, so it's not completely unreasonable.
> BTW: This mail of mine is just born out of curiosity. I am no member of
> the GF team and thus only interested in why you propose this solution ;-)
Fair enough, but that's why I posted my question before I started
coding. I really don't want to pop out of the blue with a working
solution for a problem no one else sees as a problem. *I* think it's
useful, but if there's no chance of it being merged in, there's no
real reason to implement it... though, shooting from the hip, it might
be possible to put all of this in some sort of application archive and
handle it all from "user space", which makes it possible to provide
the support without having to modify GlassFish. We'll see what the
movers and shakers think... :)
Thanks for the feedback. :)
--
Jason Lee, SCJP
Software Architect -- Objectstream, Inc.
Mojarra and Mojarra Scales Dev Team
https://mojarra.dev.java.net
https://scales.dev.java.net
http://blogs.steeplesoft.com