Hi!
During the weekend I have done the same task.
Nice race, isn't it?
But who are the judges? :-)
Well, my solution is almost the same, but I think it's somewhat more
consistent. But certainly your variant of Container.java change is
better, I'll borrow it.
I also need some help, comments and advices. Let me start from my
problems :-)
1) I have changed configuration files for EJX so that CastorJDO
resource manager is supported for jboss.xml, but not for ejb-jar.xml.
Richard, could you help here? Could you provide some configuration
file for the list of possible resource-ref Java classes?
FYI, Rickard, I've noticed that EJX doesn't show jboss.xml files in
the "Open file" dialog, even when the file type is set to "jBoss XML".
Though, if I rename jboss.xml to ejb-jar.xml, edit and save, it is
saved as jboss.xml.
2) UserTransaction is not bound to a bean context.
Sebastien Sahuc wrote:
SS> Attached is the Mbean for integrating Castor inside jboss. Unfortunately,
SS> there is quite a lot of things I'm not happy about :
SS> + At compile time you need the castor library in the classpath. Should we
SS> use the reflection to avoid this ?
I don't think so. Better let's put the MBean to other place.
I guess, the module contrib would be the right one.
SS> + The 'database' document must be in the classpath. (database file is the
SS> config file that contains the DB connection info (use of the JDBC
SS> resource manager through JNDI ENC) + link to mapping file(s). It's the
SS> first parameter of the Mlet.
In my view the 'database.xml' (as well as 'mapping.xml') should belong
to server configuration rather than to bean's. It is first parameter
of the Mlet (in my variant, too :-), which is described in jboss.conf,
and it shouldn't point at some thing that is out there (;-), in
the jar file that may be deployed or may not.
Are you going to write one MLet per jar file?
SS> + Lazing loading of the mapping file. Cannot be done at init or starting
SS> time of the Mbean because it needs a JDBC connection, and the jdbc ENC is
SS> not available at this time.
It's okay, lazy loading is the main pattern of Java :-)
SS> + The loading is quite long. I believe there is classloader issues, but
SS> I'm not sure so far. Need investigation...
Only once, when the first method in the given container is executed.
I guess, it's inevitable.
SS> + The class is under package jdbc, should be moved.
SS> The class name is not good also, so any suggestion on these points
SS> would be appreciate.
In my variant, the package is org.jboss.jdo.castor, the class names
are CastorJDOImpl, CastorJDOImplMBean. I'm also not sure that my
variant of the name is good.
SS> + There is an small conflict on the XML parser used. Indeed Castor uses
SS> Xerces by default, while jboss uses Sun's parser. At this point I suggest
SS> that you -jboss- upgrade to the JAXP library, so that you don't depend on
SS> any parser. I can submit the diff for that purpose if you want... On the
SS> other hand, castor permits the use of other SAX parser by placing a
SS> castor.properties in the classpath (another conf file in the conf
SS> directory...) and changing one of it values.
I hope Castor is able to use Sun's parser. Haven't tried though.
SS> HOW TO USE IT :
I'll provide the diff of usage instructions.
SS> * Put the castor jar in lib/ext directory (available from
SS> http://castor.exolab.org)
SS> * Add the Mlet in jboss.conf
SS> <MLET CODE = "org.jboss.jdbc.CastorDataSourceLoader"
SS> ARCHIVE="jboss.jar,castor-0.8.8.jar" CODEBASE="../lib/ext/">
SS> <ARG TYPE="java.lang.String" VALUE="database.xml">
SS> <ARG TYPE="java.lang.String" VALUE="test">
SS> </MLET>
SS> where database.xml is the database document needed by the Castor JDO. See
SS> castor documentation for further info on the content of this file)
SS> and the second parameter is the name given to the database (atribute of
SS> database.xml). It will serve to set the JNDI name. See below.
No differences, but in my variant database.xml and mapping.xml should
be in the conf directory rather that in bean jar file.
SS> * Declare the resource managers in your jboss.xml besides your
SS> ejb-jar.xml :
SS> <jboss>
SS> <resource-manager>
SS> <res-name>jdo/myjdo</res-name>
SS> <res-jndi-name>jdo.test</res-jndi-name>
SS> </resource-manager>
SS> [...]
SS> </jboss>
- <res-jndi-name>jdo.test</res-jndi-name>
+ <res-jndi-name>test</res-jndi-name>
SS> Notice that the jndi name is composed of the second parameter of the Mlet
SS> (jdo.$DBNAME)
Why do you add "jdo."? Let user decide how to distinguish different
types of resources. The JNDI name shouldn't be bounded to
the logical database name for Castor.
I propose to make the latter an Mlet parameter.
SS> * Declare the resource manager JNDI ENC for the beans in ejb-jar.xml :
SS> <session>
SS> [...]
SS> <resource-ref>
SS> <description>JDO</description>
SS> <res-ref-name>jdo/myjdo</res-ref-name>
SS> <res-type>org.exolab.castor.jdo.JDO</res-type>
SS> <res-auth>Container</res-auth>
SS> </resource-ref>
SS> </session>
SS> * Get the JDO object in your Session bean as :
SS> a_method () {
SS> InitialContext ic = new InitialContext();
SS> JDO jdo = (JDO) ic.lookup("java:comp/env/jdo/myjdo");
SS> Database db = jdo.getDatabase();
SS> db.create (obj1);
SS> [...]
SS> db.remove(obj2)
SS> [...]
SS> whatever action on db
SS> }
All the same.
Best regards,
Oleg
