New approach for updating Datasource/Drivers via Admin Conso

[ccrouch]

Since the previous designs, mentioned at the beginning and end of this thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=59093, proved not to be feasible it is important to now find something which will definitely work. To that end the following approach is proposed based on the well trodden path of deploying drivers to /lib and datasources to /deploy.

Overall the approach requires two new templates to be implemented for use by the DeploymentService (http://www.jboss.org/wiki/Wiki.jsp?page=DeploymentService):

1) A template which takes a local URL to a driver jar and copies it into server//lib. If there is file with the same name already present in the lib directory the copy should not take place. There are a number of implications of this:
a) This DeploymentService operation will always succeed, subject to hardware failure. It will either copy the driver jar successfully or not attempt to write it all. This way there are no issues with jars being locked and the copy failing.
b) Just as is the case now, only one version of a driver jar will be recognized by the JBoss instance.
c) Just as is the case now, updating a driver jar from one version to another will require shutting JBoss down, removing the old jar from /lib and putting in the new one. As now, this will affect all datasources which use the driver class from that jar.
d) A user of the Admin Console will not have to upload a driver jar if they just want to use one that already exists in the /lib directory. In this case the Admin Console will simply not call the DeploymentService with this new template.
e) When creating a new datasource and uploading a new driver, the new datasource will require a server restart to become available.

2) A template which takes the various properties for a datasource and build the appropriate Local no-Tx, Local Tx or XA -ds.xml file. The Deployment service will then copy the -ds.xml to the /deploy directory. This may in fact turn out to need three separate templates, one for each datasource type.

Thanks

[starksm64]

Yes, this is the correct approach.

[dimitris]

If we fall back to the "traditional" jboss view, then:

1) Invoking on a template for copying static libs into ./lib is not the best way. It'd be more straightforward to have on the DeploymentService something like:

String[] listStaticLibs();
boolean uploadStaticLib(URL url);

(This doesn't solve the modifications issue, i.e. remove/update a lib)

2) From a design point of view, I believe it's much more clear to the admin to provide him an exact view of the system, it's restrictions and the ability to change it. In this sense you admit that the ./lib directory contains static libs that can only be changed with a reboot. So maybe a better interface is something like:

 boolean scheduleLibUpdate(URL url);
 boolean scheduleLibRemoval(String libname);

The 2 schedule methods will store the new lib/info for removal somewhere, then the server upon boot will have to make those changes.

The thing is, the changes need to take place *before* ./conf/jboss-service.xml is loaded, because this is where the libs are "loaded".

Maybe we could pass a new arg at command line, e.g. --update-libs to triger this behaviour.

In any case we could proceed with (1) and optionally do (2).

[starksm64]

A view of the static libs is not an admin view. An admin may not even know that a datasource has a jdbc driver jar. You have to make a distinction between a package and the installation of that package. A package is a self contained collection of descriptors, jars, os libs, etc. that needs to be installed into the server with version and duplication concerns resolved.

[ccrouch]

If we fall back to the "traditional" jboss view, then:

1) Invoking on a template for copying static libs into ./lib is not the best way. It'd be more straightforward to have on the DeploymentService something like:

String[] listStaticLibs();
boolean uploadStaticLib(URL url);

(This doesn't solve the modifications issue, i.e. remove/update a lib)

I am fine with which either implementing this as a template or new API on DeploymentSerivce, as long as the functionality requirements are met

2) From a design point of view, I believe it's much more clear to the admin to provide him an exact view of the system, it's restrictions and the ability to change it. In this sense you admit that the ./lib directory contains static libs that can only be changed with a reboot. So maybe a better interface is something like:

 boolean scheduleLibUpdate(URL url);
 boolean scheduleLibRemoval(String libname);

The 2 schedule methods will store the new lib/info for removal somewhere, then the server upon boot will have to make those changes.

The thing is, the changes need to take place *before* ./conf/jboss-service.xml is loaded, because this is where the libs are "loaded".

Maybe we could pass a new arg at command line, e.g. --update-libs to triger this behaviour.

In any case we could proceed with (1) and optionally do (2).

Agreed lets do (1). For the first phase we will not be requiring any removal or update of jars from /lib, so let's not do (2).

Overall the datasource component of the admin console will attempt to abstract away some of the details of the implementation. An administrator will optionally specify a driver jar to upload and some datasource properties, without having to know precisely what we are going to do with that jar. In future versions I hope that we will be able to move away from copying the driver jars into /lib, without affecting how administrators use the console.

Thanks