Datasources not parsing jboss.server.data.dir

[clebert.suconic]

Maybe someone already brought this up, but as I couldn't find any thread in a quick search...

On jboss-5/trunk, DefaultDS is using this URL to connect to HSQLDB:

jdbc:hsqldb:${jboss.server.data.dir}${/}hypersonic${/}localDB


I was trying to look at my tables using the HSQLDB DatabaseManager, but because of this issue, the Database still empty, and we aways have two HSQLDB instances running on the JVM.


Is that a known issue?

[clebert.suconic]

I forgot to mention...

After you start jboss on trunk, you will see a directory called ${jboss.server.data.dir} under JBOSS/bin

[starksm64]

No, I was not aware of it but do see two databases showing up. The property substitution is not working on some usage path.

[starksm@succubus bin]$ ls -lR \$\{jboss.server.data.dir\}\$\{/
${jboss.server.data.dir}${/:
total 8
drwxrwxr-x 2 starksm starksm 4096 Jul 27 09:13 }hypersonic${/

${jboss.server.data.dir}${/}hypersonic${:
total 28
-rw-rw-r-- 1 starksm starksm 849 Jul 27 08:57 }localDB.log
-rw-rw-r-- 1 starksm starksm 411 Jul 27 08:57 }localDB.properties
-rw-rw-r-- 1 starksm starksm 6116 Jul 27 08:57 }localDB.script

[starksm@succubus bin]$ ls -l ../server/default/data/hypersonic/
total 16
-rw-rw-r-- 1 starksm starksm 410 Jul 27 09:13 localDB.properties
-rw-rw-r-- 1 starksm starksm 101 Jul 27 09:13 localDB.script

[clebert.suconic]

Maybe there are issues with property substitution in other places as well:


When I start trunk/default, I see:

15:09:42,292 INFO [JMXKernel] Legacy JMX core initialized
15:09:46,604 INFO [WebService] Using RMI server codebase: http://${java.rmi.server.hostname}:8083/

[clebert.suconic]

I have create a JIRA:

http://jira.jboss.org/jira/browse/JBAS-4585


Feel free to change the description if you find a better one.

[starksm64]

The conversion from the old xslt deployer to the new deployer is not running the McfProperties through the property replacement as this comes from the jaxb parse and is set directly on the ManagedConnectionFactoryDeployment rather than passed in through as an mbean attribute where this would happen. It should be happening at the jaxb parse layer when the new metadata instance is created though since the use of mbeans is an implementation detail.

I don't know if there is a general text filter where property replacement could be hooked into jaxb before the type conversion occurs. For now I'll do the property replacement inside the setMcfProperties call.

The WebService is just a simple mbean as always so I doubt the java.rmi.server.hostname is being set.

[starksm64]

The connection url issue is fixed for now and there is no longer duplicate hsqldb database files. It needs to be fixed more generally though.

[aloubyansky]

Currently most (if not all) of the string properties use javax.xml.bind.annotation.adapters.CollapsedStringAdapter. As a quick fix I would propose to extend it, e.g.

public class ManagedConnectionStringAdapter extends CollapsedStringAdapter
{
 @Override
 public String marshal(String v)
 {
 return super.marshal(v);
 }

 @Override
 public String unmarshal(String v)
 {
 v = super.unmarshal(v);
 return v == null ? null : StringPropertyReplacer.replaceProperties(v);
 }
}

[adrian.brock]

It should not be replacing properties during the parsing.

The correct place to fix this is in AbstractBuilder
when it constructs the ServiceTextValueMetaData.

That way it works for both xml and programmatic deployment.
e.g. profile service configurations won't be parsed instead the metadata
is passed in as a preexisting attachment.

NOTE: It also needs doing for other things not just plain text, e.g.

<depends>${some.property:defaultDependency}</depends>

[adrian.brock]

The correct place to fix this is in AbstractBuilder
when it constructs the ServiceTextValueMetaData.

You could argue that the Service* objects should be doing this processing
with additional boolean properties on each to specify whether replacement should occur.

But currently, the replacement is only done in the ServiceMetaDataParser.

[aloubyansky]

I committed this. But it covers only string-based properties.

[adrian.brock]

I guess you missed my post?

[adrian.brock]

It also looks like you broke the smoke tests?

Caused by: java.lang.IllegalArgumentException: Wrong value: ${org.jboss.test.jca.xads.SomeProperty}
 at org.jboss.test.jca.xads.TestXADataSource.setSomeProperty(TestXADataSource.java:43)
 at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.getXADataSource(XAManagedConnectionFactory.java:577)
 at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:449)
 at org.jboss.resource.adapter.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:409)
 at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:611)
 at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:257)
 at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:607)
 at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:354)
 at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:381)
 at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:409)
 at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:854)
 at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
 at org.jboss.test.jca.xads.Test.test(Test.java:46)

[aloubyansky]

Yes, I missed your post, sorry. Rolled back the change.

[aloubyansky]

It should not be replacing properties during the parsing.

The correct place to fix this is in AbstractBuilder
when it constructs the ServiceTextValueMetaData.

I just tried it. It works for String-based properties. But not int, for example. Since unmarshalling/JAXB converts string values to the target Java types in metadata. And then the builder is called.
One way to workaround this could be to make all the properties in the metadata Strings. It seems like whatever type of the property is the value is converted to String anyway during the service building.

Also other uses of the unmarshalled metadata will have to be checked to make sure the system properties are substituted, e.g. when creating object names. Because now I got

13:47:00,957 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=${jndi.name}' to JNDI
 name 'java:SomeDS'