You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by jl...@apache.org on 2018/12/06 08:53:05 UTC
[20/44] tomee git commit: TOMEE-2316 Convert Markdown files to
Asciidoc in the docs folder - 8
TOMEE-2316 Convert Markdown files to Asciidoc in the docs folder - 8
Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/68720016
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/68720016
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/68720016
Branch: refs/heads/master
Commit: 68720016fa1ecc08890ac7241cb82dab9e424d1c
Parents: 388460f
Author: Carlos Chacin <cc...@gmail.com>
Authored: Wed Dec 5 22:07:24 2018 -0800
Committer: Carlos Chacin <cc...@gmail.com>
Committed: Wed Dec 5 22:07:24 2018 -0800
----------------------------------------------------------------------
docs/messagedrivencontainer-config.adoc | 85 +++
docs/messagedrivencontainer-config.md | 67 --
docs/multicast-discovery.adoc | 91 +++
docs/multicast-discovery.md | 83 ---
docs/multiple-business-interface-hazzards.adoc | 200 ++++++
docs/multiple-business-interface-hazzards.md | 202 ------
docs/multipoint-considerations.adoc | 32 +
docs/multipoint-considerations.md | 30 -
docs/multipoint-discovery.adoc | 85 +++
docs/multipoint-discovery.md | 75 --
docs/multipoint-recommendations.adoc | 153 ++++
docs/multipoint-recommendations.md | 141 ----
docs/multipulse-discovery.adoc | 109 +++
docs/multipulse-discovery.md | 94 ---
docs/new-in-openejb-3.0.adoc | 154 +++++
docs/new-in-openejb-3.0.md | 179 -----
docs/openejb-3.adoc | 69 ++
docs/openejb-3.md | 72 --
docs/openejb-binaries.adoc | 32 +
docs/openejb-binaries.md | 27 -
docs/openejb-eclipse-plugin.adoc | 22 +
docs/openejb-eclipse-plugin.md | 22 -
docs/openejb-jsr-107-integration.adoc | 24 +
docs/openejb-jsr-107-integration.md | 25 -
docs/openejb.xml.adoc | 96 +++
docs/openejb.xml.md | 96 ---
docs/openjpa.adoc | 125 ++++
docs/openjpa.md | 113 ---
docs/orb-config.adoc | 40 ++
docs/orb-config.md | 26 -
docs/persistence-context.adoc | 59 ++
docs/persistence-context.md | 57 --
docs/persistence-unit-ref.adoc | 91 +++
docs/persistence-unit-ref.md | 91 ---
docs/properties-listing.adoc | 729 ++++++++++++++++++++
docs/properties-listing.md | 94 ---
docs/properties-tool.adoc | 219 ++++++
docs/properties-tool.md | 216 ------
docs/property-overriding.adoc | 64 ++
docs/property-overriding.md | 65 --
docs/provisioning.adoc | 96 +++
docs/provisioning.md | 78 ---
docs/proxyfactory-config.adoc | 42 ++
docs/proxyfactory-config.md | 26 -
44 files changed, 2617 insertions(+), 1879 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/messagedrivencontainer-config.adoc
----------------------------------------------------------------------
diff --git a/docs/messagedrivencontainer-config.adoc b/docs/messagedrivencontainer-config.adoc
new file mode 100644
index 0000000..10a9109
--- /dev/null
+++ b/docs/messagedrivencontainer-config.adoc
@@ -0,0 +1,85 @@
+# MessageDrivenContainer Configuration
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+A MessageDrivenContainer can be declared via xml in the
+`<tomee-home>/conf/tomee.xml` file or in a `WEB-INF/resources.xml` file
+using a declaration like the following. All properties in the element
+body are optional.
+
+....
+<Container id="myMessageDrivenContainer" type="MESSAGE">
+ activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec
+ instanceLimit = 10
+ messageListenerInterface = javax.jms.MessageListener
+ resourceAdapter = Default JMS Resource Adapter
+</Container>
+....
+
+Alternatively, a MessageDrivenContainer can be declared via properties
+in the `<tomee-home>/conf/system.properties` file or via Java
+VirtualMachine `-D` properties. The properties can also be used when
+embedding TomEE via the `javax.ejb.embeddable.EJBContainer` API or
+`InitialContext`
+
+....
+myMessageDrivenContainer = new://Container?type=MESSAGE
+myMessageDrivenContainer.activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec
+myMessageDrivenContainer.instanceLimit = 10
+myMessageDrivenContainer.messageListenerInterface = javax.jms.MessageListener
+myMessageDrivenContainer.resourceAdapter = Default JMS Resource Adapter
+....
+
+Properties and xml can be mixed. Properties will override the xml
+allowing for easy configuration change without the need for $\{} style
+variable substitution. Properties are not case sensitive. If a property
+is specified that is not supported by the declared
+MessageDrivenContainer a warning will be logged. If a
+MessageDrivenContainer is needed by the application and one is not
+declared, TomEE will create one dynamically using default settings.
+Multiple MessageDrivenContainer declarations are allowed. # Supported
+Properties
+
+Property
+
+Type
+
+Default
+
+Description
+
+activationSpecClass
+
+String
+
+org.apache.activemq.ra.ActiveMQActivationSpec
+
+Specifies the activation spec class
+
+instanceLimit
+
+int
+
+10
+
+Specifies the maximum number of bean instances that are allowed to exist
+for each MDB deployment.
+
+messageListenerInterface
+
+String
+
+javax.jms.MessageListener
+
+Specifies the message listener interface handled by this container
+
+resourceAdapter
+
+String
+
+Default JMS Resource Adapter
+
+The resource adapter delivers messages to the container
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/messagedrivencontainer-config.md
----------------------------------------------------------------------
diff --git a/docs/messagedrivencontainer-config.md b/docs/messagedrivencontainer-config.md
deleted file mode 100644
index 3362a4f..0000000
--- a/docs/messagedrivencontainer-config.md
+++ /dev/null
@@ -1,67 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=MessageDrivenContainer Configuration
-~~~~~~
-
-
-A MessageDrivenContainer can be declared via xml in the `<tomee-home>/conf/tomee.xml` file or in a `WEB-INF/resources.xml` file using a declaration like the following. All properties in the element body are optional.
-
- <Container id="myMessageDrivenContainer" type="MESSAGE">
- activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec
- instanceLimit = 10
- messageListenerInterface = javax.jms.MessageListener
- resourceAdapter = Default JMS Resource Adapter
- </Container>
-
-Alternatively, a MessageDrivenContainer can be declared via properties in the `<tomee-home>/conf/system.properties` file or via Java VirtualMachine `-D` properties. The properties can also be used when embedding TomEE via the `javax.ejb.embeddable.EJBContainer` API or `InitialContext`
-
- myMessageDrivenContainer = new://Container?type=MESSAGE
- myMessageDrivenContainer.activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec
- myMessageDrivenContainer.instanceLimit = 10
- myMessageDrivenContainer.messageListenerInterface = javax.jms.MessageListener
- myMessageDrivenContainer.resourceAdapter = Default JMS Resource Adapter
-
-Properties and xml can be mixed. Properties will override the xml allowing for easy configuration change without the need for ${} style variable substitution. Properties are not case sensitive. If a property is specified that is not supported by the declared MessageDrivenContainer a warning will be logged. If a MessageDrivenContainer is needed by the application and one is not declared, TomEE will create one dynamically using default settings. Multiple MessageDrivenContainer declarations are allowed.
-# Supported Properties
-<table class="mdtable">
-<tr>
-<th>Property</th>
-<th>Type</th>
-<th>Default</th>
-<th>Description</th>
-</tr>
-<tr>
- <td>activationSpecClass</td>
- <td>String</td>
- <td>org.apache.activemq.ra.ActiveMQActivationSpec</td>
- <td>
-Specifies the activation spec class
-</td>
-</tr>
-<tr>
- <td>instanceLimit</td>
- <td>int</td>
- <td>10</td>
- <td>
-Specifies the maximum number of bean instances that are
-allowed to exist for each MDB deployment.
-</td>
-</tr>
-<tr>
- <td>messageListenerInterface</td>
- <td>String</td>
- <td>javax.jms.MessageListener</td>
- <td>
-Specifies the message listener interface handled by this container
-</td>
-</tr>
-<tr>
- <td>resourceAdapter</td>
- <td>String</td>
- <td>Default JMS Resource Adapter</td>
- <td>
-The resource adapter delivers messages to the container
-</td>
-</tr>
-</table>
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multicast-discovery.adoc
----------------------------------------------------------------------
diff --git a/docs/multicast-discovery.adoc b/docs/multicast-discovery.adoc
new file mode 100644
index 0000000..6fd67f4
--- /dev/null
+++ b/docs/multicast-discovery.adoc
@@ -0,0 +1,91 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: Multicast (UDP) Discovery
+
+
+Multicast is the preferred way to broadcast the heartbeat on the
+network. The simple technique of broadcasting a non-changing service URI
+on the network has specific advantages to multicast. The URI itself is
+essentially stateless and there is no "i'm alive" URI or an "i'm dead"
+URI.
+
+In this way the issues with UDP being unordered and unreliable melt away
+as state is no longer a concern and packet sizes are always small.
+Complicated libraries that ride atop UDP and attempt to offer
+reliability (retransmission) and ordering on UDP can be avoided. As well
+the advantages UDP has over TCP are retained as there are no java layers
+attempting to force UDP communication to be more TCP-like. The simple
+design means UDP/Multicast is only used for discovery and from there on
+out critical information is transmitted over TCP/IP which is obviously
+going to do a better job at ensuring reliability and ordering.
+
+== Server Configuration
+
+When you boot the server there should be a `conf/multicast.properties`
+file containing:
+
+....
+server = org.apache.openejb.server.discovery.MulticastDiscoveryAgent
+bind = 239.255.2.3
+port = 6142
+disabled = true
+group = default
+....
+
+Just need to enable that by setting `disabled=false`. All of the above
+settings except `server` can be changed. The `port` and `bind` must be
+valid for general multicast/udp network communication.
+
+The `group` setting can be changed to further group servers that may use
+the same multicast channel. As shown below the client also has a `group`
+setting which can be used to select an appropriate server from the
+multicast channel.
+
+== Multicast Client
+
+The multicast functionality is not just for servers to find each other
+in a cluster, it can also be used for EJB clients to discover a server.
+A special `multicast://` URL can be used in the `InitialContext`
+properties to signify that multicast should be used to seed the
+connection process. Such as:
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY,
+"org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "multicast://239.255.2.3:6142?group=default");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+The URL has optional query parameters such as `schemes` and `group` and
+`timeout` which allow you to zero in on a particular type of service of
+a particular cluster group as well as set how long you are willing to
+wait in the discovery process till finally giving up. The first matching
+service that it sees "flowing" around on the UDP stream is the one it
+picks and sticks to for that and subsequent requests, ensuring UDP is
+only used when there are no other servers to talk to.
+
+Note that EJB clients do not need to use multicast to find a server. If
+the client knows the URL of a server in the cluster, it may use it and
+connect directly to that server, at which point that server will share
+the full list of its peers.
+
+== Multicast Servers with TCP Clients
+
+Note that clients do not need to use multicast to communicate with
+servers. Servers can use multicast to discover each other, but clients
+are still free to connect to servers in the network using the server's
+TCP address.
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "ejbd://192.168.1.30:4201");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+When the client connects, the server will send the URLs of all the
+servers in the group and failover will take place normally.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multicast-discovery.md
----------------------------------------------------------------------
diff --git a/docs/multicast-discovery.md b/docs/multicast-discovery.md
deleted file mode 100644
index 10f1692..0000000
--- a/docs/multicast-discovery.md
+++ /dev/null
@@ -1,83 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=Multicast (UDP) Discovery
-~~~~~~
-
-Multicast is the preferred way to broadcast the heartbeat on the network.
-The simple technique of broadcasting a non-changing service URI on the
-network has specific advantages to multicast. The URI itself is
-essentially stateless and there is no "i'm alive" URI or an "i'm dead" URI.
-
-In this way the issues with UDP being unordered and unreliable melt away as
-state is no longer a concern and packet sizes are always small.
-Complicated libraries that ride atop UDP and attempt to offer reliability
-(retransmission) and ordering on UDP can be avoided. As well the
-advantages UDP has over TCP are retained as there are no java layers
-attempting to force UDP communication to be more TCP-like. The simple
-design means UDP/Multicast is only used for discovery and from there on out
-critical information is transmitted over TCP/IP which is obviously going to
-do a better job at ensuring reliability and ordering.
-
-# Server Configuration
-
-When you boot the server there should be a `conf/multicast.properties` file
-containing:
-
-
- server = org.apache.openejb.server.discovery.MulticastDiscoveryAgent
- bind = 239.255.2.3
- port = 6142
- disabled = true
- group = default
-
-
-Just need to enable that by setting `disabled=false`. All of the above
-settings except `server` can be changed. The `port` and `bind` must
-be valid for general multicast/udp network communication.
-
-The `group` setting can be changed to further group servers that may use
-the same multicast channel. As shown below the client also has a `group`
-setting which can be used to select an appropriate server from the
-multicast channel.
-
-# Multicast Client
-
-The multicast functionality is not just for servers to find each other in a
-cluster, it can also be used for EJB clients to discover a server. A
-special `multicast://` URL can be used in the `InitialContext` properties to
-signify that multicast should be used to seed the connection process. Such
-as:
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY,
- "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "multicast://239.255.2.3:6142?group=default");
- InitialContext remoteContext = new InitialContext(p);
-
-The URL has optional query parameters such as `schemes` and `group` and
-`timeout` which allow you to zero in on a particular type of service of a
-particular cluster group as well as set how long you are willing to wait in
-the discovery process till finally giving up. The first matching service
-that it sees "flowing" around on the UDP stream is the one it picks and
-sticks to for that and subsequent requests, ensuring UDP is only used when
-there are no other servers to talk to.
-
-Note that EJB clients do not need to use multicast to find a server. If
-the client knows the URL of a server in the cluster, it may use it and
-connect directly to that server, at which point that server will share the
-full list of its peers.
-
-# Multicast Servers with TCP Clients
-
-Note that clients do not need to use multicast to communicate with servers.
-Servers can use multicast to discover each other, but clients are still
-free to connect to servers in the network using the server's TCP address.
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "ejbd://192.168.1.30:4201");
- InitialContext remoteContext = new InitialContext(p);
-
-When the client connects, the server will send the URLs of all the servers
-in the group and failover will take place normally.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multiple-business-interface-hazzards.adoc
----------------------------------------------------------------------
diff --git a/docs/multiple-business-interface-hazzards.adoc b/docs/multiple-business-interface-hazzards.adoc
new file mode 100644
index 0000000..caeae43
--- /dev/null
+++ b/docs/multiple-business-interface-hazzards.adoc
@@ -0,0 +1,200 @@
+# Multiple Business Interface Hazzards
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+# UndeclaredThrowableException
+
+When two java interfaces are implemented by a proxy and those two
+interfaces declare the _same method_ but with _different throws clauses_
+some very nasty side effects happen, namely you loose the ability to
+throw any checked exceptions that are not in the throws clause of both
+methods.
+
+....
+import junit.framework.TestCase;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.Method;
+import java.lang.reflect.UndeclaredThrowableException;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public class ExceptionTest extends TestCase {
+
+ public void test() throws Exception {
+ ClassLoader classLoader = this.getClass().getClassLoader();
+ Class[]
+....
+
+interfaces = new Class[]\{One.class, Two.class};
+
+....
+ InvocationHandler h = new TestInvocationHandler();
+
+ Object proxy =
+....
+
+java.lang.reflect.Proxy.newProxyInstance(classLoader, interfaces, h);
+
+....
+ One one = (One) proxy;
+
+ try {
+ one.run(new CommonException());
+ } catch (CommonException e) {
+ // this will work
+ } catch(UndeclaredThrowableException u) {
+ Throwable t = u.getCause();
+ fail("Undeclared: "+t);
+ } catch(Throwable t){
+ fail("Caught: "+t);
+ }
+
+ try {
+ one.run(new OneException());
+ } catch (OneException e) {
+ } catch(UndeclaredThrowableException u) {
+ Throwable t = u.getCause();
+ fail("Undeclared: "+t); // This will always be the code that
+....
+
+executes } catch(Throwable t)\{ fail("Caught: "+t); }
+
+....
+ Two two = (Two) proxy;
+ try {
+ two.run(new CommonException());
+ } catch (TwoException e) {
+ } catch(UndeclaredThrowableException u) {
+ Throwable t = u.getCause();
+ fail("Undeclared: "+t); // This will always be the code that
+....
+
+executes } catch(Throwable t)\{ fail("Caught: "+t); }
+
+....
+ }
+
+ public static class CommonException extends Exception {
+ public CommonException() {
+ }
+ }
+
+ public static interface One {
+ void run(Object o) throws OneException, CommonException;
+ }
+
+ public static class OneException extends Exception {
+ public OneException() {
+ }
+ }
+
+ public static interface Two {
+ void run(Object o) throws TwoException, CommonException;
+ }
+
+ public static class TwoException extends Exception {
+ public TwoException() {
+ }
+ }
+
+ private static class TestInvocationHandler implements InvocationHandler
+....
+
+\{ public Object invoke(Object proxy, Method method, Object[] args)
+throws Throwable \{ throw (Throwable)args[0] ; } } }
+
+# IllegalArgumentException
+
+This one is less of a runtime problem as doing this will cause things to
+fail up front. When two java interfaces are implemented by a proxy and
+those two interfaces declare the _same method_ but with _different
+return types_ the VM proxy code will refuse to create a proxy at all.
+Take this code example:
+
+....
+import junit.framework.TestCase;
+
+import java.lang.reflect.InvocationHandler;
+import java.lang.reflect.Method;
+
+/**
+ * @version $Rev$ $Date$
+ */
+public class ReturnTest extends TestCase {
+
+ public void test() throws Exception {
+ ClassLoader classLoader = this.getClass().getClassLoader();
+ Class[]
+....
+
+interfaces = new Class[]\{ReturnTest.One.class, ReturnTest.Two.class};
+
+....
+ InvocationHandler h = new ReturnTest.TestInvocationHandler();
+
+ Object proxy =
+....
+
+java.lang.reflect.Proxy.newProxyInstance(classLoader, interfaces, h);
+
+....
+ One one = (One) proxy;
+ try {
+ Object object = one.run(new ThingOne());
+ } catch (Throwable t) {
+ fail("Caught: " + t);
+ }
+
+ Two two = (Two) proxy;
+ try {
+ Object object = two.run(new ThingTwo());
+ } catch (Throwable t) {
+ fail("Caught: " + t);
+ }
+
+ }
+
+ public static interface One {
+ ThingOne run(Object o);
+ }
+
+ public static class ThingOne {
+ }
+
+ public static interface Two {
+ ThingTwo run(Object o);
+ }
+
+ public static class ThingTwo {
+ }
+
+ private static class TestInvocationHandler implements InvocationHandler
+....
+
+\{ public Object invoke(Object proxy, Method method, Object[] args)
+throws Throwable \{ return args[0] ; } } }
+
+Running this code will result in the following exception:
+
+....
+java.lang.IllegalArgumentException: methods with same signature
+....
+
+run(java.lang.Object) but incompatible return types: [class
+ReturnTestlatexmath:[$ThingOne, class ReturnTest$]ThingTwo] at
+sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:669) at
+sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:420) at
+sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306) at
+java.lang.reflect.Proxy.getProxyClass(Proxy.java:501) at
+java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581) at
+ReturnTest.test(ReturnTest.java:36) at
+sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
+sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
+at
+sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
+at
+com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multiple-business-interface-hazzards.md
----------------------------------------------------------------------
diff --git a/docs/multiple-business-interface-hazzards.md b/docs/multiple-business-interface-hazzards.md
deleted file mode 100644
index c6558d7..0000000
--- a/docs/multiple-business-interface-hazzards.md
+++ /dev/null
@@ -1,202 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=Multiple Business Interface Hazzards
-~~~~~~
-<a name="MultipleBusinessInterfaceHazzards-UndeclaredThrowableException"></a>
-# UndeclaredThrowableException
-
-When two java interfaces are implemented by a proxy and those two
-interfaces declare the *same method* but with *different throws clauses*
-some very nasty side effects happen, namely you loose the ability to throw
-any checked exceptions that are not in the throws clause of both methods.
-
-
- import junit.framework.TestCase;
-
- import java.lang.reflect.InvocationHandler;
- import java.lang.reflect.Method;
- import java.lang.reflect.UndeclaredThrowableException;
-
- /**
- * @version $Rev$ $Date$
- */
- public class ExceptionTest extends TestCase {
-
- public void test() throws Exception {
- ClassLoader classLoader = this.getClass().getClassLoader();
- Class[]
- interfaces = new Class[]{One.class, Two.class};
-
- InvocationHandler h = new TestInvocationHandler();
-
- Object proxy =
-java.lang.reflect.Proxy.newProxyInstance(classLoader, interfaces, h);
-
- One one = (One) proxy;
-
- try {
- one.run(new CommonException());
- } catch (CommonException e) {
- // this will work
- } catch(UndeclaredThrowableException u) {
- Throwable t = u.getCause();
- fail("Undeclared: "+t);
- } catch(Throwable t){
- fail("Caught: "+t);
- }
-
- try {
- one.run(new OneException());
- } catch (OneException e) {
- } catch(UndeclaredThrowableException u) {
- Throwable t = u.getCause();
- fail("Undeclared: "+t); // This will always be the code that
-executes
- } catch(Throwable t){
- fail("Caught: "+t);
- }
-
- Two two = (Two) proxy;
- try {
- two.run(new CommonException());
- } catch (TwoException e) {
- } catch(UndeclaredThrowableException u) {
- Throwable t = u.getCause();
- fail("Undeclared: "+t); // This will always be the code that
-executes
- } catch(Throwable t){
- fail("Caught: "+t);
- }
-
- }
-
- public static class CommonException extends Exception {
- public CommonException() {
- }
- }
-
- public static interface One {
- void run(Object o) throws OneException, CommonException;
- }
-
- public static class OneException extends Exception {
- public OneException() {
- }
- }
-
- public static interface Two {
- void run(Object o) throws TwoException, CommonException;
- }
-
- public static class TwoException extends Exception {
- public TwoException() {
- }
- }
-
- private static class TestInvocationHandler implements InvocationHandler
-{
- public Object invoke(Object proxy, Method method, Object[]
- args) throws Throwable {
- throw (Throwable)args[0]
-;
- }
- }
- }
-
-
-
-<a name="MultipleBusinessInterfaceHazzards-IllegalArgumentException"></a>
-# IllegalArgumentException
-
-This one is less of a runtime problem as doing this will cause things to
-fail up front. When two java interfaces are implemented by a proxy and
-those two interfaces declare the *same method* but with *different return
-types* the VM proxy code will refuse to create a proxy at all. Take this
-code example:
-
-
-
- import junit.framework.TestCase;
-
- import java.lang.reflect.InvocationHandler;
- import java.lang.reflect.Method;
-
- /**
- * @version $Rev$ $Date$
- */
- public class ReturnTest extends TestCase {
-
- public void test() throws Exception {
- ClassLoader classLoader = this.getClass().getClassLoader();
- Class[]
- interfaces = new Class[]{ReturnTest.One.class, ReturnTest.Two.class};
-
- InvocationHandler h = new ReturnTest.TestInvocationHandler();
-
- Object proxy =
-java.lang.reflect.Proxy.newProxyInstance(classLoader, interfaces, h);
-
- One one = (One) proxy;
- try {
- Object object = one.run(new ThingOne());
- } catch (Throwable t) {
- fail("Caught: " + t);
- }
-
- Two two = (Two) proxy;
- try {
- Object object = two.run(new ThingTwo());
- } catch (Throwable t) {
- fail("Caught: " + t);
- }
-
- }
-
- public static interface One {
- ThingOne run(Object o);
- }
-
- public static class ThingOne {
- }
-
- public static interface Two {
- ThingTwo run(Object o);
- }
-
- public static class ThingTwo {
- }
-
- private static class TestInvocationHandler implements InvocationHandler
-{
- public Object invoke(Object proxy, Method method, Object[]
- args) throws Throwable {
- return args[0]
-;
- }
- }
- }
-
-
-Running this code will result in the following exception:
-
-
- java.lang.IllegalArgumentException: methods with same signature
-run(java.lang.Object) but incompatible return types: [class ReturnTest$ThingOne, class ReturnTest$ThingTwo]
- at
-sun.misc.ProxyGenerator.checkReturnTypes(ProxyGenerator.java:669)
- at
-sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:420)
- at
-sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306)
- at java.lang.reflect.Proxy.getProxyClass(Proxy.java:501)
- at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
- at ReturnTest.test(ReturnTest.java:36)
- at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
- at
-sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
- at
-sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
- at
-com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
-
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-considerations.adoc
----------------------------------------------------------------------
diff --git a/docs/multipoint-considerations.adoc b/docs/multipoint-considerations.adoc
new file mode 100644
index 0000000..24d3644
--- /dev/null
+++ b/docs/multipoint-considerations.adoc
@@ -0,0 +1,32 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: Multipoint Considerations
+
+
+== Network size
+
+The general disadvantage of this topology is the number of connections
+required. The number of connections for the network of servers is equal
+to `(n * n - n) / 2`, where n is the number of servers. For example,
+with 5 servers you need 10 connections, with 10 servers you need 45
+connections, and with 50 servers you need 1225 connections. This is of
+course the number of connections across the entire network, each
+individual server only needs `n - 1` connections.
+
+The handling of these sockets is all asynchronous Java NIO code which
+allows the server to handle many connections (all of them) with one
+thread. From a pure threading perspective, the option is extremely
+efficient with just one thread to listen and broadcast to many peers.
+
+== Double connect
+
+It is possible in this process that two servers learn of each other at
+the same time and each attempts to connect to the other simultaneously,
+resulting in two connections between the same two servers. When this
+happens both servers will detect the extra connection and one of the
+connections will be dropped and one will be kept. In practice this race
+condition rarely happens and can be avoided almost entirely by fanning
+out server startup by as little as 100 milliseconds.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-considerations.md
----------------------------------------------------------------------
diff --git a/docs/multipoint-considerations.md b/docs/multipoint-considerations.md
deleted file mode 100644
index 63ebf11..0000000
--- a/docs/multipoint-considerations.md
+++ /dev/null
@@ -1,30 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=Multipoint Considerations
-~~~~~~
-
-# Network size
-
-The general disadvantage of this topology is the number of connections
-required. The number of connections for the network of servers is equal to
-`(n * n - n) / 2`, where n is the number of servers. For example, with 5
-servers you need 10 connections, with 10 servers you need 45 connections,
-and with 50 servers you need 1225 connections. This is of course the
-number of connections across the entire network, each individual server
-only needs `n - 1` connections.
-
-The handling of these sockets is all asynchronous Java NIO code which
-allows the server to handle many connections (all of them) with one thread.
- From a pure threading perspective, the option is extremely efficient with
-just one thread to listen and broadcast to many peers.
-
-# Double connect
-
-It is possible in this process that two servers learn of each other at the
-same time and each attempts to connect to the other simultaneously,
-resulting in two connections between the same two servers. When this
-happens both servers will detect the extra connection and one of the
-connections will be dropped and one will be kept. In practice this race
-condition rarely happens and can be avoided almost entirely by fanning out
-server startup by as little as 100 milliseconds.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-discovery.adoc
----------------------------------------------------------------------
diff --git a/docs/multipoint-discovery.adoc b/docs/multipoint-discovery.adoc
new file mode 100644
index 0000000..a8a4daa
--- /dev/null
+++ b/docs/multipoint-discovery.adoc
@@ -0,0 +1,85 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: Multipoint (TCP) Discovery
+
+
+As TCP has no real broadcast functionality to speak of, communication of
+who is in the network is achieved by each server having a physical
+connection to each other server in the network.
+
+To join the network, the server must be configured to know the address
+of at least one server in the network and connect to it. When it does
+both servers will exchange the full list of all the other servers each
+knows about. Each server will then connect to any new servers they've
+just learned about and repeat the processes with those new servers. The
+end result is that everyone has a direct connection to everyone 100% of
+the time, hence the made-up term "multipoint" to describe this situation
+of each server having multiple point-to-point connections which create a
+fully connected graph.
+
+On the client side things are similar. It needs to know the address of
+at least one server in the network and be able to connect to it. When it
+does it will get the full (and dynamically maintained) list of every
+server in the network. The client doesn't connect to each of those
+servers immediately, but rather consults the list in the event of a
+failover, using it to decide who to connect to next.
+
+The entire process is essentially the art of using a statically
+maintained list to bootstrap getting the more valuable dynamically
+maintained list.
+
+== Server Configuration
+
+In the server this list can be specified via the
+`conf/multipoint.properties` file like so:
+
+....
+server = org.apache.openejb.server.discovery.MultipointDiscoveryAgent
+bind = 127.0.0.1
+port = 4212
+disabled = false
+initialServers = 192.168.1.20:4212, 192.168.1.30:4212, 192.168.1.40:4212
+....
+
+The above configuration shows the server has an `port` `4212` open for
+connections by other servers for multipoint communication. The
+`initialServers` list should be a comma separated list of other similar
+servers on the network. Only one of the servers listed is required to be
+running when this server starts up -- it is not required to list all
+servers in the network.
+
+== Client Configuration
+
+Configuration in the client is similar, but note that EJB clients do not
+participate directly in multipoint communication and do *not* connect to
+the multipoint port. The server list is simply a list of the regular
+`ejbd://` urls that a client normally uses to connect to a server.
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "failover:ejbd://192.168.1.20:4201,ejbd://192.168.1.30:4201");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+Failover can work entirely driven by the server, the client does not
+need to be configured to participate. A client can connect as usual to
+the server.
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "ejbd://192.168.1.20:4201");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+If the server at `192.168.1.20:4201` supports failover, so will the
+client.
+
+In this scenario the list of servers used for failover is supplied
+entirely by the server at `192.168.1.20:4201`. The server could have
+aquired the list via multicast or multipoint (or both), but this detail
+is not visible to the client.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-discovery.md
----------------------------------------------------------------------
diff --git a/docs/multipoint-discovery.md b/docs/multipoint-discovery.md
deleted file mode 100644
index bb93b13..0000000
--- a/docs/multipoint-discovery.md
+++ /dev/null
@@ -1,75 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=Multipoint (TCP) Discovery
-~~~~~~
-
-As TCP has no real broadcast functionality to speak of, communication of
-who is in the network is achieved by each server having a physical
-connection to each other server in the network.
-
-To join the network, the server must be configured to know the address of
-at least one server in the network and connect to it. When it does both
-servers will exchange the full list of all the other servers each knows
-about. Each server will then connect to any new servers they've just
-learned about and repeat the processes with those new servers. The end
-result is that everyone has a direct connection to everyone 100% of the
-time, hence the made-up term "multipoint" to describe this situation of
-each server having multiple point-to-point connections which create a fully
-connected graph.
-
-On the client side things are similar. It needs to know the address of at
-least one server in the network and be able to connect to it. When it does
-it will get the full (and dynamically maintained) list of every server in
-the network. The client doesn't connect to each of those servers
-immediately, but rather consults the list in the event of a failover, using
-it to decide who to connect to next.
-
-The entire process is essentially the art of using a statically maintained
-list to bootstrap getting the more valuable dynamically maintained list.
-
-# Server Configuration
-
-In the server this list can be specified via the
-`conf/multipoint.properties` file like so:
-
- server = org.apache.openejb.server.discovery.MultipointDiscoveryAgent
- bind = 127.0.0.1
- port = 4212
- disabled = false
- initialServers = 192.168.1.20:4212, 192.168.1.30:4212, 192.168.1.40:4212
-
-
-The above configuration shows the server has an `port` `4212` open for
-connections by other servers for multipoint communication. The
-`initialServers` list should be a comma separated list of other similar
-servers on the network. Only one of the servers listed is required to be
-running when this server starts up -- it is not required to list all
-servers in the network.
-
-# Client Configuration
-
-Configuration in the client is similar, but note that EJB clients do not
-participate directly in multipoint communication and do **not** connect to
-the multipoint port. The server list is simply a list of the regular
-`ejbd://` urls that a client normally uses to connect to a server.
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "failover:ejbd://192.168.1.20:4201,ejbd://192.168.1.30:4201");
- InitialContext remoteContext = new InitialContext(p);
-
-Failover can work entirely driven by the server, the client does not need
-to be configured to participate. A client can connect as usual to the server.
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "ejbd://192.168.1.20:4201");
- InitialContext remoteContext = new InitialContext(p);
-
-If the server at `192.168.1.20:4201` supports failover, so will the client.
-
-In this scenario the list of servers used for failover is supplied entirely
-by the server at `192.168.1.20:4201`. The server could have aquired the list
-via multicast or multipoint (or both), but this detail is not visible to the
-client.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-recommendations.adoc
----------------------------------------------------------------------
diff --git a/docs/multipoint-recommendations.adoc b/docs/multipoint-recommendations.adoc
new file mode 100644
index 0000000..9764479
--- /dev/null
+++ b/docs/multipoint-recommendations.adoc
@@ -0,0 +1,153 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: Multipoint Recommendations
+
+
+As mentioned the `initialServers` is only used for bootstrapping the
+multipoint network. Once running, all servers will dynamically establish
+direct connections with each other and there is no single point of
+failure.
+
+However to ensure that the bootstrapping process can occur successfully,
+the `initialServers` property of the `conf/multipoint.properties` file
+must be set carefully and with a specific server start order in mind.
+Each server consults its `initialServers` list exactly once in the
+bootstrapping phase at startup, after that time connections are made
+dynamically.
+
+This means that at least one of the servers listed in `initialServers`
+must already be running when the server starts or the server might never
+become introduced and connected to all the other servers in the network.
+
+== Failed scenario background
+
+As an example of a failed scenario, imagine there are three servers;
+`server1`, `server2`, `server3`. They are setup only to point to the
+server in front of them making a chain:
+
+* server1; `initialServers = server2`
+* server2; `initialServers = server3`
+* server3; `initialServers = *<blank>*`
+
+Which is essentially `server1` -> `server2` -> `server3`. This scenario
+could work, but they servers would have to be started in exactly the
+opposite order:
+
+[arabic]
+. `server3` starts
+. `server2` starts
+[arabic]
+.. _static:_ connect to `server3`
+. `server1` starts
+[arabic]
+.. _static:_ connect to `server2`
+.. _dynamic:_ connect to `server3`
+
+At this point all servers would be fully connected. But the above setup
+is flawed and could easily fail. The first flaw is `server3` lists
+nothing in its `initialServers` list, so if it were restarted it would
+leave the multipoint network and not know how to get back in.
+
+The second flaw is if you started them in any other order, you would
+also not get a fully connected multipoint network. Say the servers were
+started in "front" order:
+
+[arabic]
+. `server1` starts
+[arabic]
+.. _static:_ connect to `server2` - failed, `server2` not started.
+. `server2` starts
+[arabic]
+.. _static:_ connect to `server3` - failed, `server3` not started.
+. `server3` starts
+[arabic]
+.. no connection attempts, initialServers list is empty.
+
+After startup completes, all servers will be completely isolated and
+failover will not work. The described setup is weaker than it needs to
+be. Listing just one server means the listed server is a potential point
+of weakness. As a matter of trivia, it is interesting to point out that
+you could bring a fourth server online temporarily that lists all three
+servers. Once it makes the introductions and all servers learn of each
+other, you could shut it down again.
+
+The above setup is easily fixable via better configuration. If `server3`
+listed both `server1` and `server2` in its initialServers list, rather
+than listing nothing at all, then all servers would fully discover each
+other regardless of startup order; assuming all three servers did
+eventually start.
+
+== Bootstrapping Three Servers or Less
+
+In a three sever scenario, we recommend simply having all three servers
+list all three servers.
+
+* server1/conf/multipoint.properties
+** `initialServers = server1, server2, server3`
+* server2/conf/multipoint.properties
+** `initialServers = server1, server2, server3`
+* server3/conf/multipoint.properties
+** `initialServers = server1, server2, server3`
+
+There's no harm to a server listing itself. It gives you one clean list
+to maintain and it will work even if you decide not to start one of the
+three servers.
+
+== Bootstrapping Four Servers or More
+
+In a scenario of four or more, we recommend picking at least to servers
+and focus on always keeping at least one of them running. Lets refer to
+them as "root" servers for simplicity sake.
+
+* server1/conf/multipoint.properties
+** `initialServers = server2`
+* server2/conf/multipoint.properties
+** `initialServers = server1`
+
+Root `server1` would list root `server2` so they would always be linked
+to each other regardless of start order or if one of them went down.
+`Server1` could be shutdown and reconnect on startup to the full
+multipoint network through `server2`, and vice versa.
+
+All other servers would simply list the root servers (`server1`,
+`server2`) in their initialServers list.
+
+* server3/conf/multipoint.properties
+** `initialServers = server1, server2`
+* server4/conf/multipoint.properties
+** `initialServers = server1, server2`
+* serverN/conf/multipoint.properties
+** `initialServers = server1, server2`
+
+As long as at least one root server (`server1` or `server2`) was
+running, you can bring other servers on and offline at will and always
+have a fully connected graph.
+
+Of course all servers once running and connected will have a full list
+of all other servers in the network, so if at any time the "root"
+servers weren't around to make initial introductions to new servers it
+would be no trouble. It's possible to reconfigure new servers to point
+at any other server in the network as all servers will have the full
+list. So these "root" servers are no real point of failure in function,
+but only of convenience.
+
+== Setting initialServers overrides
+
+Always remember that any property in a
+`conf/<server-service>.properties` file can be overridden on the command
+line or via system properties. So it is possible easily set the
+`initialServers` list in startup scripts.
+
+A bash example might look something like:
+
+....
+!/bin/bash
+
+OPENEJB_HOME=/opt/openejb-3.1.3
+INITIAL_LIST=$(cat /some/shared/directory/our_initial_servers.txt)
+
+$OPENEJB_HOME/bin/openejb start -Dmultipoint.initialServers=$INITIAL_LIST
+....
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipoint-recommendations.md
----------------------------------------------------------------------
diff --git a/docs/multipoint-recommendations.md b/docs/multipoint-recommendations.md
deleted file mode 100644
index dfcb573..0000000
--- a/docs/multipoint-recommendations.md
+++ /dev/null
@@ -1,141 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=Multipoint Recommendations
-~~~~~~
-
-As mentioned the `initialServers` is only used for bootstrapping
-the multipoint network. Once running, all servers will dynamically
-establish direct connections with each other and there is no single point
-of failure.
-
-However to ensure that the bootstrapping process can occur successfully,
-the `initialServers` property of the `conf/multipoint.properties` file
-must be set carefully and with a specific server start order in mind. Each
-server consults its `initialServers` list exactly once in the
-bootstrapping phase at startup, after that time connections are made
-dynamically.
-
-This means that at least one of the servers listed in `initialServers`
-must already be running when the server starts or the server might never
-become introduced and connected to all the other servers in the network.
-
-# Failed scenario <small>background</small>
-
-As an example of a failed scenario, imagine there are three servers;
-`server1`, `server2`, `server3`. They are setup only to point to the server in
-front of them making a chain:
-
-* server1; `initialServers = server2`
-* server2; `initialServers = server3`
-* server3; `initialServers = *<blank>*`
-
-Which is essentially `server1` -> `server2` -> `server3`. This scenario could
-work, but they servers would have to be started in exactly the opposite
-order:
-
-1. `server3` starts
-1. `server2` starts
- 1. *static:* connect to `server3`
-1. `server1` starts
- 1. *static:* connect to `server2`
- 1. *dynamic:* connect to `server3`
-
-At this point all servers would be fully connected. But the above setup is
-flawed and could easily fail. The first flaw is `server3` lists nothing in
-its `initialServers` list, so if it were restarted it would leave the
-multipoint network and not know how to get back in.
-
-The second flaw is if you started them in any other order, you would also
-not get a fully connected multipoint network. Say the servers were started
-in "front" order:
-
-1. `server1` starts
- 1. *static:* connect to `server2` - failed, `server2` not started.
-1. `server2` starts
- 1. *static:* connect to `server3` - failed, `server3` not started.
-1. `server3` starts
- 1. no connection attempts, initialServers list is empty.
-
-After startup completes, all servers will be completely isolated and
-failover will not work. The described setup is weaker than it needs to be.
-Listing just one server means the listed server is a potential point of
-weakness. As a matter of trivia, it is interesting to point out that you
-could bring a fourth server online temporarily that lists all three
-servers. Once it makes the introductions and all servers learn of each
-other, you could shut it down again.
-
-The above setup is easily fixable via better configuration. If `server3`
-listed both `server1` and `server2` in its initialServers list, rather than
-listing nothing at all, then all servers would fully discover each other
-regardless of startup order; assuming all three servers did eventually
-start.
-
-# Bootstrapping Three Servers or Less
-
-In a three sever scenario, we recommend simply having all three servers
-list all three servers.
-
-* server1/conf/multipoint.properties
- * `initialServers = server1, server2, server3`
-* server2/conf/multipoint.properties
- * `initialServers = server1, server2, server3`
-* server3/conf/multipoint.properties
- * `initialServers = server1, server2, server3`
-
-There's no harm to a server listing itself. It gives you one clean list to
-maintain and it will work even if you decide not to start one of the three
-servers.
-
-# Bootstrapping Four Servers or More
-
-In a scenario of four or more, we recommend picking at least to servers and
-focus on always keeping at least one of them running. Lets refer to them
-as "root" servers for simplicity sake.
-
-* server1/conf/multipoint.properties
- * `initialServers = server2`
-* server2/conf/multipoint.properties
- * `initialServers = server1`
-
-Root `server1` would list root `server2` so they would always be linked to each
-other regardless of start order or if one of them went down. `Server1` could
-be shutdown and reconnect on startup to the full multipoint network through
-`server2`, and vice versa.
-
-All other servers would simply list the root servers (`server1`, `server2`) in
-their initialServers list.
-
-* server3/conf/multipoint.properties
- * `initialServers = server1, server2`
-* server4/conf/multipoint.properties
- * `initialServers = server1, server2`
-* serverN/conf/multipoint.properties
- * `initialServers = server1, server2`
-
-As long as at least one root server (`server1` or `server2`) was running, you
-can bring other servers on and offline at will and always have a fully
-connected graph.
-
-Of course all servers once running and connected will have a full list of
-all other servers in the network, so if at any time the "root" servers
-weren't around to make initial introductions to new servers it would be no
-trouble. It's possible to reconfigure new servers to point at any other
-server in the network as all servers will have the full list. So these
-"root" servers are no real point of failure in function, but only of
-convenience.
-
-# Setting initialServers <small>overrides</small>
-
-Always remember that any property in a `conf/<server-service>.properties`
-file can be overridden on the command line or via system properties. So it
-is possible easily set the `initialServers` list in startup scripts.
-
-A bash example might look something like:
-
- !/bin/bash
-
- OPENEJB_HOME=/opt/openejb-3.1.3
- INITIAL_LIST=$(cat /some/shared/directory/our_initial_servers.txt)
-
- $OPENEJB_HOME/bin/openejb start -Dmultipoint.initialServers=$INITIAL_LIST
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipulse-discovery.adoc
----------------------------------------------------------------------
diff --git a/docs/multipulse-discovery.adoc b/docs/multipulse-discovery.adoc
new file mode 100644
index 0000000..63d6518
--- /dev/null
+++ b/docs/multipulse-discovery.adoc
@@ -0,0 +1,109 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: MultiPulse (UDP) Discovery
+
+
+MultiPulse is an alternative multicast lookup that does not use a
+regular heartbeat. Instead, servers listen for a multicast request
+packet (a pulse) to which a response is then sent. Multicast network
+traffic is effectively reduced to an absolute minimum.
+
+MultiPulse is only useful in network scenarios where both client and
+server can be configured to send multicast UDP packets.
+
+== Server Configuration
+
+After you boot the server for the first time the default configuration
+will create the file `conf/conf.d/multipulse.properties` containing:
+
+....
+server = org.apache.openejb.server.discovery.MulticastPulseAgent
+bind = 239.255.2.3
+port = 6142
+disabled = true
+group = default
+....
+
+You just need to enable the agent by setting `disabled = false`. It is
+advisable to disable multicast in the `multicast.properties file`, or at
+least to use a different bind address or port should you wish to use
+both.
+
+All of the above settings except `server` can be modified as required.
+The `port` and `bind` must be valid for general multicast/udp network
+communication.
+
+The `group` setting can be changed to further group/cluster servers that
+may use the same multicast channel. As shown below the client also has
+an optional `group` setting which can be used to select an appropriate
+server cluster from the multicast channel (See MultiPulse Client).
+
+The next step is to ensure that the advertised services are configured
+for discovery. Edit the `ejbd.properties` file (and any other enabled
+services such as http, etc.) and ensure that the `discovery` option is
+set to a value that remote clients will be able to resolve.
+
+....
+server = org.apache.openejb.server.ejbd.EjbServer
+bind = 0.0.0.0
+port = 4201
+disabled = false
+threads = 20
+discovery = ejb:ejbd://{bind}:{port}
+....
+
+NOTE: If either `0.0.0.0` (IPv4) or `[::]` (IPv6) wildcard bind
+addresses are used then the server will actually broadcast all of it's
+known public hosts to clients. Clients will then cycle though and
+attempt to connect to the provided hosts until successful.
+
+If `localhost` is used then only clients on the same physical machine
+will actually 'see' the server response.
+
+== MultiPulse Client
+
+The multipulse functionality is not just for servers to find each other
+in a cluster, it can also be used for EJB clients to discover a server.
+A special `multipulse://` URL can be used in the `InitialContext`
+properties to signify that multipulse should be used to seed the
+connection process. Such as:
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "multipulse://239.255.2.3:6142?group=default&timeout=250");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+The URL has optional query parameters such as `schemes` and `group` and
+`timeout` which allow you to zero in on a particular type of service of
+a particular cluster group as well as set how long you are willing to
+wait in the discovery process till finally giving up. The first matching
+service that it sees "flowing" around on the UDP stream is the one it
+picks and sticks to for that and subsequent requests, ensuring UDP is
+only used when there are no other servers to talk to.
+
+Note that EJB clients do not need to use multipulse to find a server. If
+the client knows the URL of a server in the cluster, it may use it and
+connect directly to that server, at which point that server will share
+the full list of its peers.
+
+== Multicast Servers with TCP Clients
+
+Note that clients do not need to use multipulse to communicate with
+servers. Servers can use multicast to discover each other, but clients
+are still free to connect to servers in the network using the server's
+TCP address.
+
+....
+Properties p = new Properties();
+p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put(Context.PROVIDER_URL, "ejbd://192.168.1.30:4201");
+InitialContext remoteContext = new InitialContext(p);
+....
+
+When the client connects, the server will send the URLs of all the
+servers in the group and failover will take place normally.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/multipulse-discovery.md
----------------------------------------------------------------------
diff --git a/docs/multipulse-discovery.md b/docs/multipulse-discovery.md
deleted file mode 100644
index 087803d..0000000
--- a/docs/multipulse-discovery.md
+++ /dev/null
@@ -1,94 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=MultiPulse (UDP) Discovery
-~~~~~~
-
-MultiPulse is an alternative multicast lookup that does not use a regular heartbeat.
-Instead, servers listen for a multicast request packet (a pulse) to which a response
-is then sent. Multicast network traffic is effectively reduced to an absolute minimum.
-
-MultiPulse is only useful in network scenarios where both client and server can be
-configured to send multicast UDP packets.
-
-# Server Configuration
-
-After you boot the server for the first time the default configuration will create the
-file `conf/conf.d/multipulse.properties` containing:
-
- server = org.apache.openejb.server.discovery.MulticastPulseAgent
- bind = 239.255.2.3
- port = 6142
- disabled = true
- group = default
-
-You just need to enable the agent by setting `disabled = false`. It is advisable to
-disable multicast in the `multicast.properties file`, or at least to use a different
-bind address or port should you wish to use both.
-
-All of the above settings except `server` can be modified as required.
-The `port` and `bind` must be valid for general multicast/udp network communication.
-
-The `group` setting can be changed to further group/cluster servers that may use
-the same multicast channel. As shown below the client also has an optional `group`
-setting which can be used to select an appropriate server cluster from the multicast
-channel (See MultiPulse Client).
-
-The next step is to ensure that the advertised services are configured for discovery.
-Edit the `ejbd.properties` file (and any other enabled services such as http, etc.) and
-ensure that the `discovery` option is set to a value that remote clients will be able
-to resolve.
-
- server = org.apache.openejb.server.ejbd.EjbServer
- bind = 0.0.0.0
- port = 4201
- disabled = false
- threads = 20
- discovery = ejb:ejbd://{bind}:{port}
-
-NOTE: If either `0.0.0.0` (IPv4) or `[::]` (IPv6) wildcard bind addresses are used then the
-server will actually broadcast all of it's known public hosts to clients. Clients will then
-cycle though and attempt to connect to the provided hosts until successful.
-
-If `localhost` is used then only clients on the same physical machine will actually 'see' the
-server response.
-
-# MultiPulse Client
-
-The multipulse functionality is not just for servers to find each other in a
-cluster, it can also be used for EJB clients to discover a server. A
-special `multipulse://` URL can be used in the `InitialContext` properties to
-signify that multipulse should be used to seed the connection process. Such
-as:
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "multipulse://239.255.2.3:6142?group=default&timeout=250");
- InitialContext remoteContext = new InitialContext(p);
-
-The URL has optional query parameters such as `schemes` and `group` and
-`timeout` which allow you to zero in on a particular type of service of a
-particular cluster group as well as set how long you are willing to wait in
-the discovery process till finally giving up. The first matching service
-that it sees "flowing" around on the UDP stream is the one it picks and
-sticks to for that and subsequent requests, ensuring UDP is only used when
-there are no other servers to talk to.
-
-Note that EJB clients do not need to use multipulse to find a server. If
-the client knows the URL of a server in the cluster, it may use it and
-connect directly to that server, at which point that server will share the
-full list of its peers.
-
-# Multicast Servers with TCP Clients
-
-Note that clients do not need to use multipulse to communicate with servers.
-Servers can use multicast to discover each other, but clients are still
-free to connect to servers in the network using the server's TCP address.
-
- Properties p = new Properties();
- p.put(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put(Context.PROVIDER_URL, "ejbd://192.168.1.30:4201");
- InitialContext remoteContext = new InitialContext(p);
-
-When the client connects, the server will send the URLs of all the servers
-in the group and failover will take place normally.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/new-in-openejb-3.0.adoc
----------------------------------------------------------------------
diff --git a/docs/new-in-openejb-3.0.adoc b/docs/new-in-openejb-3.0.adoc
new file mode 100644
index 0000000..f5d871f
--- /dev/null
+++ b/docs/new-in-openejb-3.0.adoc
@@ -0,0 +1,154 @@
+:jbake-title: New in OpenEJB 3.0
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+# EJB 3.0
+
+OpenEJB 3.0 supports the EJB 3.0 specification as well as the prior EJB
+2.1, EJB 2.0, and EJB 1.1. New features in EJB 3.0 include:
+
+* Annotations instead of xml
+* No home interfaces
+* Business Interfaces
+* Dependency Injection
+* Intercpetors
+* Java Persistence API
+* Service Locator (ala SessionContext.lookup)
+* POJO-style beans
+
+EJB 2.x features since OpenEJB 1.0 also include: - MessageDriven Beans -
+Container-Managed Persistence (CMP) 2.0 - Timers
+
+The two aspects of EJB that OpenEJB does not yet support are: - Web
+Services (JAX-WS, JAX-RPC) - CORBA
+
+JAX-WS and CORBA support will be added in future releases. Support for
+the JAX-RPC API is not a planned feature.
+
+# Extensions to EJB 3.0
+
+== CMP via JPA
+
+Our CMP implementation is a thin layer over the new Java Persistence API
+(JPA). This means when you deploy an old style CMP 1.1 or CMP 2.1 bean
+it is internally converted and ran as a JPA bean. This makes it possible
+to use both CMP and JPA in the same application without any coherence
+issues that can come from using two competing persistence technologies
+against the same data. Everything is ultimately JPA in the end.
+
+== Extended Dependency Injection
+
+Dependency Injection in EJB 3.0 via @Resource is largely limited to
+objects provided by the container, such as DataSources, JMS Topics and
+Queues. It is possible for you to supply your own configuration
+information for injection, but standard rules allow for only data of
+type String, Character, Boolean, Integer, Short, Long, Double, Float and
+Byte. If you needed a URL, for example, you'd have to have it injected
+as a String then convert it yourself to a URL. This is just plain silly
+as the conversion of Strings to other basic data types has existed in
+JavaBeans long before Enterprise JavaBeans existed.
+
+OpenEJB 3.0 supports injection of any data type for which you can supply
+a JavaBeans PropertyEditor. We include several built-in PropertyEditors
+already such as Date, InetAddress, Class, File, URL, URI, Map, List and
+more.
+
+....
+import java.net.URI;
+import java.io.File;
+import java.util.Date;
+
+@Stateful
+public class MyBean {
+ @Resource URI blog;
+ @Resource Date birthday;
+ @Resource File homeDirectory;
+}
+....
+
+== The META-INF/env-entries.properties
+
+Along the lines of injection, one of the last remaining things in EJB 3
+that people need an ejb-jar.xml file for is to supply the value of
+env-entries. Env Entries are the source of data for all user supplied
+data injected into your bean; the afore mentioned String, Boolean,
+Integer, etc. This is a very big burden as each env-entry is going to
+cost you 5 lines of xml and the complication of having to figure out how
+to add you bean declaration in xml as an override of an existing bean
+and not accidentally as a new bean. All this can be very painful when
+all you want is to supply the value of a few @Resource String fields in
+you bean class.
+
+To fix this, OpenEJB supports the idea of a
+META-INF/env-entries.properties file where we will look for the value of
+things that need injection that are not container controlled resources
+(i.e. datasources and things of that nature). You can configure you ejbs
+via a properties file and skip the need for an ejb-jar.xml and it's 5
+lines per property madness.
+
+....
+blog = http://acme.org/myblog
+birthday = locale=en_US style=MEDIUM Mar 1, 1954
+homeDirectory = /home/esmith/
+....
+
+== Support for GlassFish descriptors
+
+Unit testing EJBs with OpenEJB is a major feature and draw for people,
+even for people who may still use other app servers for final deployment
+such as Geronimo or GlassFish. The descriptor format for Geronimo is
+natively understood by OpenEJB as OpenEJB is the EJB Container provider
+for Geronimo. However, OpenEJB also supports the GlassFish descriptors
+so people using GlassFish as their final server can still use OpenEJB
+for testing EJBs via plain JUnit tests in their build and only have one
+set of vendor descriptors to maintain.
+
+== JavaEE 5 EAR and Application Client support
+
+JavaEE 5 EARs and Application Clients can be deployed in addition to ejb
+jars. EAR support is limited to ejbs, application clients, and
+libraries; WAR files and RAR files will be ignored. Per the JavaEE 5
+spec, the META-INF/application.xml and META-INF/application-client.xml
+files are optional.
+
+== Application Validation for EJB 3.0
+
+Incorrect usage of various new aspects of EJB 3.0 are checked for and
+reported during the deployment process preventing strange errors and
+failures.
+
+As usual validation failures (non-compliant issues with your
+application) are printed out in complier-style "all-at-once" output
+allowing you to see and fix all your issues in one go. For example, if
+you have 10 @PersistenceContext annotations that reference an invalid
+persistence unit, you get all 10 errors on the _first_ deploy rather
+than one failure on the first deploy with 9 more failed deployments to
+go.
+
+Validation output comes in three levels. The most verbose level will
+tell you in detail what you did wrong, what the options are, and what to
+do next... even including valid code and annotation usage tailored to
+your app that you can copy and paste into your application. Very ideal
+for beginners and people using OpenEJB in a classroom setting.
+
+== Most configurable JNDI names ever
+
+# General Improvements
+
+== Online Deployment ## Security Service ## Connection Pooling ##
+Configuration Overriding ## Flexible JNDI Name Formatting ## Cleaner
+Embedding ## Tomcat 6 Support ## Business locals remotable
+
+If you want to make business local interfaces remotable, you can set
+this property:
+
+....
+ openejb.remotable.businessLocals=true
+....
+
+Then you can lookup your business local interfaces from remote clients.
+
+You'd still have to ensure that the you pass back and forth is
+serializable.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/new-in-openejb-3.0.md
----------------------------------------------------------------------
diff --git a/docs/new-in-openejb-3.0.md b/docs/new-in-openejb-3.0.md
deleted file mode 100644
index 3c568ab..0000000
--- a/docs/new-in-openejb-3.0.md
+++ /dev/null
@@ -1,179 +0,0 @@
-title= New in OpenEJB 3.0
-type=page
-status=published
-~~~~~~
-
-<a name="NewinOpenEJB3.0-EJB3.0"></a>
-# EJB 3.0
-
-OpenEJB 3.0 supports the EJB 3.0 specification as well as the prior EJB
-2.1, EJB 2.0, and EJB 1.1. New features in EJB 3.0 include:
-
- - Annotations instead of xml
- - No home interfaces
- - Business Interfaces
- - Dependency Injection
- - Intercpetors
- - Java Persistence API
- - Service Locator (ala SessionContext.lookup)
- - POJO-style beans
-
-EJB 2.x features since OpenEJB 1.0 also include:
- - MessageDriven Beans
- - Container-Managed Persistence (CMP) 2.0
- - Timers
-
-The two aspects of EJB that OpenEJB does not yet support are:
- - Web Services (JAX-WS, JAX-RPC)
- - CORBA
-
-JAX-WS and CORBA support will be added in future releases. Support for the
-JAX-RPC API is not a planned feature.
-
-<a name="NewinOpenEJB3.0-ExtensionstoEJB3.0"></a>
-# Extensions to EJB 3.0
-
-<a name="NewinOpenEJB3.0-CMPviaJPA"></a>
-## CMP via JPA
-
-Our CMP implementation is a thin layer over the new Java Persistence API
-(JPA). This means when you deploy an old style CMP 1.1 or CMP 2.1 bean it
-is internally converted and ran as a JPA bean. This makes it possible to
-use both CMP and JPA in the same application without any coherence issues
-that can come from using two competing persistence technologies against the
-same data. Everything is ultimately JPA in the end.
-
-<a name="NewinOpenEJB3.0-ExtendedDependencyInjection"></a>
-## Extended Dependency Injection
-
-Dependency Injection in EJB 3.0 via @Resource is largely limited to objects
-provided by the container, such as DataSources, JMS Topics and Queues. It
-is possible for you to supply your own configuration information for
-injection, but standard rules allow for only data of type String,
-Character, Boolean, Integer, Short, Long, Double, Float and Byte. If you
-needed a URL, for example, you'd have to have it injected as a String then
-convert it yourself to a URL. This is just plain silly as the conversion
-of Strings to other basic data types has existed in JavaBeans long before
-Enterprise JavaBeans existed.
-
-OpenEJB 3.0 supports injection of any data type for which you can supply a
-JavaBeans PropertyEditor. We include several built-in PropertyEditors
-already such as Date, InetAddress, Class, File, URL, URI, Map, List and
-more.
-
-
- import java.net.URI;
- import java.io.File;
- import java.util.Date;
-
- @Stateful
- public class MyBean {
- @Resource URI blog;
- @Resource Date birthday;
- @Resource File homeDirectory;
- }
-
-
-<a name="NewinOpenEJB3.0-TheMETA-INF/env-entries.properties"></a>
-## The META-INF/env-entries.properties
-
-Along the lines of injection, one of the last remaining things in EJB 3
-that people need an ejb-jar.xml file for is to supply the value of
-env-entries. Env Entries are the source of data for all user supplied data
-injected into your bean; the afore mentioned String, Boolean, Integer, etc.
- This is a very big burden as each env-entry is going to cost you 5 lines
-of xml and the complication of having to figure out how to add you bean
-declaration in xml as an override of an existing bean and not accidentally
-as a new bean. All this can be very painful when all you want is to supply
-the value of a few @Resource String fields in you bean class.
-
-To fix this, OpenEJB supports the idea of a META-INF/env-entries.properties
-file where we will look for the value of things that need injection that
-are not container controlled resources (i.e. datasources and things of that
-nature). You can configure you ejbs via a properties file and skip the
-need for an ejb-jar.xml and it's 5 lines per property madness.
-
-
- blog = http://acme.org/myblog
- birthday = locale=en_US style=MEDIUM Mar 1, 1954
- homeDirectory = /home/esmith/
-
-
-<a name="NewinOpenEJB3.0-SupportforGlassFishdescriptors"></a>
-## Support for GlassFish descriptors
-
-Unit testing EJBs with OpenEJB is a major feature and draw for people, even
-for people who may still use other app servers for final deployment such as
-Geronimo or GlassFish. The descriptor format for Geronimo is natively
-understood by OpenEJB as OpenEJB is the EJB Container provider for
-Geronimo. However, OpenEJB also supports the GlassFish descriptors so
-people using GlassFish as their final server can still use OpenEJB for
-testing EJBs via plain JUnit tests in their build and only have one set of
-vendor descriptors to maintain.
-
-<a name="NewinOpenEJB3.0-JavaEE5EARandApplicationClientsupport"></a>
-## JavaEE 5 EAR and Application Client support
-
-JavaEE 5 EARs and Application Clients can be deployed in addition to ejb
-jars. EAR support is limited to ejbs, application clients, and libraries;
-WAR files and RAR files will be ignored. Per the JavaEE 5 spec, the
-META-INF/application.xml and META-INF/application-client.xml files are
-optional.
-
-<a name="NewinOpenEJB3.0-ApplicationValidationforEJB3.0"></a>
-## Application Validation for EJB 3.0
-
-Incorrect usage of various new aspects of EJB 3.0 are checked for and
-reported during the deployment process preventing strange errors and
-failures.
-
-As usual validation failures (non-compliant issues with your application)
-are printed out in complier-style "all-at-once" output allowing you to see
-and fix all your issues in one go. For example, if you have 10
-@PersistenceContext annotations that reference an invalid persistence unit,
-you get all 10 errors on the *first* deploy rather than one failure on the
-first deploy with 9 more failed deployments to go.
-
-Validation output comes in three levels. The most verbose level will tell
-you in detail what you did wrong, what the options are, and what to do
-next... even including valid code and annotation usage tailored to your app
-that you can copy and paste into your application. Very ideal for
-beginners and people using OpenEJB in a classroom setting.
-
-<a name="NewinOpenEJB3.0-MostconfigurableJNDInamesever"></a>
-## Most configurable JNDI names ever
-
-<a name="NewinOpenEJB3.0-GeneralImprovements"></a>
-# General Improvements
-
-<a name="NewinOpenEJB3.0-OnlineDeployment"></a>
-## Online Deployment
-<a name="NewinOpenEJB3.0-SecurityService"></a>
-## Security Service
-<a name="NewinOpenEJB3.0-ConnectionPooling"></a>
-## Connection Pooling
-<a name="NewinOpenEJB3.0-ConfigurationOverriding"></a>
-## Configuration Overriding
-<a name="NewinOpenEJB3.0-FlexibleJNDINameFormatting"></a>
-## Flexible JNDI Name Formatting
-<a name="NewinOpenEJB3.0-CleanerEmbedding"></a>
-## Cleaner Embedding
-<a name="NewinOpenEJB3.0-Tomcat6Support"></a>
-## Tomcat 6 Support
-<a name="NewinOpenEJB3.0-Businesslocalsremotable"></a>
-## Business locals remotable
-
-If you want to make business local interfaces remotable, you can set this
-property:
-
- openejb.remotable.businessLocals=true
-
-Then you can lookup your business local interfaces from remote clients.
-
-You'd still have to ensure that the you pass back and forth is
-serializable.
-
-
-
-
-
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-3.adoc
----------------------------------------------------------------------
diff --git a/docs/openejb-3.adoc b/docs/openejb-3.adoc
new file mode 100644
index 0000000..260bbb4
--- /dev/null
+++ b/docs/openejb-3.adoc
@@ -0,0 +1,69 @@
+# OpenEJB 3
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+# Past, Present, and Future
+
+The goal of OpenEJB 3 is to merge our past, present, and future into one
+codebase. OpenEJB 3 will take the excellent features in OpenEJB 1.0
+(tomcat integration, testability, embeddibility, ease of use, etc), move
+towards an IoC architecture based on Gbean.org and Spring, bring in the
+OpenEJB 2 code, and implement the EJB 3.0 specification.
+
+# The Plan
+
+We will start on OpenEJB 3 by taking the 1.0 code (pretty much the same
+as 0.9.2), merging in the 2.0 code, and ensuring that the entire time
+the code we write is code you can use! We will never drop a feature,
+even temporarily. We will start from code that users are now using and
+always keep, maintain, and improve those features as we add new
+features. Releasing early and often.
+
+== Past
+
+OpenEJB 1.0 (from 0.9.2 lineage) has some great features and many people
+that depend on them. Tomcat integration, Collapsed EARs, Container
+Driven Testing, easy embedding, and other features make OpenEJB a unique
+EJB implementation. We're going to take this code, kill all the static
+old-school techniques, modernize it with and IoC architecture based on
+the gbean.org kernel. The gbean kernel is an IoC kernel compatible with
+both Spring and Geronimo.
+
+== Present
+
+OpenEJB 2.0 is an awesome fast implementation of EJB 2.1 that runs in
+Apache Geronimo. As the gbean.org kernel is both Spring and Geronimo
+compatible, it provides a great way for us to take the
+Geronimo-compatible EJB containers and deployers in OpenEJB 2 and start
+hammering them out and releasing them to long-time OpenEJB users. It
+will also allow people using OpenEJB to start experimenting with
+Spring's sophisticated IoC features.
+
+== Future
+
+EJB 3.0 is a new direction for EJB and we're going to do it with style.
+A focus on simplicity is where OpenEJB shines. Combining the EJB 3.0
+Simplified specification with our existing lightweight features, like
+Container Driven Testing, is just the beginning. We plan to go way
+beyond the planned additions and into areas the J2EE spec groups won't
+go such as deployment descriptors with attributes, simpler packaging,
+more flexible classloader setup, more powerful IoC support, simpler web
+services support and more.
+
+# Release on Day One
+
+Keep it working, keep it progressing, keep releasing. The 3.0 version
+number won't be the finishing line, but the starting line. Our work will
+start out as 3.0 on day one and keep incrementing the version number as
+we get further along our feature list. The EJB 3.0 spec is not completed
+and the OpenEJB 3.0 code line will be equally dynamic and best suited
+for adventurous developers who enjoy reading release notes and
+participating on user lists. There will be an incredible focus on
+keeping things stable enough to use the entire time as we work towards
+feature completion.
+
+The effect of all this is that you get a fixed-up, far more extensible,
+version of the code you are already using delivered to you right away.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-3.md
----------------------------------------------------------------------
diff --git a/docs/openejb-3.md b/docs/openejb-3.md
deleted file mode 100644
index f6c94cc..0000000
--- a/docs/openejb-3.md
+++ /dev/null
@@ -1,72 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=OpenEJB 3
-~~~~~~
-
-<a name="OpenEJB3-Past,Present,andFuture"></a>
-# Past, Present, and Future
-
-The goal of OpenEJB 3 is to merge our past, present, and future into one
-codebase. OpenEJB 3 will take the excellent features in OpenEJB 1.0
-(tomcat integration, testability, embeddibility, ease of use, etc), move
-towards an IoC architecture based on Gbean.org and Spring, bring in the
-OpenEJB 2 code, and implement the EJB 3.0 specification.
-
-<a name="OpenEJB3-ThePlan"></a>
-# The Plan
-
-We will start on OpenEJB 3 by taking the 1.0 code (pretty much the same as
-0.9.2), merging in the 2.0 code, and ensuring that the entire time the code
-we write is code you can use! We will never drop a feature, even
-temporarily. We will start from code that users are now using and always
-keep, maintain, and improve those features as we add new features.
-Releasing early and often.
-
-<a name="OpenEJB3-Past"></a>
-## Past
-
-OpenEJB 1.0 (from 0.9.2 lineage) has some great features and many people
-that depend on them. Tomcat integration, Collapsed EARs, Container Driven
-Testing, easy embedding, and other features make OpenEJB a unique EJB
-implementation. We're going to take this code, kill all the static
-old-school techniques, modernize it with and IoC architecture based on the
-gbean.org kernel. The gbean kernel is an IoC kernel compatible with both
-Spring and Geronimo.
-
-<a name="OpenEJB3-Present"></a>
-## Present
-
-OpenEJB 2.0 is an awesome fast implementation of EJB 2.1 that runs in
-Apache Geronimo. As the gbean.org kernel is both Spring and Geronimo
-compatible, it provides a great way for us to take the Geronimo-compatible
-EJB containers and deployers in OpenEJB 2 and start hammering them out and
-releasing them to long-time OpenEJB users. It will also allow people using
-OpenEJB to start experimenting with Spring's sophisticated IoC features.
-
-<a name="OpenEJB3-Future"></a>
-## Future
-
-EJB 3.0 is a new direction for EJB and we're going to do it with style. A
-focus on simplicity is where OpenEJB shines. Combining the EJB 3.0
-Simplified specification with our existing lightweight features, like
-Container Driven Testing, is just the beginning. We plan to go way beyond
-the planned additions and into areas the J2EE spec groups won't go such as
-deployment descriptors with attributes, simpler packaging, more flexible
-classloader setup, more powerful IoC support, simpler web services support
-and more.
-
-<a name="OpenEJB3-ReleaseonDayOne"></a>
-# Release on Day One
-
-Keep it working, keep it progressing, keep releasing. The 3.0 version
-number won't be the finishing line, but the starting line. Our work will
-start out as 3.0 on day one and keep incrementing the version number as we
-get further along our feature list. The EJB 3.0 spec is not completed and
-the OpenEJB 3.0 code line will be equally dynamic and best suited for
-adventurous developers who enjoy reading release notes and participating on
-user lists. There will be an incredible focus on keeping things stable
-enough to use the entire time as we work towards feature completion.
-
-The effect of all this is that you get a fixed-up, far more extensible,
-version of the code you are already using delivered to you right away.
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-binaries.adoc
----------------------------------------------------------------------
diff --git a/docs/openejb-binaries.adoc b/docs/openejb-binaries.adoc
new file mode 100644
index 0000000..ca1e5dd
--- /dev/null
+++ b/docs/openejb-binaries.adoc
@@ -0,0 +1,32 @@
+# OpenEJB Binaries
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+Add this to your _$HOME/.m2/settings.xml_ to enable publishing to
+the Apache Nexus repo. This works for snapshots or staging final
+binaries.
+
+....
+<settings>
+ <servers>
+ <server>
+ <id>apache.snapshots.https</id>
+ <username>yourapacheid</username>
+ <password>yourapachepass</password>
+ </server>
+ <server>
+ <id>apache.releases.https</id>
+ <username>yourapacheid</username>
+ <password>yourapachepass</password>
+ </server>
+ </servers>
+</settings>
+....
+
+Then publish via:
+
+....
+$ mvn clean deploy
+....
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-binaries.md
----------------------------------------------------------------------
diff --git a/docs/openejb-binaries.md b/docs/openejb-binaries.md
deleted file mode 100644
index d27ce26..0000000
--- a/docs/openejb-binaries.md
+++ /dev/null
@@ -1,27 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=OpenEJB Binaries
-~~~~~~
-Add this to your *$HOME/.m2/settings.xml* to enable publishing to the
-Apache Nexus repo. This works for snapshots or staging final binaries.
-
- <settings>
- <servers>
- <server>
- <id>apache.snapshots.https</id>
- <username>yourapacheid</username>
- <password>yourapachepass</password>
- </server>
- <server>
- <id>apache.releases.https</id>
- <username>yourapacheid</username>
- <password>yourapachepass</password>
- </server>
- </servers>
- </settings>
-
-
-Then publish via:
-
- $ mvn clean deploy
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-eclipse-plugin.adoc
----------------------------------------------------------------------
diff --git a/docs/openejb-eclipse-plugin.adoc b/docs/openejb-eclipse-plugin.adoc
new file mode 100644
index 0000000..670e936
--- /dev/null
+++ b/docs/openejb-eclipse-plugin.adoc
@@ -0,0 +1,22 @@
+# OpenEJB Eclipse Plugin
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+# OpenEJB Eclipse Plugin
+
+=== Overview
+
+The OpenEJB plugin for Eclipse provides the ability to run an OpenEJB
+standalone server and deploy projects directly from within the IDE,
+using functionality provided by the Eclipse Web Tools Project (WTP).
+Additionally, the plugin also provides the capability to read a
+ejb-jar.xml (and optionally a openejb-jar.xml) file and automatically
+add the corresponding EJB 3 annotations to your code automatically.
+
+link:installation.html[Installation]
+link:building-from-source.html[Building from source]
+link:generating-ejb-3-annotations.html[Generating EJB 3 annotations]
+link:running-a-standalone-openejb-server.html[Running a standalone
+OpenEJB server]
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-eclipse-plugin.md
----------------------------------------------------------------------
diff --git a/docs/openejb-eclipse-plugin.md b/docs/openejb-eclipse-plugin.md
deleted file mode 100644
index e68fb3a..0000000
--- a/docs/openejb-eclipse-plugin.md
+++ /dev/null
@@ -1,22 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=OpenEJB Eclipse Plugin
-~~~~~~
-<a name="OpenEJBEclipsePlugin-OpenEJBEclipsePlugin"></a>
-# OpenEJB Eclipse Plugin
-
-<a name="OpenEJBEclipsePlugin-Overview"></a>
-### Overview
-
-The OpenEJB plugin for Eclipse provides the ability to run an OpenEJB
-standalone server and deploy projects directly from within the IDE, using
-functionality provided by the Eclipse Web Tools Project (WTP).
-Additionally, the plugin also provides the capability to read a ejb-jar.xml
-(and optionally a openejb-jar.xml) file and automatically add the
-corresponding EJB 3 annotations to your code automatically.
-
-[Installation](installation.html)
-[Building from source](building-from-source.html)
-[Generating EJB 3 annotations](generating-ejb-3-annotations.html)
-[Running a standalone OpenEJB server](running-a-standalone-openejb-server.html)
http://git-wip-us.apache.org/repos/asf/tomee/blob/68720016/docs/openejb-jsr-107-integration.adoc
----------------------------------------------------------------------
diff --git a/docs/openejb-jsr-107-integration.adoc b/docs/openejb-jsr-107-integration.adoc
new file mode 100644
index 0000000..e7b3172
--- /dev/null
+++ b/docs/openejb-jsr-107-integration.adoc
@@ -0,0 +1,24 @@
+# OpenEJB JSR-107 Integration
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+# OpenEJB JSR-107 (JCACHE) Integration
+
+This page is for the collaboration for those involved with the
+integration of JSR-107 into OpenEJB.
+
+=== Overview
+
+The idea here is to add a caching layer to OpenEJB. The overall
+objective is to improve performance in OpenEJB where applicable through
+caching EJBs.
+
+=== Status
+
+Dain and myself (Jeremy) have deciphered the JSR-107 spec and how I am
+working on the first crude integration of JCACHE into OpenEJB. Anyone
+interested in helping or providing any feedback/suggestions, please
+contact me via the developer mailing list.