[peterj]

Just now checked in code that implements the ability to update existing data sources. There is now a new method, updateDataSource, with the same signature as the existing createModule method. See the comments at org.jboss.services.deployment.DeploymentServiceMBean.updateDataSource for more details. And there are unit tests also.

[chilin]

I tried updating "DefaultDS" by invoking updateDataSource with the following parameters:

updateDataSource(?hsqldb-ds.xml?, ?local-tx-datasource?, attributeMap);

... but updateDataSource() reported a ?module does not exist? error attempting to locate the ?hsqldb-ds.xml? file under the .../server/deploy/deployment-service directory. Looks like the current implementation of updateDataSource() only looks for the module under the DeploymentService's DeployDir!

Here're the messages and exception:

09:09:09,542 INFO [DeploymentService] updateDataSource(module=hsqldb-ds.xml, template=local-tx-datasource, properties={jndi-name=DefaultDS, use-java-context=true, connection-url=jdbc:hsqldb:C:\jboss-head\build\output\jboss-5.0.0.Alpha\server\default\data\hypersonic\localDB, blocking-timeout-millis=30000, driver-class=org.hsqldb.jdbcDriver, idle-timeout-minutes=0, security-config=SECURITY-DOMAIN, min-pool-size=3, user-name=sa, prepared-statement-cache-size=32, security-domain=HsqlDbRealm, max-pool-size=20, no-tx-separate-pools=false})

09:09:14,448 ERROR [DeploymentServiceDataSourceHelper] updateDataSource failed

java.lang.Exception: module does not exist: C:\jboss-head\build\output\jboss-5.0.0.Alpha\server\default\deploy\deployment-service\hsqldb-ds.xml

at org.jboss.services.deployment.DeploymentManager.getDeployedURL(DeploymentManager.java:516)

at org.jboss.services.deployment.DeploymentManager.updateDataSource(DeploymentManager.java:382)

at org.jboss.services.deployment.DeploymentService.updateDataSource(DeploymentService.java:222)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

.....................

[peterj]

The code to lookup the existing -ds.xml file was corrected and should now work even for -ds.xml files that are not located in the deployment service's deployment directory. In other words, the admin console should now be able to update DefaultDS.

[chilin]

The DefaultDS's config file (hsqldb-ds.xml) was successfully located and updated. However when the file was re-deployed, the following exception occurred:

11:21:06,926 WARN [ServiceController] Problem starting service jboss.ejb:persistencePolicy=database,service=EJBTimerService
java.lang.IllegalStateException: Cannot find datasource meta data: jboss.jdbc:datasource=DefaultDS,service=metadata
at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.init(GeneralPurposeDatabasePersistencePlugin.java:101)
at org.jboss.ejb.txtimer.DatabasePersistencePolicy.startService(DatabasePersistencePolicy.java:103)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
.......

Comparing the original and updated hsqldb-ds.xml file, I discovered that the following settings are missing from the updated file:

 <!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
 <metadata>
 <type-mapping>Hypersonic SQL</type-mapping>
 </metadata>

 <!-- When using in-process (standalone) mode -->
 <depends>jboss:service=Hypersonic,database=localDB</depends>

Missing the "depends" clause didn't seem to cause any immediate side effect (the file was re-deployed successfully), but missing "metadata" caused the above exception (although the comment says it's optional)!

Looks like we need to maintain the "type-mapping" (and possibly also the "depends") settings in the Admin Console's DataSource class and pass them to updateDataSource() during an update. However, I can't figure out where to locate these settings from the four mbeans associated with DefaultDS. Anyone has any idea?

[peterj]

We have a problem.

I looked at the original templates used to create data sources. Those templates enable you to define dependencies and metadata. Well, sort of. The only metadata that can be specified is the type-mapping.

Since I based the update template on the creation templates, the update templates will generate dependency and type-mapping properties if those are given in the map. The problem is that if I change the template to simply copy those settings from the original xml file, then there is a possibility for duplicate settings.

So we have two possible options:

Option A is to find that data so that it can be supplied on an update. Chi, I recall you mentioning that you were able to find the dependency but not the type-mapping.

Option B is for the template to check if these properties are specified, and if so, generate them, and if not copy them from the old xml file. Unfortunately option B makes these two properties bahave differently than the rest of the properties. In addition, we would need a mechanism to not copy those properties if they were not given and not desired in the updated definition of the data source.

I will work on changing the templates to support option B, with a mechanism to not copy those properties (set the property value to an empty string), if that is desired.

Meanwhile, Chi and Charles, any ideas for finding the type-mapping so that we can do option A?

[chilin]

Actually I was able to find the type-mapping (in jboss.jdbc:datasource=<datasource name>,service=metadata), but not the dependency. I'll continue with the research to see if I can figure out, but if someone can give me a clue, it'll be greatly appreciated!

[adrian.brock]

Clue: Read the FAQ

[peterj]

I have read every question (topic heading) in http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossFrequentlyAskedQuestions, http://wiki.jboss.org/wiki/Wiki.jsp?page=FAQJBossJCA. and http://wiki.jboss.org/wiki/Wiki.jsp?page=FAQJBossJMX.

I also did a wiki search for "datasource(s) dependency(ies)" (four separate searches) and read each of the articles.

The closest thing I found was http://wiki.jboss.org/wiki/Wiki.jsp?page=DependOnDataSource, and http://wiki.jboss.org/wiki/Wiki.jsp?page=HowCanAnMBeanDependOnADatasource but both have the dependency in the wrong direction.

So I will ask the question in another way. Programmatically, we can obtain all of the data found in a datasource description in a -ds.xml file, except for the clause. How can we, programmatically, obtain the mbeans on which a datasource depends?

[peterj]

Sorry, should have previewed my submission before submitting.

The end of the second sentence on the past paragraph should read "except for the 'depends' clause"

[chilin]

I found a topic in the user forum which was pretty close, but not quite what we want (because it requires some added code in the mbean itself):
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=49420

Other than this, I also found out the listDeployed() operation of "jboss.system:service=ServiceController" lists the dependency information of all the mbeans, and the "depends" clause specified in the -ds.xml file appears under the following mbean: "jboss.jca:name=<datasource name>,service=ManagedConnectionFactory".

If there's no better solution, we can invoke the listDeployed() oeration from the console and walk through the returned list to get the dependency information. However there're multiple mbeans the ManagedConnectionFactory depends on, how do I determine which one (or could it be ones?) was specified in the "depends" clause?