Have you tried with 5.0? I believe that the same set of MBeans are still being created for a data source. The only difference is how they get created, but the end result is still the same.
Of course, the best was to programmatically create a data source is to create the *-ds.xml file and then move it into the deploy directory and let the hot deployer take care of it. This way, as long as the *-ds.xml file layout does not change, you do not have to be concerned with such details.
In Jboss5 the -ds.xml file does not get converted to xml service through xslt subdeployer but the new jca deployers create the same set of MBeans and start the service through new jca deployers.
Thank you guys. I will give it a try now.
But I don't think to create *-ds.xml file is a good idea for security reasons.
Is there a solution that i can remove the *-ds.xml file after data-source deployed?
You can encrypt password in -ds.xml or set permission that only jboss process can read this file.
Consider that creating DS in Java has the same security problems how -ds.xml because anybody can decompile class files from deployed application (unless you use obfuscator or something similar)
decompile will not be a problem for our system because we are using one-time key for encryption and the key will be loaded from somewhere else and existing no where besides jboss's memeory. no clear key in code,only a batch of APIs.
like this some side effects do exist. I am still trying to do some make up.
anyway, I still think it makes more sense for JBoss to have a API to create datasource programmatically.
In tests I create datasource in Spring, I'm sure in JBoss there are functions to create DS (it really pity if there are inner). If not you can create suitable class DS from underlying implementaion which JBoss use and bind it to JNDI new NamingContext().bind("java:dsXXX", ds);
It'n not tested it and I'm courious if it is correct. Now I have plan to decompose JBoss mechanisms to boost developing (eg programatically create war/ear/selected bean ejb3 wich seleceted requirements without scannging all classpath - scanning classpath was inflexible with few environment and one code tree in our project - eg replace one implementation from classpath without deleting it.