David,
I support not having a default database in the server. I think if we break the
usage of the server into development and production (as John discusses in his
note) we'll see that from a developer's perspective a DB is beneficial.
However, if your deploying for production you penalize the administrator to
remove things that are useful to developers. I think a good compromise is add
some scripts / plans that one can easily modify to create various resources
(DataSources, Queues, etc.).
Matt
David Jencks wrote:
Dain has been complaining that the default database is no more and IIUC
suggesting that we reinstate it and by default hook at least ejb
applications that don't have an explicit database configuration up to
it. Since I removed the default database I'd like to somewhat
preemptively explain my thinking.
Based on my support experiences with another app server that did
something like this, I think this is a really bad idea. What happened
there was that no one knew how to connect their app to a non- default
database, and we got zillions of problem reports based on the app using
the default database rather than the one that was misconfigured :-)
I also don't think that encouraging all applications to use the same
database is a very good policy. It certainly invites collisions
between applications and reduces portability.
We have the capabilities to build a derby database for a particular
schema, and package it , and to bundle a datasource configuration with
a j2ee app plan. This is used for the daytrader and uddi server
configurations. Rather than including a database no one should want
:-) and encouraging people to use it, I would rather see us automate
the construction of a configured database for an app, and the
construction and bundling of a datasource configuration with the app's
plan.
thanks
david jencks
- Re: Supporting applications that need a database Matt Hogstrom
-
