Repository: tomee Updated Branches: refs/heads/master c5fca2f9c -> 63929301a
http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/common-persistenceprovider-properties.adoc ---------------------------------------------------------------------- diff --git a/docs/common-persistenceprovider-properties.adoc b/docs/common-persistenceprovider-properties.adoc new file mode 100644 index 0000000..53d0145 --- /dev/null +++ b/docs/common-persistenceprovider-properties.adoc @@ -0,0 +1,47 @@ +# Common PersistenceProvider properties +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +While not a definitive list, it +does help to show a side-by-side view of common properties used by the +various persistence providers out there. + +# TopLink + +.... +<properties> + + <!--http://www.oracle.com/technology/products/ias/toplink/JPA/essentials/toplink-jpa-extensions.html--> + <property name="toplink.ddl-generation" value="drop-and-create-tables"/> + <property name="toplink.logging.level" value="FINEST"/> + <property name="toplink.ddl-generation.output-mode" value="both"/> + <property name="toplink.target-server" value="pl.zsk.samples.ejbservice.OpenEJBServerPlatform"/> +</properties> +.... + +# OpenJPA + +.... +<properties> + <!--http://openjpa.apache.org/faq.html--> + <!-- does not create foreign keys, creates schema and deletes content of a database + (deleteTableContents - foreign keys are created twice???), use dropDB instead --> + <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema(foreignKeys=true,schemaAction='dropDB,add')"/> + <!--Resolves the problem with foreign key integrity - joined entities are persisted sometimes in wrong order??? (verify it)--> + <property name="openjpa.jdbc.SchemaFactory" value="native(foreignKeys=true)" /> + <!--Create foreign keys--> + <property name="openjpa.jdbc.MappingDefaults" value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/> + <property name="openjpa.Log" value="DefaultLevel=TRACE,SQL=TRACE" /> +</properties> +.... + +# Hibernate + +.... +<properties> + <property name="hibernate.hbm2ddl.auto" value="create-drop"/> + <property name="hibernate.transaction.manager_lookup_class" value="org.apache.openejb.hibernate.TransactionManagerLookup"/> +</properties> +.... http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/common-persistenceprovider-properties.md ---------------------------------------------------------------------- diff --git a/docs/common-persistenceprovider-properties.md b/docs/common-persistenceprovider-properties.md deleted file mode 100644 index 4445c3b..0000000 --- a/docs/common-persistenceprovider-properties.md +++ /dev/null @@ -1,47 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=Common PersistenceProvider properties -~~~~~~ -While not a definitive list, it does help to show a side-by-side view of -common properties used by the various persistence providers out there. - -<a name="CommonPersistenceProviderproperties-TopLink"></a> -# TopLink - - - <properties> - - <!--http://www.oracle.com/technology/products/ias/toplink/JPA/essentials/toplink-jpa-extensions.html--> - <property name="toplink.ddl-generation" value="drop-and-create-tables"/> - <property name="toplink.logging.level" value="FINEST"/> - <property name="toplink.ddl-generation.output-mode" value="both"/> - <property name="toplink.target-server" value="pl.zsk.samples.ejbservice.OpenEJBServerPlatform"/> - </properties> - - -<a name="CommonPersistenceProviderproperties-OpenJPA"></a> -# OpenJPA - - - <properties> - <!--http://openjpa.apache.org/faq.html--> - <!-- does not create foreign keys, creates schema and deletes content of a database - (deleteTableContents - foreign keys are created twice???), use dropDB instead --> - <property name="openjpa.jdbc.SynchronizeMappings" value="buildSchema(foreignKeys=true,schemaAction='dropDB,add')"/> - <!--Resolves the problem with foreign key integrity - joined entities are persisted sometimes in wrong order??? (verify it)--> - <property name="openjpa.jdbc.SchemaFactory" value="native(foreignKeys=true)" /> - <!--Create foreign keys--> - <property name="openjpa.jdbc.MappingDefaults" value="ForeignKeyDeleteAction=restrict, JoinForeignKeyDeleteAction=restrict"/> - <property name="openjpa.Log" value="DefaultLevel=TRACE,SQL=TRACE" /> - </properties> - - -<a name="CommonPersistenceProviderproperties-Hibernate"></a> -# Hibernate - - - <properties> - <property name="hibernate.hbm2ddl.auto" value="create-drop"/> - <property name="hibernate.transaction.manager_lookup_class" value="org.apache.openejb.hibernate.TransactionManagerLookup"/> - </properties> http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/comparison.adoc ---------------------------------------------------------------------- diff --git a/docs/comparison.adoc b/docs/comparison.adoc new file mode 100644 index 0000000..b985ea3 --- /dev/null +++ b/docs/comparison.adoc @@ -0,0 +1,231 @@ +# Comparison +:index-group: General Information +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +Apache OpenEJB and Apache TomEE are born from the same project and +community. They differ in two major ways, only one of them technical: + +* TomEE incorporates two additional projects; Tomcat and MyFaces +* TomEE, as a name, more easily implies the breadth of technologies +included + +Effectively, TomEE is a superset of OpenEJB. They share the same code +and TomEE grew out of OpenEJB. + +Note: this table is for TomEE 1.x, TomEE 7 comments are under it. + +Tomcat + +TomEE + +TomEE JAX-RS (~ Microprofile) + +TomEE+ + +TomEE PluME + +OpenEJB + +Java Servlets + +(/) + +(/) + +(/) + +(/) + +(/) + +Java ServerPages (JSP) + +(/) + +(/) + +(/) + +(/) + +(/) + +Java ServerFaces (JSF) + +(/) + +(/) + +(/) + +(/) + +Java Transaction API (JTA) + +(/) + +(/) + +(/) + +(/) + +(/) + +Java Persistence API (JPA) + +(/) + +(/) + +(/) + +(/) + +(/) + +Java Contexts and Dependency Injection (CDI) + +(/) + +(/) + +(/) + +(/) + +(/) + +Java Authentication and Authorization Service (JAAS) + +(/) + +(/) + +(/) + +(/) + +(/) + +Java Authorization Contract for Containers (JACC) + +(/) + +(/) + +(/) + +(/) + +(/) + +JavaMail API + +(/) + +(/) + +(/) + +(/) + +(/) + +Bean Validation + +(/) + +(/) + +(/) + +(/) + +(/) + +Enterprise JavaBeans + +(/) + +(/) + +(/) + +(/) + +(/) + +Java API for RESTful Web Services (JAX-RS) + +(/) + +(/) + +(/) + +(/) + +Java API for XML Web Services (JAX-WS) + +(/) + +(/) + +(/) + +Java EE Connector Architecture + +(/) + +(/) + +(/) + +Java Messaging Service (JMS) + +(/) + +(/) + +(/) + +EclipseLink + +(/) + +Mojarra + +(/) + +TomEE 7 targets JavaEE 7 and implements these specifications (in +parenthesis the distibution(s) containing it if not part of the basic +packages): + +* WebSocket JSR 356 +* JSON-P JSR 353 +* Servlet 3.1 JSR 340 +* JSF 2.2 JSR 344 +* EL 3.0 JSR 341 +* JSP 2.3 JSR 245 +* JSTL 1.2 JSR 52 +* JBatch (plus) JSR 352 +* Concurrency utilities for EE JSR 236 +* CDI 1.2, DI, Interceptors 1.2, Common Annotations JSR 346 + JSR 330 + +JSR 318 + JSR 250 +* Bean Validation 1.1 JSR 349 +* EJB 3.2 JSR 345 +* JavaEE Connector JSR 322 +* JPA 2.1 JSR 338 (WARNING: openjpa based distributions provide a JPA +2.0 runtime) +* JMS 2.0 JSR 343 (layer based on ActiveMQ 5 / JMS 1.1 for default +distributions) +* JTA 1.2 JSR 907 +* Javamail 1.4 (NOTE: EE 7 requires 1.5) +* JAX-RS 2.0 JSR 339 +* JAX-WS 2.2 JSR 224 +* JAXB 2.2 JSR 222 +* and more inherited from TomEE 1/JavaEE 6 http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/comparison.md ---------------------------------------------------------------------- diff --git a/docs/comparison.md b/docs/comparison.md deleted file mode 100644 index e841649..0000000 --- a/docs/comparison.md +++ /dev/null @@ -1,222 +0,0 @@ -index-group=General Information -type=page -status=published -title=Comparison -~~~~~~ - -Apache OpenEJB and Apache TomEE are born from the same project and community. They differ in two major ways, only one of them technical: - - - TomEE incorporates two additional projects; Tomcat and MyFaces - - TomEE, as a name, more easily implies the breadth of technologies included - -Effectively, TomEE is a superset of OpenEJB. They share the same code and TomEE grew out of OpenEJB. - -Note: this table is for TomEE 1.x, TomEE 7 comments are under it. - -<table class="mdtable"> -<tr> -<th></th> -<th>Tomcat</th> -<th>TomEE</th> -<th>TomEE JAX-RS (~ Microprofile)</th> -<th>TomEE+</th> -<th>TomEE PluME</th> -<th>OpenEJB</th> -</tr> - -<tr> -<td>Java Servlets</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td></td> -</tr> - -<tr> -<td>Java ServerPages (JSP)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td></td> -</tr> - -<tr> -<td>Java ServerFaces (JSF)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td></td> -</tr> - -<tr> -<td>Java Transaction API (JTA)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java Persistence API (JPA)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java Contexts and Dependency Injection (CDI)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java Authentication and Authorization Service (JAAS)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java Authorization Contract for Containers (JACC)</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>JavaMail API</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Bean Validation</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Enterprise JavaBeans</td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java API for RESTful Web Services (JAX-RS)</td> -<td></td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java API for XML Web Services (JAX-WS)</td> -<td></td> -<td></td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java EE Connector Architecture</td> -<td></td> -<td></td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>Java Messaging Service (JMS)</td> -<td></td> -<td></td> -<td></td> -<td>(/)</td> -<td>(/)</td> -<td>(/)</td> -</tr> - -<tr> -<td>EclipseLink</td> -<td></td> -<td></td> -<td></td> -<td></td> -<td>(/)</td> -<td></td> -</tr> - -<tr> -<td>Mojarra</td> -<td></td> -<td></td> -<td></td> -<td></td> -<td>(/)</td> -<td></td> -</tr> - -</table> - - -TomEE 7 targets JavaEE 7 and implements these specifications (in parenthesis the distibution(s) containing it if not part of the basic packages): - -* WebSocket JSR 356 -* JSON-P JSR 353 -* Servlet 3.1 JSR 340 -* JSF 2.2 JSR 344 -* EL 3.0 JSR 341 -* JSP 2.3 JSR 245 -* JSTL 1.2 JSR 52 -* JBatch (plus) JSR 352 -* Concurrency utilities for EE JSR 236 -* CDI 1.2, DI, Interceptors 1.2, Common Annotations JSR 346 + JSR 330 + JSR 318 + JSR 250 -* Bean Validation 1.1 JSR 349 -* EJB 3.2 JSR 345 -* JavaEE Connector JSR 322 -* JPA 2.1 JSR 338 (WARNING: openjpa based distributions provide a JPA 2.0 runtime) -* JMS 2.0 JSR 343 (layer based on ActiveMQ 5 / JMS 1.1 for default distributions) -* JTA 1.2 JSR 907 -* Javamail 1.4 (NOTE: EE 7 requires 1.5) -* JAX-RS 2.0 JSR 339 -* JAX-WS 2.2 JSR 224 -* JAXB 2.2 JSR 222 -* and more inherited from TomEE 1/JavaEE 6 http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/concepts.adoc ---------------------------------------------------------------------- diff --git a/docs/concepts.adoc b/docs/concepts.adoc new file mode 100644 index 0000000..d3374ad --- /dev/null +++ b/docs/concepts.adoc @@ -0,0 +1,83 @@ +# Concepts +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +OpenEJB was founded on the idea that it would be embedded into +third-party environments whom would likely already have three things: + +* their one "server" platform with existing clients and protocols +* their own way to configure their platform +* existing services like TransactionManager, Security, and Connector + +Thus the focus of OpenEJB was to create an EJB implementation that would +be easily embeddible, configurable, and customizable. + +Part of achieving that is a drive to be as simple as possible as to not +over-define and therefore restrict the ability to be embeddible, +configurable and customizable. Smaller third-party environments could +easily 'downscale' OpenEJB in their integrations by replacing standard +components with lighter implementations or removing them all together +and larger environments could 'upscale' OpenEJB by replacing and adding +heavier implementations of those standard components likely tailored to +their systems and infrastructure. + +Container and Server are mentioned in the EJB spec as being separate +things but are never defined formally. In our world Containers, which +implement the basic component contract and lifecycle of a bean are not +coupled to any particular Server, which has the job of providing a +naming service and providing a way for it's clients to reference and +invoke components (beans) hosted in Containers. Because Containers have +no dependence at all only Server, you can run OpenEJB without any Server +at all in an embedded environment for example without any work or any +extra overhead. Similarly you can add as many new Server components as +you want without ever having to modify any Containers. + +There is a very strong pluggability focus in OpenEJB as it was always +intended to be embedded and customized in other environments. As a +result all Containers are pluggable, isolated from each other, and no +one Container is bound to another Container and therefore removing or +adding a Container has no repercussions on the other Containers in the +system. TransactionManager, SecurityService and Connector also pluggable +and are services exposed to Containers. A Container may not be dependent +on specific implementations of those services. Service Providers define +what services they are offering (Container, Connector, Security, +Transaction, etc.) in a file they place in their jar called +service-jar.xml. + +The service-jar.xml should be placed not in the META-INF but somewhere +in your package hierarchy (ours is in +/org/apache/openejb/service-jar.xml) which allows the services in your +service-jar.xml to be referenced by name (such as +DefaultStatefulContainer) or more specifically by package and id (such +as org.apache.openejb#DefaultStatefulContainer). + +The same implementation of a service can be declared several times in a +service-jar.xml with different ids. This allows for you to setup several +several different profiles or pre-configured versions of the services +you provide each with a different name and different set of default +values for its properties. + +In your openejb.conf file when you declare Containers and Connectors, we +are actually hooking you up with Service Providers automatically. You +get what is in the org/apache/openejb/service-jar.xml by default, but +you are able to point specifically to a specific Service Provider by the +'provider' attribute on the Container, Connector, TransactionManager, +SecurityService, etc. elements of the openejb.conf file. When you +declare a service (Container, Connector, etc.) in your openejb.conf file +the properties you supply override the properties supplied by the +Service Provider, thus you only need to specify the properties you'd +like to change and can have your openejb.conf file as large or as small +as you would like it. The act of doing this can be thought of as +essentially instantiating the Service Provider and configuring that +instance for inclusion in the runtime system. + +For example Container(id=NoTimeoutStatefulContainer, +provider=DefaultStatefulContainer) could be declared with it's Timeout +property set to 0 for never, and a +Container(id=ShortTimeoutStatefulContainer, +provider=DefaultStatefulContainer) could be declared with it's Timeout +property set to 15 minutes. Both would be instances of the +DefaultStatefulContainer Service Provider which is a service of type +Container. http://git-wip-us.apache.org/repos/asf/tomee/blob/d380ec18/docs/concepts.md ---------------------------------------------------------------------- diff --git a/docs/concepts.md b/docs/concepts.md deleted file mode 100644 index 370992d..0000000 --- a/docs/concepts.md +++ /dev/null @@ -1,79 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=Concepts -~~~~~~ -OpenEJB was founded on the idea that it would be embedded into third-party -environments whom would likely already have three things: - - - their one "server" platform with existing clients and protocols - - their own way to configure their platform - - existing services like TransactionManager, Security, and Connector - -Thus the focus of OpenEJB was to create an EJB implementation that would be -easily embeddible, configurable, and customizable. - -Part of achieving that is a drive to be as simple as possible as to not -over-define and therefore restrict the ability to be embeddible, -configurable and customizable. Smaller third-party environments could -easily 'downscale' OpenEJB in their integrations by replacing standard -components with lighter implementations or removing them all together and -larger environments could 'upscale' OpenEJB by replacing and adding heavier -implementations of those standard components likely tailored to their -systems and infrastructure. - -Container and Server are mentioned in the EJB spec as being separate things -but are never defined formally. In our world Containers, which implement -the basic component contract and lifecycle of a bean are not coupled to any -particular Server, which has the job of providing a naming service and -providing a way for it's clients to reference and invoke components (beans) -hosted in Containers. Because Containers have no dependence at all only -Server, you can run OpenEJB without any Server at all in an embedded -environment for example without any work or any extra overhead. Similarly -you can add as many new Server components as you want without ever having -to modify any Containers. - -There is a very strong pluggability focus in OpenEJB as it was always -intended to be embedded and customized in other environments. As a result -all Containers are pluggable, isolated from each other, and no one -Container is bound to another Container and therefore removing or adding a -Container has no repercussions on the other Containers in the system. -TransactionManager, SecurityService and Connector also pluggable and are -services exposed to Containers. A Container may not be dependent on -specific implementations of those services. Service Providers define what -services they are offering (Container, Connector, Security, Transaction, -etc.) in a file they place in their jar called service-jar.xml. - -The service-jar.xml should be placed not in the META-INF but somewhere in -your package hierarchy (ours is in /org/apache/openejb/service-jar.xml) -which allows the services in your service-jar.xml to be referenced by name -(such as DefaultStatefulContainer) or more specifically by package and id -(such as org.apache.openejb#DefaultStatefulContainer). - -The same implementation of a service can be declared several times in a -service-jar.xml with different ids. This allows for you to setup several -several different profiles or pre-configured versions of the services you -provide each with a different name and different set of default values for -its properties. - -In your openejb.conf file when you declare Containers and Connectors, we -are actually hooking you up with Service Providers automatically. You get -what is in the org/apache/openejb/service-jar.xml by default, but you are -able to point specifically to a specific Service Provider by the 'provider' -attribute on the Container, Connector, TransactionManager, SecurityService, -etc. elements of the openejb.conf file. When you declare a service -(Container, Connector, etc.) in your openejb.conf file the properties you -supply override the properties supplied by the Service Provider, thus you -only need to specify the properties you'd like to change and can have your -openejb.conf file as large or as small as you would like it. The act of -doing this can be thought of as essentially instantiating the Service -Provider and configuring that instance for inclusion in the runtime system. - -For example Container(id=NoTimeoutStatefulContainer, -provider=DefaultStatefulContainer) could be declared with it's Timeout -property set to 0 for never, and a -Container(id=ShortTimeoutStatefulContainer, -provider=DefaultStatefulContainer) could be declared with it's Timeout -property set to 15 minutes. Both would be instances of the -DefaultStatefulContainer Service Provider which is a service of type -Container.
