Kees Jongenburger wrote:
2005/9/13, Nico Klasens <[EMAIL PROTECTED]>:
Hello Developers,
Yes, you are reading it correctly, I want to remove something almost
everyone in the community is using. I have some good reasons for this.
For a very long time, there is support for j2ee datasources in mmbase.
The jdbc module tries to implement the same functionality as these
datasources, but does not have what it takes to be a real connection pool.
There are numerous good pooling jars around. and I think supporting
data sources
Is very good. Adding support for data source does not necessary mean
that you need to use jndi or whatever sun calls it today so I don't
understand how you can remove jdbc.xml
jdbc.xml contains only settings for the MultiPool. Not using it will
make it obsolete.
I will vote -1 if it is not possible to run MMBase outside of
a container. What do you propose for that?
I'd be very very happy with any way to start mmbase
MMBase.setDataSource() sounds great to me!
We could keep the sources somewhere else with a extended
DatabaseStorageManagerFactory which return the GenericDataSource which
is wrapping the jdbc module implementatie.
But running outside a container does not make much sense, because the
bridge already depends on servlet classes.
Another advantage is that the web
application does not have environment settings which makes it much
easier to deploy to a different server.
This is actually false, the only thing you add is an extra layer of
configuration options and problems. not only your database setting and
mmbase settings must match , but also the jndi names in the server.xml
(in tomcat) and names in the web.xml configuration(int tomat) and the
name used in the application. and if you want to run 2 mmbases on one
server the checkout the mess.
Tomcat has the feature of context.xml files which are installed in
<tomcat>/conf/Catalina/localhost. These files can contain the stuff
which otherwise go in the server.xml. When you install a new web
application then tomcat will search for META-INF/context.xml in the war
and installs this in the tomcat dir. Redeployments will not overwrite
this file.
Redeployment in tomcat with jndi is much less a hassle for sysadmins
then modifying the jdbc.xml all the time. Sysadmins can match the jndi
name used in the application. Multiple jdbc.xml instances gives a bigger
mess, because the database settings are not on one place. Sysadmins
should know their appllcation server settings better then MMBase settings.
Jndi names will have extra value when you have an Application Lifecycle
Infrastructure. In dutch the term OTAP is used for this. OTAP is short
for Development, Test, Acceptance and Production. Using the same name
with different resource settings makes deployment to all environments a
breeze. With redeployments you don't have to re-apply the perfomance
tuning settings.
Also we do provide database specific storage strategies and table
creation, currently I think this is based on the jdbc driver name. How
is that going to work if your hack passes?
Just how it is now. Like I wrote before, the datasource stuff is in
MMbase for a long time. Almost 3 years, but it didn't work all the time.
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
