On Fri, May 21, 2004 at 06:20:58PM +0200, Vincent Massol wrote: > Hi Jacek, > > Jacek Laskowski wrote: > > > > Vincent Massol wrote: > > > Hi, > > > > > > I'd like to use openEJB in embedded mode. I'd also like to be able > to > > > configure it using a java API (instead of the openejb.xml file). Is > it > > > possible? > > > > Yes, it's possible. What parameters would you like to set up?
As Jacek mentions, it definitely is possible. We have a couple levels of pluggable API for configuration, but I'm guessing you really don't want to implement any of them and would be quite happy with a properties version of the openejb.xml file. I've been toying around with that idea lately; specifically for use in tools which are inherently properties based anyway. But just for educational purposes, here are the existing pluggable layers in reverse order: The Configuration Factory (http://www.openejb.org/design_configfactory.html) - A sub-API of the Classic Assembler. - Does whatever it wants to to create an OpenEjbConfiguration object tree. - Geared more towards GUI tools or implementing completely different ways to do what openejb.conf and openejb-jar.xml do. - It's a fair amount of work as the tree must be valid. The Assembler (http://www.openejb.org/design_assembler.html) - Builds the actual container instances, the jndi namespace, etc. that are used at run-time. - Geared more towards App Servers looking for an extreme amount of control. - A truck-load of work as building a valid container system isn't trivial. Anyway, you really don't want to build your own OpenEjbConfiguration tree, you just want to hint some info to the Configuration Factory that is building the tree and let it assume defaults for everything else. I'm thinking maybe openejb.conf would be the base property name for anything that would normally be found in the openejb.conf file. DEPLOYMENTS =========================== > - adding/deploying an ejb jar (equivalent of <Deployments > jar="myCMPBean.jar"/>) How would you feel about two system properties for this, something like: openejb.conf.deployment.dirs=<classpath-style dir list> openejb.conf.deployment.jars=<classpath-style jar list> CONFIGURING A CONTAINER =========================== > - defining a container (equivalent of <Container id="Default CMP > Container" ctype="CMP_ENTITY"/>). Is it required to explicitely define a > default container or is there one automatically created for you? This is where we should be assuming defaults and creating one for you. We don't do that currently though. This is possible except in the case of CMP entities where there must be a castor database.xml file that points to castor mapping.xml files. So for the times when you really need to configure a container, I see a couple options. OP 1 ------ openejb.conf.container.<alias> = <ctype>, <id>(optional) <alias>.foo = bar <alias>.this = that Where <id> and <ctype> have the same meaning they do in the Container xml tag, additionally <alias> is just used as a prefix for the container's normal properties. If <id> is not specified, than <alias> is used internally as the <id>. Possible example: openejb.conf.container.castor_cmp = CMP_ENTITY, Default CMP Container castor_cmp.local_tx_database = conf/mysql.cmp_global_tx_database.xml castor_cmp.global_tx_database = conf/mysql.cmp_local_tx_database.xml OP 2 ------ openejb.conf.container.<ctype> = <alias>, <id>(optional) <alias>.foo = bar <alias>.this = that Tags have same meaning as above. Possible example: openejb.conf.container.cmp_entity = castor_cmp, Default CMP Container castor_cmp.local_tx_database = conf/mysql.cmp_global_tx_database.xml castor_cmp.global_tx_database = conf/mysql.cmp_local_tx_database.xml ------ OP 2 was actually the first approach I thought of, but has the limitation that there could be only one container of any given type. In my mind, declaring the container is just like instantiating it, so OP 1 is much closer to that thought. This is what I mean: openejb.conf.container.castor_cmp = CMP_ENTITY, Default CMP Container is logically identical to... Container castor_cmp = new Container(CMP_ENTITY, "Default CMP Container"); castor_cmp.set("local_tx_database", "conf/mysql.cmp_global_tx_database.xml"); castor_cmp.set("global_tx_database", "conf/mysql.cmp_global_tx_database.xml"); Anyway, OP 1 is my preference. The door is open for other ideas. CONFIGURING ANY SERVICE ============================ The same approach for conatiners could be used for Connectors and other services too. So, really, the algorithm is this: openejb.conf.<type>.<alias> = //attributes// <alias>.foo = bar <alias>.this = that Where <type> can be any of Container, Connector, ConnectionManager, ProxyFactory, SecurityService, or TransactionService Possible Example: openejb.conf.connector.axion = Default JDBC Database axion.JdbcDriver = org.axiondb.jdbc.AxionDriver axion.JdbcUrl = jdbc:axiondb:DefaultDatabase:target/test-database LOADING PROPERTIES CONFIGURATION ================================== As far as a mechanism to get the properties to OpenEJB, this might be a good algorithm. 1. openejb.configuration=path/to/some/openejb.properties 2. The system properties via setting openejb.configuration=system.properties Perhaps just the presence of any openejb.conf.foo properties could signal OpenEJB to not look for an xml configuration file. - Number 1 could be the path to any file ending in .properties. - In the event number 1 and number 2 are used together, the system properties would override the values of openejb.properties allowing for something dynamic like: java -Dopenejb.configuration=foo.properties -Dopenejb.conf.deployment.jars=path/to/some.jar ================================ Any thoughts on any of this? I'm actually leaving for Ecuador Wednesday, so wouldn't have time to work on something like this for a couple weeks. Anyone is welcome to step up to the plate and give it a shot. Just be warned that this is a fairly involved task, so the potential for drowning in it is certainly there. Just to clarify the work, there are really two things in action here: - Creating defaults when containers aren't declared and needed by an ejb jar being loaded in the system. - Allowing properties to be used to declare things instead of using xml with an openejb.xml (aka openejb.conf) file. The advantage here is that when combined with the first item, someone could potentially get an effective configuration with merely: java -Dopenejb.conf.deployments.jars=$CLASSPATH BTW, thanks for providing us with a good use case, Vincent. Asking for usability features is always a good thing. -David > Just to let you know, I'm trying to create an OpenEjbTestSetup for > Cactus (in the same spirit as the JettyTestSetup: > http://tinyurl.com/2gfao). > I don't think I need more than the parameters list above as for more > complex configuration, I'll let the user specify his own open ejb > configuration file. > > Can this be done using the default Assembler or do I have to create my > own Assembler? > > > > > Sorry for such a short message, but don't have an example to show you > > this running. > > Thanks for your fast answer! I'm completely new to OpenEJB so I may be > asking stupid questions... ;-) > > Thanks > -Vincent >
