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

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.

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.

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);
 }
}

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@jboss.org" wrote:

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

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

I guess you missed my post?

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)

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

"adrian@jboss.org" wrote:
It should not be replacing properties during the parsing.

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

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