&quot;weston.price(a)jboss.com&quot; wrote : | 1) The element name mappings have to be hardcoded somewhere. Example: | | <min-pool-size/> | <max-pool-size/> | <connection-url/> | <xa-datasource-property/> | | All of this stuff has to resolve to something in the MetaData, and then applied correctly to ServiceMetaData instances to construct and deploy the MBeans for a MCF. Why don't you just write a holder that knows how to create a more structured metadata object from the flat scheme. e.g. in JAXB annotations (I'll use fields instead of accessors for brevity) | | public BaseConnectionFactoryDefinition implements PoolMetaData, etc... | { | @XmlElement("min-pool-size") public int minPoolSize; | @XmlElement("max-pool-size") public int maxPoolSize; | | public PoolMetaData getPoolMetaData() | { | return this; | } | } | | @XmlRoot("local-tx-datasource") | public LocalTxDataSource extendsBaseConnectionFactoryDefinition implements MCFMetaData | { | @XmlElement("connection-url") public String connectionURL; | | public LocalDataSourceMetaData getConnectionFactoryMetaData() | { | return this; | } | | public List<ConnectionPropertyMetaData> getConnectionProperties() | { | // create connection property metadata | } | } | The idea being that PoolMetaData and MCFMetaData (or whatever you call them) are what the real ds deployer uses when constructing the MBeans/POJOs. It is then simply a case of parsing (using JAXB - or JBossXB with JAXB annotations) and extracting the metadata into deployment attachments. The other big advantage is that somebody can write their own deployer that creates this metadata some other way and still reuse the JCA real deployer. NOTE: This is OOP (inheritance) not AOP. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4023695#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...