Kees Jongenburger wrote:
jdbc.xml contains only settings for the MultiPool. Not using it will
make it obsolete.
but it's also a module that made it possible to have the different
implementation running right?
No, implementation selection is based on datasource driverclass in
lookup.xml or mmbaseroot.xml.
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.
Again I am fine with removing the code. But I want a way do make it
possible to use a datasource acquired by other means then jndi. How
are we supposed to run the junit tests
otherwise?
We just need another storagemanagerfactory.
Almost all mmbase junit classes are integration testcases. Integration
testcase usually run in a deployed environment. Like always MMbase does
it differently.
But running outside a container does not make much sense, because the
bridge already depends on servlet classes.
Yes, I think this is a design mistake. still the bridge is usable
outside of a servlet container
What is going to break when we correct that mistake?
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.
I just makes things it harder to work. Don't even start with changing
the name of the datasource. It requires the database driver to be put
in the container and makes it impossible to distribute mmbase as a
working war.
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.
doesn't make sence either. a production and test server should have
the same settings, path Image Magic, the more you rely on external
configuration the more things can mess up.
In OTAP terms, Acceptance and Production are the same in an ideal
world., but you don't want your acceptance server pointing to
production. Development is for writing component code. Test is for
testing the components interaction. So development and test does not
have to be the same at all.
Iow you have to do configuration management and mmbase makes it much
harder then it could be.
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.
Perhaps Gomez can shine some light on that.I think you will need to
configure the
database type or something similar
The lookup.xml for the datasource driverclass or mmbaseroot.xml
Nico
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
