Overview

General

Configuration

Servers

Integrations

Community

Feeds


Site
News
   



Manual del Usario [ edit ]

Configuration

Short Overview

Configuration Properties

  • openejb.home - OpenEJB home (installation) directory path. All relative paths are resolved against the property unless openejb.base is set. Unless set, the value is assigned to the user.dir Java property.
  • openejb.base - OpenEJB base directory path. If set, the directory pointed by the property is searched for resources before openejb.home.
  • openejb.configuration - OpenEJB configuration file path.
  • openejb.loader - OpenEJB loader that's responsible for loading EJBs. There are 3 different loader types:
    • tomcat-webapp - set it when inside of Tomcat scoped at just the webapp, aka. Collapsed EAR
    • tomcat - set it when inside of Tomcat scoped for all webapps to share
    • system (also: bootstrap)
    • embedded (also: noload)
  • openejb.configurator (default: org.openejb.alt.config.ConfigurationFactory ) - a class that builds org.openejb.alt.assembler.classic.OpenEjbConfiguration object; implements the org.openejb.alt.assembler.classic.OpenEjbConfigurationFactory interface

Configuration File

Show a config file with the elements hyperlinked.

openejb.conf
<?xml version="1.0"?>
<openejb>
  <Container id="Default CMP Container" ctype="CMP_ENTITY">
    Global_TX_Database  c:/my/app/conf/postgresql.cmp_global_database.xml
    Local_TX_Database   c:/my/app/conf/postgresql.cmp_local_database.xml
  </Container>
  <Connector id="Default JDBC Database">
    JdbcDriver org.postgresql.Driver
    JdbcUrl jdbc:postgresql://localhost/mydb
    UserName username
    Password password
  </Connector>
  <SecurityService id="Default Security Service"/>
  <TransactionService id="Default Transaction Manager"/>
  <Deployments jar="c:/my/app/employee.jar"/>
  <Deployments dir="beans/" />
</openejb>

Basic Layout

Basically, openejb.base is the source for 100% of all configuration information and third party config files (log4j, castor, instantdb, whatever). This includes finding where the, possibly many, <Deployment> entries in the openejb.conf point. The openejb.home is where the code loading OpenEJB will look for all the OpenEJB libraries. Usually openejb.base is not explicitly set and defaults to the value of openejb.home, so many people are used to only dealing with openejb.home.

The point of having and openejb.base and openejb.home was basically to allow several independently configured instances of OpenEJB running on a system (perhaps embedded in Swing apps, in Tomcat, running as a standalone Server, or even in Groovy as Mr. Strachan did!) but without the need to copy all the OpenEJB system libraries everywhere.

openejb.home

  • can be set explicitly via a system property.
  • if not set it default's to user.dir, which is the current working directory.

openejb.base

  • can be set explicitly via a system property.
  • If not set it default's to openejb.home.

openejb.configuration

  • can be set to explicitly point to the file containing your configuration.
  • If set to a relative path, we first look in user.dir/your-conf-file, then in openejb.base/your-conf-file
  • If not set we check in openejb.base/conf/openejb.conf
  • If no conf file is found, we create one in openejb.base/conf/openejb.conf

relative paths in openejb.conf

  • Deployment entries are resolved relative to openejb.base.
  • Containers use openejb.base to resolve their own config files. For example, Castor JDO to loads the database.xml and all other files from the openejb.base directory.
  • Resource adapters that are embedded usually have config files of their own and are also loaded from the openeb.base.

log files

  • The log4.configuration file is resolved relative to openejb.base.
  • The properties in the config file that point to files are also resolved relative to openejb.base.

OpenEJB libraries

  • The jars in the lib and dist directories under openejb.home are added to the classpath.

Summary

A summary of the above in a different notation:

openejb.home = user.dir (can be set explicitly)
openejb.base = openejb.home (can be set explicitly)
openejb.conf = openejb.base/conf/openejb.conf (can be set explicitly)
logging.conf = openejb.base/conf/logging.conf (can be set explicitly)
deployments  = paths listed in openejb.conf (relative paths resolved from openejb.base)
Classpath includes openejb.home/lib and openejb.home/dist

Example layout

In this one the openejb.home and openejb.base are set, everything else is defaulted. The openejb.conf file as been updated to point to the ejb jars by name (abc-ejbs.jar and xyz-ejbs.jar).

An example layout:

/usr/local/openejb  (openejb.home)
/usr/local/openejb/lib  (in classpath)
/usr/local/openejb/dist (in classpath)
/home/jsmith/foo_app  (openejb.base)
/home/jsmith/foo_app/conf/openejb.conf
/home/jsmith/foo_app/conf/logging.conf
/home/jsmith/foo_app/abc-ejbs.jar (Deployment entry in openejb.conf)
/home/jsmith/foo_app/xyz-ejbs.jar (Deployment entry in openejb.conf)
/home/jsmith/foo_app/logs/  

Another Example layout

In this example openejb.home and openejb.base are setup as well as the explicit paths for the openejb and log4j configuration files.

An example layout:

/usr/local/openejb  (openejb.home)
/usr/local/openejb/lib  (in classpath)
/usr/local/openejb/dist (in classpath)
/home/jsmith/foo_app  (openejb.base)
/home/jsmith/foo_app/openejb.xml  (openejb.configuration)
/home/jsmith/foo_app/abc-ejbs.jar (Deployment entry in openejb.xml)
/home/jsmith/foo_app/xyz-ejbs.jar (Deployment entry in openejb.xml)
/home/jsmith/foo_app/log4j.conf  (log4j.configuration)
/home/jsmith/foo_app/mylogs/  (logging dir as defined in log4j.conf)

Deployments

The 'Deployments' element in openejb.conf

A single jar

To include a single jar by name, just declare a 'Deployments' element with a 'jar' attribute pointing to the jar file on the file system.

openejb.conf
<openejb>
...
<Deployments jar="c:\my\app\superEjbs.jar" />
<Deployments jar="c:\someplace\purchasing.jar" />
<Deployments jar="timeTrack.jar" />
</openejb>

The last element in the example uses a relative path to point to the ejb jar. This path will be resolved relative to the openejb.base property. So, for example, of the value of openejb.base was 'c:\timeapp\' then OpenEJB would look for the jar 'c:\timeapp\timeTrack.jar'. See the Configuration guide for more details.

A directory of jars

To point to a directory that contains several jar files that OpenEJB should load, simply declare a 'Deployments' element with a 'dir' attribute pointing to the directory containing the jar files.

openejb.conf
<openejb>
...

<Deployments dir="c:\my\app\beans\" />
<Deployments dir="c:\crimestopper\lib" />
<Deployments dir="ejbs" />
<Deployments dir="beans" />
</openejb>

The directories listed will be searched for jars containing 'META-INF/ejb-jar.xml' files and will be added to the list of jars to load if they do. Better said, it's completely save to point to a directory containing a mix of ejbs and regular jar files. OpenEJB will simply skip over jars that do contain the required 'META-INF/ejb-jar.xml' file.

The last Deployments element declares a 'beans' directory relative to openejb.base for holding ejb jars. This declaration is simply convention and not required.

An unpacked jar

As of 1.0 beta1, OpenEJB supports unpacked ejb jars. Simply meaning that you don't need to pack your ejb's into a jar file in order to use them in OpenEJB. You still need to follow the ejb jar layout and include an "META-INF/ejb-jar.xml" in the directory that contains your ejbs.

For example, if you have a directory structure like this:

C:\myapp\
C:\myapp\acmeEjbs\
C:\myapp\acmeEjbs\META-INF\ejb-jar.xml
C:\myapp\acmeEjbs\org\acme\Foo.class
C:\myapp\acmeEjbs\org\acme\FooBean.class
C:\myapp\acmeEjbs\org\acme\FooHome.class
C:\myapp\acmeEjbs\org\acme\Bar.class
C:\myapp\acmeEjbs\org\acme\BarBean.class
C:\myapp\acmeEjbs\org\acme\BarHome.class

Then you would delcare a 'Deployments' element with the 'dir' attribute set to 'C:\myapp\acmeEjbs' as shown below.

openejb.conf
<openejb>
...

<Deployments dir="c:\myapp\acmeEjbs" />
</openejb>

Note that this syntax is the same as the directory syntax above. If OpenEJB finds a META-INF directory with an 'ejb-jar.xml' fine inside, then OpenEJB will treat the directory as an unpacked ejb jar. Otherwise OpenEJB will look for ejb jar files to load as detailed in the above section.

Log file

When trying to figure out if your ejbs were loaded, the openejb.log file is an incredible asset.

If your ejbs were loaded successfully you should see entries like the following (1.x and higher only):

openejb.log

INFO : Loaded EJBs from /usr/local/openejb-1.0-beta1/beans/openejb-itests-beans.jar
INFO : Loaded EJBs from /usr/local/openejb-1.0-beta1/beans/openejb-webadmin-clienttools.jar

If your ejbs failed to load, you will see an entry similar to the following.

openejb.log

WARN : Jar not loaded. /usr/local/openejb-1.0-beta1/beans/helloworld.jar. Jar failed validation. Use the validation tool for more details

Additionally, all the successfully loaded ejbs are individually listed in the log file at startup. The Deployment ID listed is the JNDI name used to lookup the ejb from a client of the Local or Remote Servers. The beans listed below are from our test suite.

DEBUG:  Deployments       : 19
DEBUG:  Type        Deployment ID
DEBUG:     CMP_ENTITY  client/tests/entity/cmp/RMI-over-IIOP/EJBHome
DEBUG:     STATEFUL    client/tests/stateful/EncBean
DEBUG:     STATELESS   client/tests/stateless/BeanManagedBasicStatelessHome
DEBUG:     STATEFUL    client/tests/stateful/BasicStatefulHome
DEBUG:     STATELESS   client/tests/stateless/EncBean
DEBUG:     STATEFUL    client/tests/stateful/BeanManagedTransactionTests/EJBHome
DEBUG:     BMP_ENTITY  client/tests/entity/bmp/RMI-over-IIOP/EJBHome
DEBUG:     STATEFUL    client/tests/stateful/RMI-over-IIOP/EJBHome
DEBUG:     STATELESS   client/tests/stateless/BeanManagedTransactionTests/EJBHome
DEBUG:     BMP_ENTITY  client/tests/entity/bmp/allowed_operations/EntityHome
DEBUG:     CMP_ENTITY  client/tests/entity/cmp/EncBean
DEBUG:     STATEFUL    client/tests/stateful/BeanManagedBasicStatefulHome
DEBUG:     BMP_ENTITY  client/tests/entity/bmp/BasicBmpHome
DEBUG:     STATELESS   client/tests/stateless/BasicStatelessHome
DEBUG:     CMP_ENTITY  client/tests/entity/cmp/BasicCmpHome
DEBUG:     STATELESS   client/tools/DatabaseHome
DEBUG:     CMP_ENTITY  client/tests/entity/cmp/allowed_operations/EntityHome
DEBUG:     BMP_ENTITY  client/tests/entity/bmp/EncBean
DEBUG:     STATELESS   client/tests/stateless/RMI-over-IIOP/EJBHome

Containers

Declaring your Container

CMP Entity containers are defined with the <Container> element, under the <openejb> element. This is actually the declaration used for all containers defined in the container system. The part that actually makes it a cmp container is the ctype attribute, specifially, a ctype attribute set to CMP_ENTITY as such...

example_01.conf
<?xml version="1.0"?>
<openejb>

<Container id="Default CMP Container" ctype="CMP_ENTITY"/>

</openejb>

The really fun part is that the above configuration file is completely legal! If you started the server and pointed to this file...

./openejb.sh start -conf example_01.conf

...you would end up with a running server that contained only one container, called "Default CMP Container". You could then deploy beans into it and everything. There would be no other containers running in the server at all. If you telnet'd into the server and typed the 'system' command, you could see for yourself that there is nothing else in the system.

dblevins@Miles /dev/OpenEJB
$ telnet localhost 4200
Trying 127.0.0.1...
Connected to Miles
Escape character is '^]'.
OpenEJB Remote Server Console
type 'help' for a list of commands
openejb$ system
Containers:
Default CMP Container

Deployments:
openejb$

You see that. No beans, no JDBC resources, nothing but one CMP container called "Default CMP Container".

Naming your Container

You can call the container anything you want, just change the value of the id attribute. Here is a container called "My PostgreSQL Contianer"

example_02.conf
<?xml version="1.0"?>
<openejb>

<Container id="My PostgreSQL Container" ctype="CMP_ENTITY"/>

</openejb>

If you were to deploy a CMP bean into this configuration, you would see "My PostgreSQL Container" in the list of usable containers, in fact, it would be the only container in the list.

dblevins@Miles /dev/OpenEJB/openejb
$ ./openejb.sh deploy -conf example_02.conf myCMPBean.jar
...(skipping to step two)...

==--- Step 2 ---==

Please specify which container the bean will run in.
Available containers are:

Num Type ID

1 CMP_ENTITY My PostgreSQL Container

Type the number of the container
-options to view the list again
or -help for more information.

Container:

After deployment, you would end up with a configuration like this one

example_02.conf
<?xml version="1.0"?>
<openejb>

<Container id="My PostgreSQL Container" ctype="CMP_ENTITY"/>

<Deployments jar="myCMPBean.jar" />

</openejb>

Most important, that bean will now be mapped directly to the container id "My PostgreSQL Container". So if you change the name of the container and do not redeploy the myCMPBean.jar to point to the new container id, you will have big problems!

Container types

You can declare as many containers as you want. The available container types are:

  • CMP_ENTITY
  • BMP_ENTITY
  • STATELESS
  • STATEFUL

The containers can all be of the same type, or a mix of the types.

example_03.conf
<?xml version="1.0"?>
<openejb>

<Container id="My PostgreSQL Container" ctype="CMP_ENTITY"/>
<Container id="My MySQL Container" ctype="CMP_ENTITY"/>
<Container id="My InstantDB Container" ctype="CMP_ENTITY"/>
<Container id="My Stateful Session Container" ctype="STATEFUL"/>
<Container id="My Stateless Session Container" ctype="STATELESS"/>

</openejb>

Configuring your Container

Of course, if you did have a configuration like the one above, it would be a bit pointless as all three of your CMP containers would be using the default CMP container configuration. To acually configure a container differently, you simply need to specifiy new values for the properties that the container has. These will override the defaults for that particular container declaration. So it's possible to declare multiple containers of the same type, but configure each one differently. Let's use our CMP_ENTITY containers above as an example.

example_03.conf
<?xml version="1.0"?>
<openejb>

<Container id="My PostgreSQL Container" ctype="CMP_ENTITY">
    Global_TX_Database    conf/postgresql.cmp.global-database.xml
    Local_TX_Database     conf/postgresql.cmp.local-database.xml
</Container>

<Container id="My MySQL Container" ctype="CMP_ENTITY">
    Global_TX_Database  conf/mysql.cmp.global-database.xml
    Local_TX_Database   conf/mysql.cmp.local-database.xml
</Container>

<Container id="My InstantDB Container" ctype="CMP_ENTITY">
    Global_TX_Database  conf/instantdb.cmp.global-database.xml
    Local_TX_Database   conf/instantdb.cmp.local-database.xml
</Container>

<Container id="My Stateful Session Container" ctype="STATEFUL"/>
<Container id="My Stateless Session Container" ctype="STATELESS"/>

</openejb>

The format of the configuration parameters is actually just regular old java.util.Properties file format. It keeps things simple and doesn't require you to type endless amounts of tags that are just name/value pairs anyway. The java.util.Properties file format allows for spaces, tabs, colons, or equals signs to separate the name value pairs, so this would also be acceptable..

example_03.conf
<?xml version="1.0"?>
<openejb>

<Container id="My PostgreSQL Container" ctype="CMP_ENTITY">
! This is a comment   
    Global_TX_Database = conf/postgresql.cmp.global-database.xml
    Local_TX_Database=conf/postgresql.cmp.local-database.xml
</Container>

<Container id="My MySQL Container" ctype="CMP_ENTITY">
# This is also a comment
    Global_TX_Database:conf/mysql.cmp.global-database.xml
    Local_TX_Database : conf/mysql.cmp.local-database.xml
</Container>


<Container id="My InstantDB Container" ctype="CMP_ENTITY">
    Global_TX_Database  conf/instantdb.cmp.global-database.xml
    Local_TX_Database           conf/instantdb.cmp.local-database.xml
</Container>

</openejb>

Configuration properties

The actual properties that each container type accepts are different for each type. Here is a reference for each container type.

CMP_ENTITY properties

PoolSize

The default size of the method ready bean pools. Every bean class gets its own pool of this size. The value should be any integer.

Default:

PoolSize 100

Global_TX_Database

The name of the database.xml file that is used for global or container managed transactions. This will be used when the TransactionManager is managing the transaction, such as when the tx attribute is Supports(and there is a client tx), RequiresNew, Required or Manditory.

Specifies the configuration for obtaining database connections and the mapping.xml schema which describes how beans map to the database.

Default:

Global_TX_Database conf/default.cmp_global_tx_database.xml

Local_TX_Database

The name of the database.xml file that is used for local or unspecified transaction contexts. This will be used when the TransactionManager is not managing the transaction, such as when the tx attribute is Supports (and there is no client tx), NotSupported, or Never.

Specifies the configuration for obtaining database connections and the mapping.xml schema which describes how beans map to the database.

Default:

Local_TX_Database conf/default.cmp_local_tx_database.xml

BMP_ENTITY properties

The BMP Container has no customizable properties to override.

STATEFUL properties

Passivator

The passivator is responsible for writing beans to disk at passivation time. Different passivators can be used by setting this property to the fully qualified class name of the PassivationStrategy implementation. The passivator is not responsible for invoking any callbacks or other processing, its only responsibly is to write the bean state to disk.

Known implementations:
org.openejb.core.stateful.RAFPassivater
org.openejb.core.stateful.SimplePassivater
Default:

Passivator org.openejb.core.stateful.SimplePassivater

TimeOut

Specifies the time to wait between invocations. This value is measured in minutes. A value of 5 would result in a time-out of 5 minutes between invocations.

Default:

TimeOut 20

PoolSize

Specifies the size of the bean pools for this stateful SessionBean container.

Default:

PoolSize 100

BulkPassivate

Property name that specifies the number of instances to passivate at one time when doing bulk passivation. Must be less than the PoolSize.

Default:

BulkPassivate 50

STATELESS properties

StrictPooling

Specifies the whether or not to this stateless SessionBean container should use a strict pooling algorithm. true or false

Default:

StrictPooling true

         
     
     
     
 


Apache OpenEJB is an project of The Apache Software Foundation (ASF)
 
Powered by Atlassian Confluence.