On the the XML config file end, only a handful of the config elements are required. For example, if I have a ds.xml file containing only: <connection-factories> | <tx-connection-factory> | <jndi-name>MyTx</jndi-name> | <rar-name>jms-ra.rar</rar-name> | <connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connection-definition> | </tx-connection-factory> | </connection-factories> Somehow or another, the other properties will end up with default values on the underlying connection factory. This must be happening in one of two ways: 1) For any missing elements in the XML file, the deployer knows what defaults to use and passes those defaults to the underlying connection factory. 2) For any missing elements in the XML file, the deployer passes null to the underlying connection factory or does not call the corresponding setters at all, and the connection factory knows to use its own internal defaults. Based on your comment that the profile service would have to store defaults for primitives, I'm guessing that 1) is what was done on the deployer end, because if 2) is what was done, the profile service could do the exact same thing and just rely on the underlying connection factory to provide defaults. So assuming for now that 1) is what was done on the deployer end, I suggest the following: 1) Add some sort of defaultValue attribute on the ManagedProperty annotation, e.g.: @ManagementProperty(name="idle-timeout-minutes", includeInTemplate=true, defaultValue="30") public void setIdleTimeoutMinutes(int idleTimeout) { this.idleTimeout = idleTimeout; } This attribute would be optional and would only be allowed for properties that map to SimpleValues or EnumValues. For primitive properties, when a defaultValue is specified, the Profile Service would set mandatory to false on that property, otherwise it would set mandatory to true. For non-primitive properties, unless the annotation explicitly contained mandatory=true, the properties would default to mandatory=false. If the profile service can't provide something like the above, we'll have to make all of these primitive properties required in jboss-as-plugin's metadata (today they're optional), and when a user creates a new Connection Factory via JON or the Admin Console, they will have to specify values for 20 or so properties, rather than the 3 that really need to be required (jndi-name, rar-name, and connection-definition). Of course, RHQ provides a mechanism for specifying templates for new Resources, so we can include defaults for all 17 of these properties in our plugin descriptor. This basically places the responsibility of maintaining the defaults on RHQ, rather than the profile service. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220894#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...