You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2006/02/02 02:21:45 UTC
Supporting applications that need a database
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
Posted by John Sisson <jr...@gmail.com>.
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
>
>
I agree that it is preferable to automate the construction of databases
rather than encouraging users/apps to use a default database.
For demo type applications, complete automation of the creation of the
database at deployment time would be nice.
For non-demo applications deployed in an enterprise environment, the DBA
would probably want to be involved in the creation of the database and
possibly customize the DDL, security etc.
John
Re: Supporting applications that need a database
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
+1
On 2/1/06, David Jencks <da...@yahoo.com> 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
Posted by lichtner <li...@bway.net>.
I don't generally like default things when the default is a completely
arbitrary choice, as is the case here. This is not like a default port
number.
If someone is having trouble configuring a database then he/she or someone
else should write a tool that tries to configure out the settings, not
dumb down the software for everyone else.
On Wed, 1 Feb 2006, 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
>
>