Hi David, First let me thank you for your very kind and thorough email.
See below > -----Original Message----- > From: David Blevins [mailto:[EMAIL PROTECTED] > Sent: 23 May 2004 00:24 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [openejb-user] Java API to configure openEJB? > > 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. I was more thinking about a Java API rather than properties. My need is to embed openEjb in java code so it's easier to call a Java API than to use some properties. For example: public void addEjbJar(File ejbjar); public void createContainer(...); etc > > 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. yep > > 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> > Sure, but I think it would be even better to have: public void addEjbJar(File ejbjar); > > 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. > Why not simply: public void createContainer(Container container); where Container is a simple java bean with container properties. > > 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? See above. > > I'm actually leaving for Ecuador Wednesday, so wouldn't have time to > work on something like this for a couple weeks. Cool. Have a nice trip there. > 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. Thanks for your very nice answer and your willingness to improve things. -Vincent > > -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 > >
