Oleg Nitz wrote :
> During the weekend I have done the same task.
> Nice race, isn't it?
Indeed... I've learned quite a o lot between JMX Mlet, transaction API
and Castor and jboss implementation...
> 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.
Well to be honest I don't use EJX, because i didn't find it to be trivial
enough. Sorry to say that, but I got frustrated :-)
> 2) UserTransaction is not bound to a bean context.
Right,
> 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.
Well werever you want...
> 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?
Sorry I wasn't clear enough on that point. This is what I wanted to say :
put the database.xml and its mapping files into conf directory. Sound
perfect to me.
> 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.
Yeah but why does it take so long ?
> 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.
Sound fine to me.
> 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.
I tried it, seems not ot be a problem for reding database.xml and mapping
file, but the XML part of castor won;t be working out of the box.
Again i can submit the diff for jboss to make use of JAXP, since it's the
way to go IMHO.
> 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.
So they are for me too. No problem on this point.
> 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.
Well suppose you overrride a JNDI name by inadvertence. It acts like a
namespace, just like XADataSourceBean bind XADataSource : 'XA.$NAME'
> 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.
Well perfect !
Sebastien
> Best regards,
> Oleg
