[ccrouch]

I mean't deployment service should always be invoked with a local url (file:/....../bla.jar). A remote would work too (http://...), as long as someone can serve it :)

I think we'll be ok, for the first phaze...

Agreed. I think we will probably end up relying on JBoss/Remoting to "serve" files up for remote clients, rather than a web server.

[ccrouch]

Ok, that was a great description of the steps.

How about this?

A file is transfered to a directory local to the AdminConsole as described. Then the Console prepares the input properties for the template to be executed. Part of the input properties is the URL to the local file. When the template runs, it copies the file over to the deployment.

In the remote scenario, the only thing that changes is the intermediate layer that takes care of transfering the file over (locally to the remote machine). The other steps are the same.

In the template config we would have something like:

<template-config>
 ... bla bla properties
 <property name="JarURL" type="java.net.URL"/>
 ...
 <file-list>
 <file src="files"/> <!-- deep copy this from template dir -->
 <file src="${JarURL}"/> <!-- copy the pointed resource -->
 <file-list/>

The only "problem" I see, is whenever we need to rerun the template the caller needs to make sure the URL is valid, i.e. the file exists so it can be copied.

To solve the problem you describe how about not using a .sar to hold the -ds.xml and the driver .jar but instead use a -service.xml with an embedded classpath element and just copy the driver jar straight into a DeploymentService controlled directory. I think there are three scenarios of interest:

A) Create a new datasource:
1) A file is transfered to a directory local to the AdminConsole as described.
2) Then the Console prepares the input properties for the template to be executed. Part of the input properties is the URL to the local file.
3) When the template runs, it copies the file specified by JarURL into ./deploymentservice/datasource_jars/. Then it creates a -service.xml and copies it into ./deploy/deploymentservice/ making sure to include a classpath element which points to the driver jar in ./deploymentservice/datasource_jars/


B) Update a datasource, not changing the driver:
1) No file transfer step this time, for example we are just changing the jndi name
2) Then the Console prepares the input properties for the template to be executed. Since we don't have a URL pointing to a newly uploaded file we need the URL of the existing driver jar, which we can get in the following manner:
a) Call listDeployed() on MainDeployer which will return a Collection of DeploymentInfo objects.
b) Iterate through those finding all the ones where the URL contains ./deploy/deploymentservice.
c) Iterate through those finding all the ones which have MBeans whose ObjectNames are of the form jboss.jca:service=LocalTxCM,* or jboss.jca:service=TxCM,* or jboss.jca:service=??XA???.
d) Remove any DeploymentInfo objects where the package name of the ManagedConnectionFactory MBean does not contain "jdbc". This obviously weeds out JCA resources which are not Datasources.
e) This give us a list of the datasources.
f) [When the user selected a datasource to update,step 0), they would have effectively selected one from this list of DeploymentInfo objects]
g) Since the selected DeploymentInfo object will correspond to a file in ./deploy/deploymentservice/ which contains a classpath element, then the contents of that element should be in the classpath attribute of the DeploymentInfo object.
h) We now have the contents of the classpath element which will infact point to the existing driver jar e.g. ./deploymentservice/datasource_jars/???.jar
3) When the template runs, it copies the file specified by JarURL into ./deploymentservice/datasource_jars/. [This will really be copying a file onto itself]. Then it creates a -service.xml and copies it into ./deploy/deploymentservice/ making sure to include a classpath element which points to the driver jar in ./deploymentservice/datasource_jars/


C) Update a datasource, change the driver:
This is similar to scenario A) since a new driver file will be uploaded.

[ccrouch]

Given the posts thru Jan 27th on this thread

http://www.jboss.org/index.html?module=bb&op=viewtopic&t=59343

it appears that neither of the following approachs for updating Datasources in JBoss will in general be workable:

a) Wrap a -ds.xml and driver jar in a .sar and deploy/undeploy that.
b) Have a driver .jar and a separate -service.xml referencing it, then undeploy/deploy the approriate one depending upon what is being updated.

A new thread will posted on this forum shortly outlining another alternative.

Thanks