You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by db...@apache.org on 2011/07/10 06:34:03 UTC
svn commit: r1144777 [3/16] - /openejb/site/trunk/content/
Added: openejb/site/trunk/content/configuration-and-assembly.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/configuration-and-assembly.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/configuration-and-assembly.mdtext (added)
+++ openejb/site/trunk/content/configuration-and-assembly.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,198 @@
+Title: Configuration and Assembly
+{note}
+Disclaimer that we do tweak and change this code frequently, without
+notice. It is the very heart of OpenEJB. To keep things tight and clean,
+we reserve the right to change it at anytime. Do not consider it a stable
+public API.
+{note}
+
+<a name="ConfigurationandAssembly-OverviewinCode"></a>
+# Overview in Code
+
+First a glimpse of how OpenEJB looks internally. Here's a test that builds
+OpenEJB using it's internal API. This is somewhat similar to how you might
+see people constructing Jetty in code. All our internal tests look like
+this.
+
+This usage involves no xml parsing or classpath scanning. If you don't
+give it to OpenEJB, OpenEJB doesn't know about it. This is OpenEJB with
+all the magic stripped away. At a high level:
+
+1. You build your app in code using the JAXB tree in code and hand it to
+the *ConfigurationFactory*.
+1. # The *org.apache.openejb.jee* package contains JAXB trees for
+ejb-jar.xml, beans.xml and all the Java EE deployment descriptors.
+1. The *ConfigurationFactory* will produce a fully canonical version of
+the app called the *Info* tree by:
+1. # Merging all sources of meta-data -- xml and annotations
+1. # Resolving all ejb, persistence unit, datasource and other references
+1. # Validating the app and looking for mistakes
+1. The *Info* tree is
+1. # The singular source of information about the application from this
+point forward.
+1. # Pure data with no smarts or logic of any kind.
+1. # The instruction set of what would be built by the assembler.
+1. The *Assembler* will build and start the application exactly as
+described in the *Info* tree.
+1. # When this step completes, you have a running application.
+1. # Any failures prior to this point require no cleanup. Only the
+assembler builds "live" objects.
+
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>StatefulTest.java</B></DIV><DIV class="codeContent panelContent">
+ import javax.ejb.LocalBean;
+ import javax.ejb.Stateful;
+ import javax.naming.InitialContext;
+
+ import junit.framework.TestCase;
+ import org.apache.openejb.assembler.classic.Assembler;
+ import org.apache.openejb.assembler.classic.SecurityServiceInfo;
+ import org.apache.openejb.assembler.classic.TransactionServiceInfo;
+ import org.apache.openejb.client.LocalInitialContextFactory;
+ import org.apache.openejb.config.ConfigurationFactory;
+ import org.apache.openejb.jee.EjbJar;
+ import org.apache.openejb.jee.StatefulBean;
+
+ public class StatefulTest extends TestCase {
+
+ @Override
+ protected void setUp() throws Exception {
+
+ System.setProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
+LocalInitialContextFactory.class.getName());
+
+ ConfigurationFactory config = new ConfigurationFactory();
+ Assembler assembler = new Assembler();
+
+
+assembler.createTransactionManager(config.configureService(TransactionServiceInfo.class));
+
+assembler.createSecurityService(config.configureService(SecurityServiceInfo.class));
+
+ EjbJar ejbJar = new EjbJar();
+ ejbJar.addEnterpriseBean(new StatefulBean(MyBean.class));
+
+ assembler.createApplication(config.configureApplication(ejbJar));
+ }
+
+ public void test() throws Exception {
+ InitialContext context = new InitialContext();
+ MyBean myBean = (MyBean) context.lookup("MyBeanLocalBean");
+
+ assertEquals("pan", myBean.echo("nap"));
+ }
+
+ @Stateful
+ @LocalBean
+ public static class MyBean {
+
+ public String echo(String string) {
+ StringBuilder sb = new StringBuilder(string);
+ return sb.reverse().toString();
+ }
+ }
+ }
+
+
+<a name="ConfigurationandAssembly-LogicalOverview"></a>
+# Logical Overview
+
+Slightly more detailed account of the above. Our startup and deploy world
+is broken into two phases:
+
+ 1. configuration (app.jar -> AppInfo) we build up a fully normalized and
+validated tree. Some of the steps are
+ - read in descriptors
+ - process annotations filling in the descriptor tree
+ - validating app compliance
+ - resolving resource references
+ - resolving ejb references
+ - turning the descriptor tree into Info objects for final assembly
+ - final validation check
+
+ 2. assembly (AppInfo -> actual running app) we assemble a running app as
+detailed by the AppInfo
+ - creating classloaders for the application
+ - creating EntityManagers and EntityManagerFactories
+ - creating live objects associated with resource-env-refs
+ - creating deployment (CoreDeploymentInfo) objects for each ejb
+ - creating the jndi enc of each ejb
+ - adding method permission objects into the security system (JACC
+Provider)
+ - creating transaction policy objects for each ejb
+ - creating interceptor stacks and bindings for each ejb
+ - adding ejbs to containers (which may also do things like create
+pools)
+ - adding ejbs to the live ContainerSystem registry of ejbs
+ - adding global jndi entries for each ejb
+
+
+The listings above aren't necesarrily complete or perfectly ordered, but
+generally show the nature of the work done in each phase.
+
+<a name="ConfigurationandAssembly-ConfigurationPhase"></a>
+## Configuration Phase
+
+A goal is that nothing gets through configuration and into assembly if it
+can't actually be built. The configuration phase is where we're supposed
+to wipe away any ambiguity, fully normalize the app, make sure it's
+internally consistent, spec compliant and generally good to go. If it's
+not, no worries as we actually haven't built anything permanent yet.
+Everything in the configuration phase is temporary. If it fails the
+configuration phase we just issue an error and say "App will not be loaded"
+and that's it, there's nothing to undo.
+
+<a name="ConfigurationandAssembly-InfoObjects-DatabetweenConfigurationandAssembly"></a>
+## Info Objects - Data between Configuration and Assembly
+
+The output of the configuration phase is what we call Info objects and the
+root of that tree is OpenEjbConfiguration. These objects are all simple,
+serializable data types with no methods, no constructors and no code or
+logic of any kind. We even have a test that uses ASM to walk down the Info
+tree and check that everything is compliant to these strict rules.
+
+All of the aforementioned configuration phase sits behind this info object
+tree and an interface that produces it:
+
+ org.apache.openejb.assembler.classic.OpenEjbConfiguration
+ org.apache.openejb.assembler.classic.OpenEjbConfigurationFactory
+
+The job of the OpenEjbConfigurationFactory is simply to produce an
+OpenEjbConfiguration tree. With this simple decoupling when the time comes
+we can actually support much different styles of use/topologies. For
+example, a cluster scenario. We could create an
+OpenEjbConfigurationFactory implementation that actually pulled the
+OpenEjbConfiguration from a central store or some sort of configuration
+server of our creation. Perhaps, someday we write an
+OpenEjbConfigurationFactory implementation to wrap the existing one and
+look for any changed files. If nothing has changed since last boot, we
+simple deserialize an OpenEjbConfiguration tree saved from a previous boot
+as a way of reducing startup time on very large apps.
+
+<a name="ConfigurationandAssembly-Assembly"></a>
+## Assembly
+
+The assembly phase is where real running things are actually built. This
+process is inherently ingrained in the details on how OpenEJB works
+internally. Keeping it separated from descriptor parsing, validation,
+resolving, etc. keeps the actual "openejb building" code as simple as
+possible. It also allows for some flexibility and change to take place
+architecturally with less chance of it rippling through the entire system.
+However it's also not so generic (like spring, etc.) that becomes very
+difficult to get things built in a certain way or in a certain order
+requiring you to jump through several hoops just to keep the generic system
+as beautiful as possible. It knows all the details on how to build each
+individual part and in what order to build them.
+
+In OpenEJB, the Assembler is not supposed to be the gem of the project that
+we keep clean, motivating us to push complex things out into other areas
+for other people (usually users) to worry about. In fact, it's the
+opposite. The runtime system gets top priority on it's architectural needs
+and the assembler gets last priority. If there's something we can do in
+the Assembler that saves the rest of the system from complexity, we gladly
+throw the Assembler on that grenade. Our philosophy is that you can't make
+100% of your system "perfect" all the time and sometime the mess has to go
+somewhere. The assembler is where. It's purposely not over architected so
+that it can continue to serve as a place to take up slack and not make all
+this stuff harder than it has to be.
+
Added: openejb/site/trunk/content/configuration.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/configuration.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/configuration.cwiki (added)
+++ openejb/site/trunk/content/configuration.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1,119 @@
+h1. Short Overview
+
+h2. 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
+* *openejb.descriptors.output* - possible values: true|false - When set OpenEJB saves deployment descriptors - ejb-jar.xml and openejb-jar.xml
+
+h2. Configuration File
+
+Show a config file with the elements hyperlinked.
+
+{code:xml|title=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>
+{code}
+
+h1. 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.
+
+h2. Summary
+
+A summary of the above in a different notation:
+
+{noformat}
+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
+{noformat}
+
+h2. 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:
+{noformat}
+/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/
+{noformat}
+
+
+h2. 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:
+{noformat}
+/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)
+{noformat}
Propchange: openejb/site/trunk/content/configuration.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: openejb/site/trunk/content/configuration.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/configuration.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/configuration.mdtext (added)
+++ openejb/site/trunk/content/configuration.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,155 @@
+Title: Configuration
+<a name="Configuration-ShortOverview"></a>
+# Short Overview
+
+<a name="Configuration-ConfigurationProperties"></a>
+## 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](collapsed-ear.html)
+** *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
+* *openejb.descriptors.output* - possible values: true|false - When set
+OpenEJB saves deployment descriptors - ejb-jar.xml and openejb-jar.xml
+
+<a name="Configuration-ConfigurationFile"></a>
+## Configuration File
+
+Show a config file with the elements hyperlinked.
+
+{code:xml|title=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>
+
+
+ h1. 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.
+
+ h2. Summary
+
+ A summary of the above in a different notation:
+
+ {noformat}
+ 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
+ {noformat}
+
+ h2. 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:
+ {noformat}
+ /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/
+ {noformat}
+
+
+ h2. 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:
+ {noformat}
+ /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)
+ {noformat}
Added: openejb/site/trunk/content/containers.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/containers.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/containers.cwiki (added)
+++ openejb/site/trunk/content/containers.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1,247 @@
+
+h1. 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...
+
+{code:xml|title=example_01.conf}
+<?xml version="1.0"?>
+<openejb>
+
+<Container id="Default CMP Container" ctype="CMP_ENTITY"/>
+
+</openejb>
+{code}
+
+The really fun part is that the above configuration file is completely legal! If you started the server and pointed to this file...
+
+bq. ./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.
+
+{quote}
+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]$
+{quote}
+
+You see that. No beans, no JDBC resources, nothing but one CMP container called "Default CMP Container".
+
+h1. 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"
+
+{code:xml|title=example_02.conf}
+<?xml version="1.0"?>
+<openejb>
+
+<Container id="My PostgreSQL Container" ctype="CMP_ENTITY"/>
+
+</openejb>
+{code}
+
+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.
+
+{quote}
+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:
+{quote}
+
+After deployment, you would end up with a configuration like this one
+
+{code:xml|title=example_02.conf}
+<?xml version="1.0"?>
+<openejb>
+
+<Container id="My PostgreSQL Container" ctype="CMP_ENTITY"/>
+
+<Deployments jar="myCMPBean.jar" />
+
+</openejb>
+{code}
+
+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!
+
+h1. 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.
+
+{code:xml|title=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>
+{code}
+
+h1. 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.
+
+{code:xml|title=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>
+{code}
+
+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..
+
+{code:xml|title=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>
+{code}
+
+
+h1. Configuration properties
+
+The actual properties that each container type accepts are different for each type. Here is a reference for each container type.
+
+h2. CMP_ENTITY properties
+
+h3. 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:
+bq. PoolSize 100
+
+h3. 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:
+bq. Global_TX_Database conf/default.cmp_global_tx_database.xml
+
+h3. 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:
+bq. Local_TX_Database conf/default.cmp_local_tx_database.xml
+
+h2. BMP_ENTITY properties
+
+The BMP Container has no customizable properties to override.
+
+h2. STATEFUL properties
+
+h3. 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:
+bq. Passivator org.openejb.core.stateful.SimplePassivater
+
+h3. 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:
+bq. TimeOut 20
+
+h3. PoolSize
+
+Specifies the size of the bean pools for this stateful SessionBean container.
+
+Default:
+bq. PoolSize 100
+
+h3. 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:
+bq. BulkPassivate 50
+
+h2. STATELESS properties
+
+h3. StrictPooling
+
+Specifies the whether or not to this stateless SessionBean container should use a strict pooling algorithm. true or false
+
+Default:
+bq. StrictPooling true
\ No newline at end of file
Propchange: openejb/site/trunk/content/containers.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: openejb/site/trunk/content/containers.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/containers.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/containers.mdtext (added)
+++ openejb/site/trunk/content/containers.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,314 @@
+Title: Containers
+
+<a name="Containers-DeclaringyourContainer"></a>
+# 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...
+
+{code:xml|title=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...
+
+ bq. ./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.
+
+ {quote}
+ 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]
+$
+ {quote}
+
+ You see that. No beans, no JDBC resources, nothing but one CMP container
+called "Default CMP Container".
+
+ h1. 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"
+
+ {code:xml|title=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.
+
+{quote}
+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:
+{quote}
+
+After deployment, you would end up with a configuration like this one
+
+{code:xml|title=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!
+
+ h1. 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.
+
+ {code:xml|title=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>
+
+
+<a name="Containers-ConfiguringyourContainer"></a>
+# 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.
+
+{code:xml|title=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..
+
+ {code:xml|title=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>
+
+
+
+<a name="Containers-Configurationproperties"></a>
+# Configuration properties
+
+The actual properties that each container type accepts are different for
+each type. Here is a reference for each container type.
+
+<a name="Containers-CMP_ENTITYproperties"></a>
+## CMP_ENTITY properties
+
+<a name="Containers-PoolSize"></a>
+### 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:
+bq. PoolSize 100
+
+<a name="Containers-Global_TX_Database"></a>
+### 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:
+bq. Global_TX_Database conf/default.cmp_global_tx_database.xml
+
+<a name="Containers-Local_TX_Database"></a>
+### 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:
+bq. Local_TX_Database conf/default.cmp_local_tx_database.xml
+
+<a name="Containers-BMP_ENTITYproperties"></a>
+## BMP_ENTITY properties
+
+The BMP Container has no customizable properties to override.
+
+<a name="Containers-STATEFULproperties"></a>
+## STATEFUL properties
+
+<a name="Containers-Passivator"></a>
+### 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:
+bq. Passivator org.openejb.core.stateful.SimplePassivater
+
+<a name="Containers-TimeOut"></a>
+### 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:
+bq. TimeOut 20
+
+<a name="Containers-PoolSize"></a>
+### PoolSize
+
+Specifies the size of the bean pools for this stateful SessionBean
+container.
+
+Default:
+bq. PoolSize 100
+
+<a name="Containers-BulkPassivate"></a>
+### 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:
+bq. BulkPassivate 50
+
+<a name="Containers-STATELESSproperties"></a>
+## STATELESS properties
+
+<a name="Containers-StrictPooling"></a>
+### StrictPooling
+
+Specifies the whether or not to this stateless SessionBean container should
+use a strict pooling algorithm. true or false
+
+Default:
+bq. StrictPooling true
Added: openejb/site/trunk/content/contribution-tips.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/contribution-tips.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/contribution-tips.cwiki (added)
+++ openejb/site/trunk/content/contribution-tips.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1,134 @@
+h1. First steps
+
+# Subscribe to the [dev list|mailto:dev-subscribe@openejb.apche.org] and say Hi
+# Get the source code with svn or git
+** svn co https://svn.apache.org/repos/asf/openejb/trunk/openejb3
+# Build the code (maven 2.2.1 or higher recommended)
+** mvn clean install
+
+Play around with the examples under the examples/ directory. Some of the neater ones are (ordered simple to complex):
+
+ - simple-stateless ([see video| http://vimeo.com/6149008])
+ - simple-stateful
+ - simple-singleton
+ - simple-mdb
+ - async-methods
+ - schedule-methods
+ - injection-of-env-entry
+ - injection-of-ejbs
+ - injection-of-datasource
+ - injection-of-entitymanager
+ - testcase-injection
+ - testing-transactions
+ - transaction-rollback
+ - testing-security
+ - testing-security-2
+ - simple-webservice
+
+
+h1. What is the process?
+
+{code:title=Contributor.java}
+public void contributeToOpenSource() {
+
+ boolean stillInterestedAndHavingFun = true;
+ int taskSize = 1; // start small!
+
+ contributing:
+ while (stillInterestedAndHavingFun) {
+
+ Task task = findSomethingInteresting(taskSize++);
+
+ if (!task.hasJira()) {
+ createJira(task);
+ } else {
+ requestToBeAssignedToJira(task.jiraId());
+ }
+
+ while (task.inProgress()) {
+
+ chatOnListALittleGetCleverIdeas(task, new Ideas(task));
+ hackALittle(task);
+
+ if (task.tooHard() || task.notFun()) {
+ // no big deal, try again with something else
+ taskSize--;
+ continue contributing;
+ }
+ }
+
+ File patchFile = createSvnOrGitPatch(task);
+ attachToJira(task.jiraId(), patchFile);
+ askForReviewOnList(task.jiraId());
+
+ while (!committed(patchFile)) {
+
+ try {
+ pokeAtSometingElse();
+ helpOnUserList();
+ dayDream();
+ } catch (MoreThanAWeekException e) {
+ // Assume it fell off the radar -- happens.
+ // Evidence we need more committers.
+ bumpThreadOnList(task);
+ }
+ }
+ }
+
+}
+{code}
+
+After a while when people feel comfortable with you as contributor, they vote you in as a committer and ... big surprise ... there's almost no change in the daily routine. You get access to svn and pretty much everything else stays the same. Instead of submitting patches, now you have to help review them and commit them. Instead of learning how to contribute to an open source project, now you have to learn how to help others get involved. And of course it doesn't happen all at once, you never stop learning these things and you never stop wishing you had more time.
+
+No one cares how much code you can write or how fast you can write it. We all just contribute what we can when we can and there are no expectations on how much, how often, or where.
+
+It's very much about the journey and there is no real end as long as you're having fun and learning.
+
+Probably finding something to do when you do have time is the hardest part ... that never changes.
+
+h1. Be Brave
+
+Don't assume everything has already been discussed a million times and you're the only one who doesn't know and so you shouldn't bother anyone and should just figure it out on your own. That thinking is your enemy. Don't do that or you will get nowhere ... very slowly. So slowly that now you feel you really can't ask about it because surely everyone assumes you know it or have done it by now. That thinking is a terrible trap. Ask questions. Post your thoughts.
+
+Don't worry about asking "stupid" questions on the list -- even simple questions have great value. They often lead to surprisingly good discussions. They also have a profound impact on the people around you, the ones you don't see.
+
+There are always a handful of people silently reading the list and wishing they could participate, but are less brave. Whenever someone like you finally does show up and asks basic questions and shows it's ok, we usually get another 1 or 2 new faces who suddenly find the courage to speak up.
+
+Maybe it's like Karaoke; if the people singing sound like you when you sing, there are better odds you might get up and sign too. Seeing people like yourself do the things you want to do is inspiring.
+
+h1. Start Small
+
+You may suddenly get a creative surge and see many many things that could be done. One thing you learn about open source is that you never know when life is going to intervene and you have to stop. So it's always really good to get a little tiny thing working, checked in, and just grow it iteratively as time permits. It is a practice that is key for people of any skill level. And it goes wonderfully with Open Source as it adds plenty of space for new ideas. Stone soup starts with the stone, not the soup!
+
+So no matter how big the idea or task, ask yourself "do I really need all of this to get started?". Start with the tiniest possible version. And then cut it down again :)
+
+Code is easier to grow than change. And with today's refactoring tools even change is pretty easy. What's hard is taking a big piece of code and jamming it into another big piece of code. Don't work too long in isolation.
+
+Start small, get it checked in (or patch submitted) and work iteratively.
+
+h1. Things that always need doing
+
+ - Final variables & fields are preferred where possible, but a lot of the code is old. Feel free to add them and hand the code back.
+ - If you have any skills with code coverage tools, then you'll probably find way too much to do! Tests are always welcome.
+ - There are over a 1,000 TODO comments in the code. Maybe some should be deleted. Maybe some could be completed. They probably all should have a JIRA id on them.
+ - Pick a random class, see if you can figure out what it is doing and javadoc it.
+ - Add @Override where applicable
+ - Intellij has an 'Inspect Code' feature. Yikes does it produce a lot of output.
+ - No doubt there is some exception handling that can be greatly improved.
+
+Obviously, one could get quite bored doing just the above. But sometimes the above tasks can lead to more fun and exciting things. Anything that gets you in and looking at code and actually touching and changing it usually results in questions, discussions and ideas... then little passions and late nights and lack of sleep and caffeine abuse.
+
+
+h1. Things to avoid
+
+h4. Huge patches
+
+Huge patches are hard to digest. Try to avoid them whenever possible. Any step forward is a good one. Small steps allow people to see where you're headed and give input. That's true regardless if you are a committer or contributor.
+
+h4. Be careful with reformatting
+
+Try to never mix logic changes with code reformatting. It makes it nearly impossible for others to see what the actual change was.
+
+ - If you are a committer and want to reformat something, do the reformat as a separate commit before or after the real change. As long as they are separate and clearly marked it should be easy for people to see what is going on.
+ - If you are a contributor and want to reformat something, maybe suggest it on the list, but avoid submitting patches that are just reformatting.
+
Propchange: openejb/site/trunk/content/contribution-tips.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: openejb/site/trunk/content/contribution-tips.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/contribution-tips.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/contribution-tips.mdtext (added)
+++ openejb/site/trunk/content/contribution-tips.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,202 @@
+Title: Contribution Tips
+<a name="ContributionTips-Firststeps"></a>
+# First steps
+
+1. Subscribe to the [dev list](mailto:dev-subscribe@openejb.apche.org.html)
+ and say Hi
+1. Get the source code with svn or git
+** svn co https://svn.apache.org/repos/asf/openejb/trunk/openejb3
+1. Build the code (maven 2.2.1 or higher recommended)
+** mvn clean install
+
+Play around with the examples under the examples/ directory. Some of the
+neater ones are (ordered simple to complex):
+
+ - simple-stateless ([see video](-http://vimeo.com/6149008.html)
+)
+ - simple-stateful
+ - simple-singleton
+ - simple-mdb
+ - async-methods
+ - schedule-methods
+ - injection-of-env-entry
+ - injection-of-ejbs
+ - injection-of-datasource
+ - injection-of-entitymanager
+ - testcase-injection
+ - testing-transactions
+ - transaction-rollback
+ - testing-security
+ - testing-security-2
+ - simple-webservice
+
+
+<a name="ContributionTips-Whatistheprocess?"></a>
+# What is the process?
+
+<DIV class="code panel" style="border-style: solid;border-width: 1px;"><DIV class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><B>Contributor.java</B></DIV><DIV class="codeContent panelContent">
+ public void contributeToOpenSource() {
+
+ boolean stillInterestedAndHavingFun = true;
+ int taskSize = 1; // start small!
+
+ contributing:
+ while (stillInterestedAndHavingFun) {
+
+ Task task = findSomethingInteresting(taskSize++);
+
+ if (!task.hasJira()) {
+ createJira(task);
+ } else {
+ requestToBeAssignedToJira(task.jiraId());
+ }
+
+ while (task.inProgress()) {
+
+ chatOnListALittleGetCleverIdeas(task, new Ideas(task));
+ hackALittle(task);
+
+ if (task.tooHard() || task.notFun()) {
+ // no big deal, try again with something else
+ taskSize--;
+ continue contributing;
+ }
+ }
+
+ File patchFile = createSvnOrGitPatch(task);
+ attachToJira(task.jiraId(), patchFile);
+ askForReviewOnList(task.jiraId());
+
+ while (!committed(patchFile)) {
+
+ try {
+ pokeAtSometingElse();
+ helpOnUserList();
+ dayDream();
+ } catch (MoreThanAWeekException e) {
+ // Assume it fell off the radar -- happens.
+ // Evidence we need more committers.
+ bumpThreadOnList(task);
+ }
+ }
+ }
+
+ }
+
+
+After a while when people feel comfortable with you as contributor, they
+vote you in as a committer and ... big surprise ... there's almost no
+change in the daily routine. You get access to svn and pretty much
+everything else stays the same. Instead of submitting patches, now you
+have to help review them and commit them. Instead of learning how to
+contribute to an open source project, now you have to learn how to help
+others get involved. And of course it doesn't happen all at once, you
+never stop learning these things and you never stop wishing you had more
+time.
+
+No one cares how much code you can write or how fast you can write it. We
+all just contribute what we can when we can and there are no expectations
+on how much, how often, or where.
+
+It's very much about the journey and there is no real end as long as you're
+having fun and learning.
+
+Probably finding something to do when you do have time is the hardest part
+... that never changes.
+
+<a name="ContributionTips-BeBrave"></a>
+# Be Brave
+
+Don't assume everything has already been discussed a million times and
+you're the only one who doesn't know and so you shouldn't bother anyone and
+should just figure it out on your own. That thinking is your enemy. Don't
+do that or you will get nowhere ... very slowly. So slowly that now you
+feel you really can't ask about it because surely everyone assumes you know
+it or have done it by now. That thinking is a terrible trap. Ask
+questions. Post your thoughts.
+
+Don't worry about asking "stupid" questions on the list -- even simple
+questions have great value. They often lead to surprisingly good
+discussions. They also have a profound impact on the people around you,
+the ones you don't see.
+
+There are always a handful of people silently reading the list and wishing
+they could participate, but are less brave. Whenever someone like you
+finally does show up and asks basic questions and shows it's ok, we usually
+get another 1 or 2 new faces who suddenly find the courage to speak up.
+
+Maybe it's like Karaoke; if the people singing sound like you when you
+sing, there are better odds you might get up and sign too. Seeing people
+like yourself do the things you want to do is inspiring.
+
+<a name="ContributionTips-StartSmall"></a>
+# Start Small
+
+You may suddenly get a creative surge and see many many things that could
+be done. One thing you learn about open source is that you never know when
+life is going to intervene and you have to stop. So it's always really
+good to get a little tiny thing working, checked in, and just grow it
+iteratively as time permits. It is a practice that is key for people of
+any skill level. And it goes wonderfully with Open Source as it adds
+plenty of space for new ideas. Stone soup starts with the stone, not the
+soup!
+
+So no matter how big the idea or task, ask yourself "do I really need all
+of this to get started?". Start with the tiniest possible version. And
+then cut it down again :)
+
+Code is easier to grow than change. And with today's refactoring tools
+even change is pretty easy. What's hard is taking a big piece of code and
+jamming it into another big piece of code. Don't work too long in
+isolation.
+
+Start small, get it checked in (or patch submitted) and work iteratively.
+
+<a name="ContributionTips-Thingsthatalwaysneeddoing"></a>
+# Things that always need doing
+
+ - Final variables & fields are preferred where possible, but a lot of the
+code is old. Feel free to add them and hand the code back.
+ - If you have any skills with code coverage tools, then you'll probably
+find way too much to do! Tests are always welcome.
+ - There are over a 1,000 TODO comments in the code. Maybe some should be
+deleted. Maybe some could be completed. They probably all should have a
+JIRA id on them.
+ - Pick a random class, see if you can figure out what it is doing and
+javadoc it.
+ - Add @Override where applicable
+ - Intellij has an 'Inspect Code' feature. Yikes does it produce a lot of
+output.
+ - No doubt there is some exception handling that can be greatly improved.
+
+Obviously, one could get quite bored doing just the above. But sometimes
+the above tasks can lead to more fun and exciting things. Anything that
+gets you in and looking at code and actually touching and changing it
+usually results in questions, discussions and ideas... then little passions
+and late nights and lack of sleep and caffeine abuse.
+
+
+<a name="ContributionTips-Thingstoavoid"></a>
+# Things to avoid
+
+<a name="ContributionTips-Hugepatches"></a>
+#### Huge patches
+
+Huge patches are hard to digest. Try to avoid them whenever possible. Any
+step forward is a good one. Small steps allow people to see where you're
+headed and give input. That's true regardless if you are a committer or
+contributor.
+
+<a name="ContributionTips-Becarefulwithreformatting"></a>
+#### Be careful with reformatting
+
+Try to never mix logic changes with code reformatting. It makes it nearly
+impossible for others to see what the actual change was.
+
+ - If you are a committer and want to reformat something, do the reformat
+as a separate commit before or after the real change. As long as they are
+separate and clearly marked it should be easy for people to see what is
+going on.
+ - If you are a contributor and want to reformat something, maybe suggest
+it on the list, but avoid submitting patches that are just reformatting.
+
Added: openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.cwiki (added)
+++ openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1 @@
+blah
Propchange: openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.mdtext (added)
+++ openejb/site/trunk/content/created-on-thu-apr-22-16.59.59-edt-2010.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,2 @@
+Title: created on Thu Apr 22 16.59.59 EDT 2010
+blah
Added: openejb/site/trunk/content/creating-itests.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/creating-itests.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/creating-itests.cwiki (added)
+++ openejb/site/trunk/content/creating-itests.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1,127 @@
+h1. OpenEJB itests
+
+The OpenEJB itests module is a framework to create EJB test cases that are designed according to the JUnit rules, i.e. they all have setUp, tests and tearDown methods. Since it's JUnit-based, you can do whatever you could do in JUnit.
+
+This page describes the steps to create EJB test cases.
+
+h2. How itests work
+
+The itests module lives in OpenEJB's repository in the _modules\itests_ directory. Setting up the test environment to execute the itests is based on ([maven-itest-plugin-1.0 plugin|http://svn.apache.org/repos/asf/maven/maven-1/plugins-sandbox/trunk/itest/]).
+
+Take a look at maven.xml in modules\itests directory. There you'll see that the default goal is _ejb:install_, which in turn executes _itest_. When the EJBs (todo: describe it a bit more) are done, the _itest:setup_ goal is executed, which starts the real game. First, _org/openejb/Security_ configuration is started. Once it's done, _openejb-itests-xxx.jar_ is deployed, which is _org/openejb/Itests_ configuration to be started, afterwards. When the configurations are deployed and started, the maven-itest-plugin executes junit (see [Ant JUnit task documentation|http://ant.apache.org/manual/OptionalTasks/junit.html] and project.properties of the itests module). The project.properties file configures which itests are run and some other stuff.
+
+The first itest test case is _org.openejb.test.entity.cmp.CmpTestSuite_. Consult this for more information. Then the others defined in _maven.itest.includes_ property are executed.
+
+The order in which the itests are executed is important, so the first order is set up via the maven.itest.includes property, then the test suites add their tests in some order, and finally the method names in the test classes put yet another order. So, be careful what name your test method name will become. It may influence the order.
+
+Some EJBs access database resources. It's even more important for CMPs. The itests module uses the database as defined in the _openejb.test.database_ property. It's currently defined in the _project.properties_ file of the module. You can change its value to whatever you wish using the Maven property setting approaches (-D on the command line, project.properties, build.properties in your home directory or the project you work in).
+
+So, the last important information is how the junit tests access the server resources - EJBs. It's done via executing session beans that in turn get at the test EJBs, mostly CMPs. It's also possible that the CMP itests will be accessed directly without having to pass on the call through a session bean.
+
+If itests are part of a larger project structure you can disable executing it using the _maven.itest.skip_ property. Set it to _true_ and Maven won't run the itests.
+
+h2. Simple CMP 2.1 itest
+
+h3. Database setup
+
+The itests default database is Derby. The class - _org.openejb.test.DerbyTestDatabase_ - is instantiated upon executing _org.openejb.testTestManager.getDatabase()_ in each test case's _setUp()_ method. Remember, you can define any other database using the _openejb.test.database_ property or do initialization of your own database choice in the setUp() method.
+
+The current implementation of database initialization is based on two DerbyTestDatabse methods: _createCMP2Model()_ and _dropCMP2Model()_ that create and drop database structure, accordingly.
+
+h3. CMP 2.1 deployment
+
+{info:title=Information}
+Unless specified, all directories are relative to _modules/itests_ directory and commands are executed in it.
+{info}
+
+A Maven project can produce one build artefact. It's very important to keep in mind whenever your tests are to be based on a EJB that's not built by default. The default EJBs are defined in _modules/itests/src/ejb/META-INF/ejb-jar.xml_. The corresponding deployment plan - the _openejb-jar.xml_ file is in _modules/itests/src/ejb/META-INF/openejb-jar.xml_.
+
+If you want to test your own EJB, you need to build it yourself, i.e. describe the build and deployment in _modules/itests/maven.xml_ in the pregoal of _itest:setup_.
+
+In the following example, Ant's jar builds openejb-cmp2-petstore.jar file, which in turn is distributed and started in Geronimo. The _id_ attribute of _deploy:start_ is as specified in the module's deployment plan. See [Geronimo Deployment|http://wiki.apache.org/geronimo/Deployment] for more information about Geronimo deployment plans.
+
+{noformat}
+<ant:jar destfile="${basedir}/target/openejb-cmp2-petstore.jar">
+ <fileset dir="${basedir}/target/classes">
+ <include name="**/cmp2/petstore/*.class"/>
+ <include name="**/TestFailureException.class"/>
+ </fileset>
+ <metainf dir="${basedir}/src/cmp2/petstore" includes="*.xml"/>
+</ant:jar>
+<deploy:distribute
+ uri="deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector"
+ username="system"
+ password="manager"
+ module="${basedir}/target/openejb-cmp2-petstore.jar"
+/>
+<deploy:start
+ uri="deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector"
+ username="system"
+ password="manager"
+ id="org/openejb/cmp2/petstore"/>
+{noformat}
+
+h3. Execution
+
+When EJB classes, deployment descriptor and plan, maven.xml are all set up, it's time to execute your tests. In order to run itests you will run Maven in _modules/itests_ directory.
+
+{noformat}
+~/openejb/modules/itests
+$ maven
+{noformat}
+
+It's also possible to override project properties and run only some test cases.
+
+{noformat}
+~/openejb/modules/itests
+$ maven -Dmaven.itest.includes=**/Cmp2TestSuite.java
+{noformat}
+
+When a failure occurs, you should take a look at the result file of the failed test suite in _target/itest-reports_, e.g.
+
+{noformat}
+~/openejb/modules/itests
+$ maven -Dmaven.itest.includes=**/Cmp2TestSuite.java -o
+...
+ [junit] Tests run: 113, Failures: 1, Errors: 0, Time elapsed: 22,132 sec
+ [junit] [ERROR] TEST org.openejb.test.entity.cmp2.Cmp2TestSuite FAILED
+...
+BUILD FAILED
+File...... C:\Documents and Settings\root\.maven\cache\maven-itest-plugin-1.0\plugin.jelly
+Element... fail
+Line...... 166
+Column.... 64
+There were test failures.
+Total time: 2 minutes 3 seconds
+Finished at: Sun Jul 17 17:48:36 CEST 2005
+
+$ more target/itest-reports/TEST-org.openejb.test.entity.cmp2.Cmp2TestSuite.txt
+Testsuite: org.openejb.test.entity.cmp2.Cmp2TestSuite
+Tests run: 113, Failures: 1, Errors: 0, Time elapsed: 22,132 sec
+
+Testcase: PetstoreTests.create: FAILED
+Received Exception class java.lang.NullPointerException : null
+junit.framework.AssertionFailedError: Received Exception class java.lang.NullPointerException : null
+ at org.openejb.test.entity.cmp2.PetstoreTests.test01_create(PetstoreTests.java:84)
+ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
+ at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
+ at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
+ at org.openejb.test.NumberedTestCase.runTestMethod(NumberedTestCase.java:195)
+ at org.openejb.test.NumberedTestCase$3.protect(NumberedTestCase.java:169)
+ at org.openejb.test.NumberedTestCase.run(NumberedTestCase.java:172)
+ at org.openejb.test.NumberedTestCase.run(NumberedTestCase.java:141)
+ at org.openejb.test.TestSuite.run(TestSuite.java:71)
+...
+{noformat}
+
+Complete execution log is in _target/openejb/var/log/openejb.log_ of the itests module.
+
+h4. Running the Tests in Eclipse.
+
+The steps for running the iTests inside of Eclipse are given below. They are
+
+1) For Local Interface Tests, the class to be run is _org.apache.openejb.iTest_.
+2) For Remote Interface Tests, the class to be run is _org.apache.openejb.RemoteiTest_.
+
+In both the cases you need to give _'-Dopenejb.home=target/test-classes/'_ as a vm argument
+for the tests to run.
\ No newline at end of file
Propchange: openejb/site/trunk/content/creating-itests.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: openejb/site/trunk/content/creating-itests.mdtext
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/creating-itests.mdtext?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/creating-itests.mdtext (added)
+++ openejb/site/trunk/content/creating-itests.mdtext Sun Jul 10 04:33:54 2011
@@ -0,0 +1,203 @@
+Title: Creating itests
+<a name="Creatingitests-OpenEJBitests"></a>
+# OpenEJB itests
+
+The OpenEJB itests module is a framework to create EJB test cases that are
+designed according to the JUnit rules, i.e. they all have setUp, tests and
+tearDown methods. Since it's JUnit-based, you can do whatever you could do
+in JUnit.
+
+This page describes the steps to create EJB test cases.
+
+<a name="Creatingitests-Howitestswork"></a>
+## How itests work
+
+The itests module lives in OpenEJB's repository in the _modules\itests_ directory. Setting up the test environment to execute the itests is based on ([maven-itest-plugin-1.0 plugin](http://svn.apache.org/repos/asf/maven/maven-1/plugins-sandbox/trunk/itest/)
+).
+
+Take a look at maven.xml in modules\itests directory. There you'll see that
+the default goal is _ejb:install_, which in turn executes _itest_. When the
+EJBs (todo: describe it a bit more) are done, the _itest:setup_ goal is
+executed, which starts the real game. First, _org/openejb/Security_
+configuration is started. Once it's done, _openejb-itests-xxx.jar_ is
+deployed, which is _org/openejb/Itests_ configuration to be started,
+afterwards. When the configurations are deployed and started, the
+maven-itest-plugin executes junit (see [Ant JUnit task documentation](http://ant.apache.org/manual/OptionalTasks/junit.html)
+ and project.properties of the itests module). The project.properties file
+configures which itests are run and some other stuff.
+
+The first itest test case is _org.openejb.test.entity.cmp.CmpTestSuite_.
+Consult this for more information. Then the others defined in
+_maven.itest.includes_ property are executed.
+
+The order in which the itests are executed is important, so the first order
+is set up via the maven.itest.includes property, then the test suites add
+their tests in some order, and finally the method names in the test classes
+put yet another order. So, be careful what name your test method name will
+become. It may influence the order.
+
+Some EJBs access database resources. It's even more important for CMPs. The
+itests module uses the database as defined in the _openejb.test.database_
+property. It's currently defined in the _project.properties_ file of the
+module. You can change its value to whatever you wish using the Maven
+property setting approaches (-D on the command line, project.properties,
+build.properties in your home directory or the project you work in).
+
+So, the last important information is how the junit tests access the server
+resources - EJBs. It's done via executing session beans that in turn get at
+the test EJBs, mostly CMPs. It's also possible that the CMP itests will be
+accessed directly without having to pass on the call through a session
+bean.
+
+If itests are part of a larger project structure you can disable executing
+it using the _maven.itest.skip_ property. Set it to _true_ and Maven won't
+run the itests.
+
+<a name="Creatingitests-SimpleCMP2.1itest"></a>
+## Simple CMP 2.1 itest
+
+<a name="Creatingitests-Databasesetup"></a>
+### Database setup
+
+The itests default database is Derby. The class -
+_org.openejb.test.DerbyTestDatabase_ - is instantiated upon executing
+_org.openejb.testTestManager.getDatabase()_ in each test case's _setUp()_
+method. Remember, you can define any other database using the
+_openejb.test.database_ property or do initialization of your own database
+choice in the setUp() method.
+
+The current implementation of database initialization is based on two
+DerbyTestDatabse methods: _createCMP2Model()_ and _dropCMP2Model()_ that
+create and drop database structure, accordingly.
+
+<a name="Creatingitests-CMP2.1deployment"></a>
+### CMP 2.1 deployment
+
+{info:title=Information}
+Unless specified, all directories are relative to _modules/itests_
+directory and commands are executed in it.
+{info}
+
+A Maven project can produce one build artefact. It's very important to keep
+in mind whenever your tests are to be based on a EJB that's not built by
+default. The default EJBs are defined in
+_modules/itests/src/ejb/META-INF/ejb-jar.xml_. The corresponding deployment
+plan - the _openejb-jar.xml_ file is in
+_modules/itests/src/ejb/META-INF/openejb-jar.xml_.
+
+If you want to test your own EJB, you need to build it yourself, i.e.
+describe the build and deployment in _modules/itests/maven.xml_ in the
+pregoal of _itest:setup_.
+
+In the following example, Ant's jar builds openejb-cmp2-petstore.jar file,
+which in turn is distributed and started in Geronimo. The _id_ attribute of
+_deploy:start_ is as specified in the module's deployment plan. See [Geronimo Deployment](http://wiki.apache.org/geronimo/Deployment)
+ for more information about Geronimo deployment plans.
+
+
+ <ant:jar destfile="${basedir}/target/openejb-cmp2-petstore.jar">
+ <fileset dir="${basedir}/target/classes">
+ <include name="**/cmp2/petstore/*.class"/>
+ <include name="**/TestFailureException.class"/>
+ </fileset>
+ <metainf dir="${basedir}/src/cmp2/petstore" includes="*.xml"/>
+ </ant:jar>
+ <deploy:distribute
+ uri="deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector"
+ username="system"
+ password="manager"
+ module="${basedir}/target/openejb-cmp2-petstore.jar"
+ />
+ <deploy:start
+ uri="deployer:geronimo:jmx:rmi://localhost/jndi/rmi:/JMXConnector"
+ username="system"
+ password="manager"
+ id="org/openejb/cmp2/petstore"/>
+
+
+<a name="Creatingitests-Execution"></a>
+### Execution
+
+When EJB classes, deployment descriptor and plan, maven.xml are all set up,
+it's time to execute your tests. In order to run itests you will run Maven
+in _modules/itests_ directory.
+
+
+ ~/openejb/modules/itests
+ $ maven
+
+
+It's also possible to override project properties and run only some test
+cases.
+
+
+ ~/openejb/modules/itests
+ $ maven -Dmaven.itest.includes=**/Cmp2TestSuite.java
+
+
+When a failure occurs, you should take a look at the result file of the
+failed test suite in _target/itest-reports_, e.g.
+
+
+ ~/openejb/modules/itests
+ $ maven -Dmaven.itest.includes=**/Cmp2TestSuite.java -o
+ ...
+ [junit]
+ Tests run: 113, Failures: 1, Errors: 0, Time elapsed: 22,132 sec
+ [junit]
+ [ERROR]
+ TEST org.openejb.test.entity.cmp2.Cmp2TestSuite FAILED
+ ...
+ BUILD FAILED
+ File...... C:\Documents and
+Settings\root\.maven\cache\maven-itest-plugin-1.0\plugin.jelly
+ Element... fail
+ Line...... 166
+ Column.... 64
+ There were test failures.
+ Total time: 2 minutes 3 seconds
+ Finished at: Sun Jul 17 17:48:36 CEST 2005
+
+ $ more
+target/itest-reports/TEST-org.openejb.test.entity.cmp2.Cmp2TestSuite.txt
+ Testsuite: org.openejb.test.entity.cmp2.Cmp2TestSuite
+ Tests run: 113, Failures: 1, Errors: 0, Time elapsed: 22,132 sec
+
+ Testcase: PetstoreTests.create: FAILED
+ Received Exception class java.lang.NullPointerException : null
+ junit.framework.AssertionFailedError: Received Exception class
+java.lang.NullPointerException : null
+ at
+org.openejb.test.entity.cmp2.PetstoreTests.test01_create(PetstoreTests.java:84)
+ at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
+ at
+sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
+ at
+sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
+ at
+org.openejb.test.NumberedTestCase.runTestMethod(NumberedTestCase.java:195)
+ at
+org.openejb.test.NumberedTestCase$3.protect(NumberedTestCase.java:169)
+ at org.openejb.test.NumberedTestCase.run(NumberedTestCase.java:172)
+ at org.openejb.test.NumberedTestCase.run(NumberedTestCase.java:141)
+ at org.openejb.test.TestSuite.run(TestSuite.java:71)
+ ...
+
+
+Complete execution log is in _target/openejb/var/log/openejb.log_ of the
+itests module.
+
+<a name="Creatingitests-RunningtheTestsinEclipse."></a>
+#### Running the Tests in Eclipse.
+
+The steps for running the iTests inside of Eclipse are given below. They
+are
+
+1) For Local Interface Tests, the class to be run is
+_org.apache.openejb.iTest_.
+2) For Remote Interface Tests, the class to be run is
+_org.apache.openejb.RemoteiTest_.
+
+In both the cases you need to give _'-Dopenejb.home=target/test-classes/'_
+as a vm argument
+for the tests to run.
Added: openejb/site/trunk/content/deployment-id.cwiki
URL: http://svn.apache.org/viewvc/openejb/site/trunk/content/deployment-id.cwiki?rev=1144777&view=auto
==============================================================================
--- openejb/site/trunk/content/deployment-id.cwiki (added)
+++ openejb/site/trunk/content/deployment-id.cwiki Sun Jul 10 04:33:54 2011
@@ -0,0 +1,142 @@
+h1. What is a Deployment ID?
+
+Every bean deployed in OpenEJB has a unique deployment-id that identifies it within the scope of the entire container system. The server and container system refer beans at run-time using the bean's deployment id.
+
+h2. Like ejb-name
+
+This deployment id is much like the <ejb-name> element of the ejb-jar.xml , with one very important difference. The <ejb-name> is only required to be unique within the scope of the ejb-jar.xml in the bean's jar. The deployment id is required to be unique across all beans and jars in OpenEJB. This is a subtle, but important, distinction.
+
+Remember that the EJB specification was designed so that enterprise beans could be create, packaged, and sold by vendors (EJB Providers). Furthermore, users should be able to buy a packaged set of beans (a jar with an ejb-jar.xml in it) and deploy it into an EJB Container without modification.
+
+h2. The ejb-name is not unique
+
+Let's consider this, what happens if two vendors each sell a package (jar) that contains a bean with the <ejb-name> PurchaseOrder? Both are completely different in terms functionality and are different beans in every other respect. The EJB spec says, this is fine, ejb-names only have to unique within the jar and that jar's ejb-jar.xml file. It's redictulous to excpect EJB Providers to call each other up and ask, "Are you already using the name 'PurchaseOrder' in your jar?" Remember that the EJB specification was designed so that enterprise beans could be create, packaged, and sold by vendors (EJB Providers). Furthermore, users should be able to buy a packaged set of beans (a jar with an ejb-jar.xml in it) and deploy it into an EJB Container without modification. This is all fine and dandy, but it still leaves it up to the EJB Container/Server providers to settle the difference.
+
+h2. The deployment-id is unique
+
+OpenEJB solves this with the OpenEJB-specific deployment id. By requiring that each bean deployed into OpenEJB has a unique name, we can guarantee that we are always refering to the right bean at all times. Futhermore, it allows you to deploy different versions of the same package several times in the same container system, each time giving the beans new deployment ids.
+
+h2. Using ejb-name as deployment-id anyway
+
+If you're lazy -- as any truly great programmer should be -- and don't want to type a deployment id for each bean every time you deploy a jar, you can use the -D option of the Deploy Tool. This will throw caution to the wind, and automatically assign the bean's ejb-name as the value of the bean's OpenEJB deployment id. This leaves up to you to guarantee that bean's ejb-name will be unique across all beans and jars in the container system. In other words, be very careful with the -D option!
+
+h1. How is it used?
+
+h2. In the container system
+
+In the container system, the deployment id is used to undex the bean in a system-wide registry. This registry is refered to on every call made in the container system. Being able to safely hash and cache bean information by id is a must. This stresses the importance of unique ids for every bean deployed in OpenEJB.
+
+h2. In the Local Server
+
+The Local (IntraVM) Server is an integral part of the container system and the two are, in many ways, inseparable. The Local Server takes care of all bean to bean and client to bean invocations made inside the virtual machine. For this reason, it often refered to as the IntraVM Server.
+
+For bean to bean communications, the Local Server must create a JNDI namespace (JNDI ENC) for each bean as defined by the bean's <env-entry>, <ejb-ref>, and <resource-ref> elements of the bean's ejb-jar.xml file. Every bean litterally gets its very own JNDI namespace. When a bean makes a JNDI call, the Local Server intercepts this call and uses the deployment id of the calling bean to retreive that bean's private JNDI namespace from the container system's index. The Local Server then carries out the lookup on that bean's namespace.
+
+All non-bean clients share one big global namespace. Since non-bean clients are not deployed and do not have a deployment descriptor like an ejb-jar.xml, the Local Server is unable to taylor a namespace for each non-bean client as it can for bean clients. The Local server cannot identify non-bean clients as they have no deployment id. All JNDI calls made by clients that the Local Server cannot identify go to the public, global namespace. The public, global JNDI namespace contains all beans and resources in the container system. name.
+
+Each bean is added to the public, global namespace using it's deployment id as its JNDI lookup. For example, if a bean had a deployment-id of "/my/bean/foo", a non-bean client could lookup that bean as follows.
+
+{code:title=MyAppClient.java}
+...
+Object bean = initialContext.lookup("/my/bean/Foo");
+...
+{code}
+
+If a bean in the container system made the above JNDI call, the Local Server would see the bean's identity (deployment id) hidden in the Thread, go get the bean's private JNDI namespace and finish the lookup on that. Since all names in bean's JNDI namespace are required start with "java:comp/env", the lookup would fail and the bean would receive a javax.naming.NameNotFoundException.
+
+In short...
+
+For beans:
+ - Each bean has it's own private, personalized JNDI namespace
+ - The names in it are the same names it uses in its ejb-jar.xml
+ - Beans can only access their private namespace, period
+
+For non-beans (everyone else):
+ - Non-bean clients share the public, global JNDI namespace
+ - The names in it are the deployment ids of all the beans
+ - Non-bean clients can only access the one global namespace
+
+h2. In the Remote Server
+
+The Remote Server has a public, global namespace just as the Local Server does. The difference being that the Remote Server only serves clients outside the container system and outside the virtual machine. So, all clients from the perspective of the Remote Server are non-bean clients. As a result, the Remote Server only has the one public, global JNDI namespace. Just as in the Local Server, the names in this namespacse consist of the deployment ids of the beans in the container system.
+
+Just as before, clients can lookup beans from the Remote Server using the bean's deployment id. For example, if a bean had a deployment-id of "/my/bean/foo", a client could lookup that bean as follows.
+
+{code:title=MyAppClient.java}
+...
+Object bean = initialContext.lookup("/my/bean/Foo");
+...
+{code}
+
+h2. In the CORBA Adapter
+
+The CORBA Adapter is separate than the Remote Server. It adapts the OpenEJB Container System and the Local Server into OpenORB as an embedded library. It provides users of OpenORB the ability to lookup and execute beans (EJBs) via the RMI-IIOP protocol. All the EJBHome and EJBObject interfaces of beans in OpenEJB are implemented by OpenORB as CORBA stubs and ties.
+
+The beans are exported into OpenORB's naming service by deployment id. So, just as with the Local Server and Remote Server, clients can lookup beans using the bean's deployment id. OpenORB has a JNDI implementation of their naming service, so lookups can be done just as before.
+
+{code:title=MyAppClient.java}
+...
+Object bean = initialContext.lookup("/my/bean/Foo");
+...
+{}
+
+CORBA clients can also access beans in OpenEJB as CORBA objects. These can be looked up from OpenORB's naming service (CosNaming) as follows.
+
+{code:title=MyCorbaAppClient.java}
+...
+String[] args = ...
+
+// The ORB and Object
+org.omg.CORBA.ORB orb = null;
+org.omg.CORBA.Object bean = null.
+
+// The Naming Service and Object Name
+org.omg.CosNaming.NamingContext context = null;
+org.omg.CosNaming.NameComponent[] name = null;
+
+// Get the ORB
+orb = org.omg.CORBA.ORB.init( args, null );
+
+// Get the Naming Service
+org.omg.CORBA.Object ref = null;
+ref = orb.resolve_initial_references("NameService");
+context = org.omg.CosNaming.NamingContextHelper.narrow( ref );
+
+// Get the Name as a component
+// Note: the string is the bean's deployment id
+name = new org.omg.CosNaming.NameComponent[ 1 ];
+name[0] = new org.omg.CosNaming.NameComponent("/my/bean/foo","");
+
+// Finally, get the bean as a CORBA object
+// Equvalent to an InitialContext.lookup("/my/bean/foo");
+bean = context.resolve( name );
+...
+{code}
+
+h1. What happens if there is a duplicate deployment ID?
+
+The deployment ID uniquely identifies the bean in the OpenEJB container system. Therefore, no two beans can share the same deployment ID.
+
+If a bean attempts to use a deployment ID that is already in use by another bean, the second bean and all beans in it's jar will not be loaded. In addition, the system will log a warning like the following one asking you to redeploy the jar and choose an different deployment ID for the bean.
+
+{panel:title=openejb.log}
+WARN : Jar C:\openejb\beans\fooEjbs.jar cannot be loaded. The
+Deployment ID "/my/bean/foo" is already in use. Please redeploy
+this jar and assign a different deployment ID to the bean with
+the ejb-name "FooBean".
+{panel}
+
+For example, the acmeEjbs.jar contains a bean with the ejb-name "DaffyDuckBean". The disneyEjbs.jar contains contains a bean with the ejb-name "DonaldDuckBean".
+
+We deploy the acmeEjbs.jar and give the "DaffyDuckBean" the deployment ID of "/my/favorite/duck". Sometime afterwards, we deploy the disneyEjbs.jar and assign the "DonaldDuckBean" the deployment ID "/my/favorite/duck", having forgotten that we already gave that unique ID to the "DaffyDuckBean" in the acmeEjbs.jar.
+
+When the container system is started, the system will begin loading all the beans one jar at a time. It will first load the acmeEjbs.jar and index each bean by deployment ID. But, when the system reaches the disneyEjbs.jar, it will discover that it cannot index the "DonaldDuckBean" using the deployment ID "/my/favorite/duck" because that index is already taken.
+
+The system cannot load the "DonaldDuckBean" and must also ignore the rest of the beans in the disneyEjbs.jar as they may need the "DonaldDuckBean" bean to function properly. The disneyEjbs.jar is skipped and the following warning is logged.
+
+{panel:title=openejb.log}
+WARN : Jar C:\openejb\beans\disneyEjbs.jar cannot be loaded. The
+Deployment ID "/my/favorite/duck" is already in use. Please redeploy
+this jar and assign a different deployment ID to the bean with
+the ejb-name "DonaldDuckBean".
+{panel}
\ No newline at end of file
Propchange: openejb/site/trunk/content/deployment-id.cwiki
------------------------------------------------------------------------------
svn:eol-style = native