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 <[email protected]> Authored: Wed Dec 5 22:07:24 2018 -0800 Committer: Carlos Chacin <[email protected]> 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.
