From 68720016fa1ecc08890ac7241cb82dab9e424d1c Mon Sep 17 00:00:00 2001 From: Carlos Chacin Date: Wed, 5 Dec 2018 22:07:24 -0800 Subject: [PATCH 1/2] TOMEE-2316 Convert Markdown files to Asciidoc in the docs folder - 8 --- docs/messagedrivencontainer-config.adoc | 85 ++ docs/messagedrivencontainer-config.md | 67 -- docs/multicast-discovery.adoc | 91 +++ docs/multicast-discovery.md | 83 -- .../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(-) create mode 100644 docs/messagedrivencontainer-config.adoc delete mode 100644 docs/messagedrivencontainer-config.md create mode 100644 docs/multicast-discovery.adoc delete mode 100644 docs/multicast-discovery.md create mode 100644 docs/multiple-business-interface-hazzards.adoc delete mode 100644 docs/multiple-business-interface-hazzards.md create mode 100644 docs/multipoint-considerations.adoc delete mode 100644 docs/multipoint-considerations.md create mode 100644 docs/multipoint-discovery.adoc delete mode 100644 docs/multipoint-discovery.md create mode 100644 docs/multipoint-recommendations.adoc delete mode 100644 docs/multipoint-recommendations.md create mode 100644 docs/multipulse-discovery.adoc delete mode 100644 docs/multipulse-discovery.md create mode 100644 docs/new-in-openejb-3.0.adoc delete mode 100644 docs/new-in-openejb-3.0.md create mode 100644 docs/openejb-3.adoc delete mode 100644 docs/openejb-3.md create mode 100644 docs/openejb-binaries.adoc delete mode 100644 docs/openejb-binaries.md create mode 100644 docs/openejb-eclipse-plugin.adoc delete mode 100644 docs/openejb-eclipse-plugin.md create mode 100644 docs/openejb-jsr-107-integration.adoc delete mode 100644 docs/openejb-jsr-107-integration.md create mode 100644 docs/openejb.xml.adoc delete mode 100644 docs/openejb.xml.md create mode 100644 docs/openjpa.adoc delete mode 100644 docs/openjpa.md create mode 100644 docs/orb-config.adoc delete mode 100644 docs/orb-config.md create mode 100644 docs/persistence-context.adoc delete mode 100644 docs/persistence-context.md create mode 100644 docs/persistence-unit-ref.adoc delete mode 100644 docs/persistence-unit-ref.md create mode 100644 docs/properties-listing.adoc delete mode 100644 docs/properties-listing.md create mode 100644 docs/properties-tool.adoc delete mode 100644 docs/properties-tool.md create mode 100644 docs/property-overriding.adoc delete mode 100644 docs/property-overriding.md create mode 100644 docs/provisioning.adoc delete mode 100644 docs/provisioning.md create mode 100644 docs/proxyfactory-config.adoc delete mode 100644 docs/proxyfactory-config.md diff --git a/docs/messagedrivencontainer-config.adoc b/docs/messagedrivencontainer-config.adoc new file mode 100644 index 00000000000..10a910946ae --- /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 +`/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. + +.... + + activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec + instanceLimit = 10 + messageListenerInterface = javax.jms.MessageListener + resourceAdapter = Default JMS Resource Adapter + +.... + +Alternatively, a MessageDrivenContainer can be declared via properties +in the `/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 diff --git a/docs/messagedrivencontainer-config.md b/docs/messagedrivencontainer-config.md deleted file mode 100644 index 3362a4fe8d1..00000000000 --- 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 `/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. - - - activationSpecClass = org.apache.activemq.ra.ActiveMQActivationSpec - instanceLimit = 10 - messageListenerInterface = javax.jms.MessageListener - resourceAdapter = Default JMS Resource Adapter - - -Alternatively, a MessageDrivenContainer can be declared via properties in the `/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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PropertyTypeDefaultDescription
activationSpecClassStringorg.apache.activemq.ra.ActiveMQActivationSpec -Specifies the activation spec class -
instanceLimitint10 -Specifies the maximum number of bean instances that are -allowed to exist for each MDB deployment. -
messageListenerInterfaceStringjavax.jms.MessageListener -Specifies the message listener interface handled by this container -
resourceAdapterStringDefault JMS Resource Adapter -The resource adapter delivers messages to the container -
diff --git a/docs/multicast-discovery.adoc b/docs/multicast-discovery.adoc new file mode 100644 index 00000000000..6fd67f4d60c --- /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. diff --git a/docs/multicast-discovery.md b/docs/multicast-discovery.md deleted file mode 100644 index 10f1692b49b..00000000000 --- 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. diff --git a/docs/multiple-business-interface-hazzards.adoc b/docs/multiple-business-interface-hazzards.adoc new file mode 100644 index 00000000000..caeae437444 --- /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) diff --git a/docs/multiple-business-interface-hazzards.md b/docs/multiple-business-interface-hazzards.md deleted file mode 100644 index c6558d70b6d..00000000000 --- 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 -~~~~~~ - -# 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 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) - diff --git a/docs/multipoint-considerations.adoc b/docs/multipoint-considerations.adoc new file mode 100644 index 00000000000..24d36440fb1 --- /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. diff --git a/docs/multipoint-considerations.md b/docs/multipoint-considerations.md deleted file mode 100644 index 63ebf11850b..00000000000 --- 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. diff --git a/docs/multipoint-discovery.adoc b/docs/multipoint-discovery.adoc new file mode 100644 index 00000000000..a8a4daade61 --- /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. diff --git a/docs/multipoint-discovery.md b/docs/multipoint-discovery.md deleted file mode 100644 index bb93b133b93..00000000000 --- 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. diff --git a/docs/multipoint-recommendations.adoc b/docs/multipoint-recommendations.adoc new file mode 100644 index 00000000000..97644796809 --- /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/.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 +.... diff --git a/docs/multipoint-recommendations.md b/docs/multipoint-recommendations.md deleted file mode 100644 index dfcb5734153..00000000000 --- 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 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: - -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 overrides - -Always remember that any property in a `conf/.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 diff --git a/docs/multipulse-discovery.adoc b/docs/multipulse-discovery.adoc new file mode 100644 index 00000000000..63d6518c8db --- /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. diff --git a/docs/multipulse-discovery.md b/docs/multipulse-discovery.md deleted file mode 100644 index 087803d5ba5..00000000000 --- 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. diff --git a/docs/new-in-openejb-3.0.adoc b/docs/new-in-openejb-3.0.adoc new file mode 100644 index 00000000000..f5d871f6ded --- /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. diff --git a/docs/new-in-openejb-3.0.md b/docs/new-in-openejb-3.0.md deleted file mode 100644 index 3c568abc453..00000000000 --- a/docs/new-in-openejb-3.0.md +++ /dev/null @@ -1,179 +0,0 @@ -title= New in OpenEJB 3.0 -type=page -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. - - - - - diff --git a/docs/openejb-3.adoc b/docs/openejb-3.adoc new file mode 100644 index 00000000000..260bbb4bbcf --- /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. diff --git a/docs/openejb-3.md b/docs/openejb-3.md deleted file mode 100644 index f6c94ccffe8..00000000000 --- a/docs/openejb-3.md +++ /dev/null @@ -1,72 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=OpenEJB 3 -~~~~~~ - - -# 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. diff --git a/docs/openejb-binaries.adoc b/docs/openejb-binaries.adoc new file mode 100644 index 00000000000..ca1e5ddae3e --- /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. + +.... + + + + apache.snapshots.https + yourapacheid + yourapachepass + + + apache.releases.https + yourapacheid + yourapachepass + + + +.... + +Then publish via: + +.... +$ mvn clean deploy +.... diff --git a/docs/openejb-binaries.md b/docs/openejb-binaries.md deleted file mode 100644 index d27ce2668af..00000000000 --- 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. - - - - - apache.snapshots.https - yourapacheid - yourapachepass - - - apache.releases.https - yourapacheid - yourapachepass - - - - - -Then publish via: - - $ mvn clean deploy diff --git a/docs/openejb-eclipse-plugin.adoc b/docs/openejb-eclipse-plugin.adoc new file mode 100644 index 00000000000..670e936f74d --- /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] diff --git a/docs/openejb-eclipse-plugin.md b/docs/openejb-eclipse-plugin.md deleted file mode 100644 index e68fb3ab69e..00000000000 --- a/docs/openejb-eclipse-plugin.md +++ /dev/null @@ -1,22 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=OpenEJB Eclipse Plugin -~~~~~~ - -# 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. - -[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) diff --git a/docs/openejb-jsr-107-integration.adoc b/docs/openejb-jsr-107-integration.adoc new file mode 100644 index 00000000000..e7b3172e3d1 --- /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. diff --git a/docs/openejb-jsr-107-integration.md b/docs/openejb-jsr-107-integration.md deleted file mode 100644 index f32eddf24a5..00000000000 --- a/docs/openejb-jsr-107-integration.md +++ /dev/null @@ -1,25 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=OpenEJB JSR-107 Integration -~~~~~~ - - -# 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. diff --git a/docs/openejb.xml.adoc b/docs/openejb.xml.adoc new file mode 100644 index 00000000000..00dd7f678c8 --- /dev/null +++ b/docs/openejb.xml.adoc @@ -0,0 +1,96 @@ +:jbake-title: openejb.xml +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +# Overview + +The openejb.xml is the main configuration file for the container system +and its services such as transaction, security, and data sources. + +The format is a mix of xml and properties inspired by the format of the +httpd configuration file. Basically: + +.... + + ...properties... + +.... + +Such as: + +.... + + username foo + password bar + +.... + +_Note the space_. White space is a valid name/value pair separator in +any java properties file (along with semi-colon). So the above is +equivalent to: + +.... + + username = foo + password = bar + +.... + +You are free to use white space, ":", or "=" for your name/value pair +separator with no effect on OpenEJB. + +== Property Defaults and Overriding + +The openejb.xml file itself functions as an override, default values are +specified via other means (service-jar.xml files in the classpath), +therefore you only need to specify property values here for 2 reasons: +1. you wish to for documentation purposes 2. you need to change the +default value + +The default openejb.xml file has most of the useful properties for each +component explicitly listed with default values for documentation +purposes. It is safe to delete them and be assured that no behavior will +change if a smaller config file is desired. + +Overriding can also be done via the command line or plain Java system +properties. See link:system-properties.html[System Properties] for +details. + +== What properties are available? + +To know what properties can be overriden the './bin/openejb properties' +command is very useful: see link:properties-tool.html[Properties Tool] + +Its function is to connect to a running server and print a canonical +list of all properties OpenEJB can see via the various means of +configuration. When sending requests for help to the users list or jira, +it is highly encouraged to send the output of this tool with your +message. + +== Not configurable via openejb.xml + +The only thing not yet configurable via this file are ServerServices due +to OpenEJB's embeddable nature and resulting long standing tradition of +keeping the container system separate from the server layer. This may +change someday, but untill then ServerServices are configurable via +conf/.properties files such as conf/ejbd.properties to configure the +main protocol that services EJB client requests. + +The format of those properties files is greatly adapted from the xinet.d +style of configuration and even shares similar functionality and +properties such as host-based authorization (HBA) via the 'only_from' +property. + +== Restoring openejb.xml to the defaults + +To restore this file to its original default state, you can simply +delete it or rename it and OpenEJB will see it's missing and unpack +another openejb.xml into the conf/ directory when it starts. + +This is not only handy for recovering from a non-functional config, but +also for upgrading as OpenEJB will not overwrite your existing +configuration file should you choose to unpack an new distro over the +top of an old one -- this style of upgrade is safe provided you move +your old lib/ directory first. diff --git a/docs/openejb.xml.md b/docs/openejb.xml.md deleted file mode 100644 index 1836d3562bd..00000000000 --- a/docs/openejb.xml.md +++ /dev/null @@ -1,96 +0,0 @@ -title=openejb.xml -type=page -status=published -~~~~~~ - - -# Overview - -The openejb.xml is the main configuration file for the container system and -its services such as transaction, security, and data sources. - -The format is a mix of xml and properties inspired by the format of the -httpd configuration file. Basically: - - - - ...properties... - - - -Such as: - - - - username foo - password bar - - - -*Note the space*. White space is a valid name/value pair separator in any -java properties file (along with semi-colon). So the above is equivalent -to: - - - username = foo - password = bar - - -You are free to use white space, ":", or "=" for your name/value pair -separator with no effect on OpenEJB. - - -## Property Defaults and Overriding - -The openejb.xml file itself functions as an override, default values are -specified via other means (service-jar.xml files in the classpath), -therefore you only need to specify property values here for 2 reasons:
-1. you wish to for documentation purposes
-2. you need to change the default value - -The default openejb.xml file has most of the useful properties for each -component explicitly listed with default values for documentation purposes. - It is safe to delete them and be assured that no behavior will change if a -smaller config file is desired. - -Overriding can also be done via the command line or plain Java system -properties. See [System Properties](system-properties.html) - for details. - - -## What properties are available? - -To know what properties can be overriden the './bin/openejb properties' -command is very useful: see [Properties Tool](properties-tool.html) - -Its function is to connect to a running server and print a canonical list -of all properties OpenEJB can see via the various means of configuration. -When sending requests for help to the users list or jira, it is highly -encouraged to send the output of this tool with your message. - - -## Not configurable via openejb.xml - -The only thing not yet configurable via this file are ServerServices due to -OpenEJB's embeddable nature and resulting long standing tradition of -keeping the container system separate from the server layer. This may -change someday, but untill then ServerServices are configurable via -conf/.properties files such as conf/ejbd.properties to -configure the main protocol that services EJB client requests. - -The format of those properties files is greatly adapted from the xinet.d style -of configuration and even shares similar functionality and properties such -as host-based authorization (HBA) via the 'only_from' property. - - -## Restoring openejb.xml to the defaults - -To restore this file to its original default state, you can simply delete -it or rename it and OpenEJB will see it's missing and unpack another -openejb.xml into the conf/ directory when it starts. - -This is not only handy for recovering from a non-functional config, but -also for upgrading as OpenEJB will not overwrite your existing -configuration file should you choose to unpack an new distro over the top -of an old one -- this style of upgrade is safe provided you move your old -lib/ directory first. diff --git a/docs/openjpa.adoc b/docs/openjpa.adoc new file mode 100644 index 00000000000..92d4ff75662 --- /dev/null +++ b/docs/openjpa.adoc @@ -0,0 +1,125 @@ +# OpenJPA +:index-group: JPA +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +OpenJPA is bundled with OpenEJB as the default persistence provider. + +An example of working `persistence.xml` for OpenJPA: + +.... + + + + movieDatabase + movieDatabaseUnmanaged + org.superbiz.injection.jpa.Movie + + + + + + +.... + +Where the datasources above are configured in your openejb.xml as +follows: + +.... + + JdbcDriver = org.hsqldb.jdbcDriver + JdbcUrl = jdbc:hsqldb:mem:moviedb + + + + JdbcDriver = org.hsqldb.jdbcDriver + JdbcUrl = jdbc:hsqldb:mem:moviedb + JtaManaged = false + +.... + +Or in properties as follows: + +.... +p.put("movieDatabase", "new://Resource?type=DataSource"); +p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver"); +p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb"); + +p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource"); +p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver"); +p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb"); +p.put("movieDatabaseUnmanaged.JtaManaged", "false"); +.... + +== Common exceptions + +=== Table not found in statement + +Or as derby will report it "Table 'abc.xyz' doesn't exist" + +Someone has to create the database structure for your persistent +objects. If you add the _openjpa.jdbc.SynchronizeMappings_ property as +shown below OpenJPA will auto-create all your tables, all your primary +keys and all foreign keys exactly to match your objects. + +.... + + + + + + + + + + +.... + +== Auto-commit can not be set while enrolled in a transaction + +Pending + +== This broker is not configured to use managed transactions. + +=== Setup + +Using a EXTENDED persistence context ... + +.... +@PersistenceContext(unitName = "movie-unit", type = PersistenceContextType.EXTENDED) +EntityManager entityManager; +.... + +on a persistence unit setup as RESOURCE_LOCAL ... + +.... + + ... + +.... + +inside of a transaction. + +.... +@TransactionAttribute(TransactionAttributeType.REQUIRED) +public void addMovie(Movie movie) throws Exception { + entityManager.persist(movie); +} +.... + +Note the default transaction attribute for any ejb method is REQUIRED +unless explicitly set otherwise in the bean class or method in question. + +=== Solutions + +You can either: + +[arabic] +. Change your bean or it's method to use +`TransactionAttributeType.NOT_REQUIRED` or +`TransactionAttributeType.NEVER` which will guarantee it will not be +invoked in a JTA transaction. +. Change your persistence.xml so the persistence-unit uses +`transaction-type="TRANSACTION"` making it capable of participating in a +JTA transaction. diff --git a/docs/openjpa.md b/docs/openjpa.md deleted file mode 100644 index 2ea21b65492..00000000000 --- a/docs/openjpa.md +++ /dev/null @@ -1,113 +0,0 @@ -index-group=JPA -type=page -status=published -title=OpenJPA -~~~~~~ -OpenJPA is bundled with OpenEJB as the default persistence provider. - -An example of working `persistence.xml` for OpenJPA: - - - - - movieDatabase - movieDatabaseUnmanaged - org.superbiz.injection.jpa.Movie - - - - - - - - -Where the datasources above are configured in your openejb.xml as follows: - - - JdbcDriver = org.hsqldb.jdbcDriver - JdbcUrl = jdbc:hsqldb:mem:moviedb - - - - JdbcDriver = org.hsqldb.jdbcDriver - JdbcUrl = jdbc:hsqldb:mem:moviedb - JtaManaged = false - - - -Or in properties as follows: - - p.put("movieDatabase", "new://Resource?type=DataSource"); - p.put("movieDatabase.JdbcDriver", "org.hsqldb.jdbcDriver"); - p.put("movieDatabase.JdbcUrl", "jdbc:hsqldb:mem:moviedb"); - - p.put("movieDatabaseUnmanaged", "new://Resource?type=DataSource"); - p.put("movieDatabaseUnmanaged.JdbcDriver", "org.hsqldb.jdbcDriver"); - p.put("movieDatabaseUnmanaged.JdbcUrl", "jdbc:hsqldb:mem:moviedb"); - p.put("movieDatabaseUnmanaged.JtaManaged", "false"); - - -# Common exceptions - -## Table not found in statement - -Or as derby will report it "Table 'abc.xyz' doesn't exist" - -Someone has to create the database structure for your persistent objects. -If you add the *openjpa.jdbc.SynchronizeMappings* property as shown below -OpenJPA will auto-create all your tables, all your primary keys and all -foreign keys exactly to match your objects. - - - - - - - - - - - - - - -## Auto-commit can not be set while enrolled in a transaction - -Pending - - -## This broker is not configured to use managed transactions. - - -### Setup - -Using a EXTENDED persistence context ... - - @PersistenceContext(unitName = "movie-unit", type = PersistenceContextType.EXTENDED) - EntityManager entityManager; - -on a persistence unit setup as RESOURCE_LOCAL ... - - - ... - - - -inside of a transaction. - - @TransactionAttribute(TransactionAttributeType.REQUIRED) - public void addMovie(Movie movie) throws Exception { - entityManager.persist(movie); - } - - -Note the default transaction attribute for any ejb method is REQUIRED -unless explicitly set otherwise in the bean class or method in question. - - -### Solutions - -You can either: - -1. Change your bean or it's method to use `TransactionAttributeType.NOT_REQUIRED` or `TransactionAttributeType.NEVER` which will guarantee it will not be invoked in a JTA transaction. -1. Change your persistence.xml so the persistence-unit uses `transaction-type="TRANSACTION"` making it capable of participating in a JTA transaction. diff --git a/docs/orb-config.adoc b/docs/orb-config.adoc new file mode 100644 index 00000000000..008c0058a4a --- /dev/null +++ b/docs/orb-config.adoc @@ -0,0 +1,40 @@ +# ORB Configuration +:index-group: Configuration +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +A ORB can be declared via xml in the `/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. + +.... + + +.... + +Alternatively, a ORB can be declared via properties in the +`/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` + +.... +myORB = new://Resource?type=org.omg.CORBA.ORB +.... + +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 ORB a warning will be +logged. If a ORB is needed by the application and one is not declared, +TomEE will create one dynamically using default settings. Multiple ORB +declarations are allowed. # Supported Properties + +Property + +Type + +Default + +Description diff --git a/docs/orb-config.md b/docs/orb-config.md deleted file mode 100644 index 34aa533db42..00000000000 --- a/docs/orb-config.md +++ /dev/null @@ -1,26 +0,0 @@ -index-group=Configuration -type=page -status=published -title=ORB Configuration -~~~~~~ - - -A ORB can be declared via xml in the `/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. - - - - -Alternatively, a ORB can be declared via properties in the `/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` - - myORB = new://Resource?type=org.omg.CORBA.ORB - -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 ORB a warning will be logged. If a ORB is needed by the application and one is not declared, TomEE will create one dynamically using default settings. Multiple ORB declarations are allowed. -# Supported Properties - - - - - - - -
PropertyTypeDefaultDescription
diff --git a/docs/persistence-context.adoc b/docs/persistence-context.adoc new file mode 100644 index 00000000000..c033d9309c5 --- /dev/null +++ b/docs/persistence-context.adoc @@ -0,0 +1,59 @@ +# persistence-context +:index-group: JPA +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +# Via annotation + +Both lookup and injection of an EntityManager can be configured via the +`@PersistenceContext` annotation. + +.... +package org.superbiz; + +import javax.persistence.PersistenceContext; +import javax.persistence.EntityManager; +import javax.ejb.Stateless; +import javax.naming.InitialContext; + +@Stateless +@PersistenceContext(name = "myFooEntityManager", unitName = "foo-unit") +public class MyBean implements MyInterface { + + @PersistenceContext(unitName = "bar-unit") + private EntityManager myBarEntityManager; + + public void someBusinessMethod() throws Exception { + if (myBarEntityManager == null) throw new NullPointerException("myBarEntityManager not injected"); + + // Both can be looked up from JNDI as well + InitialContext context = new InitialContext(); + EntityManager fooEntityManager = (EntityManager) context.lookup("java:comp/env/myFooEntityManager"); + EntityManager barEntityManager = (EntityManager) context.lookup("java:comp/env/org.superbiz.MyBean/myBarEntityManager"); + } +} +.... + +# Via xml + +The above @PersistenceContext annotation usage is 100% equivalent to the +following xml. + +.... + + myFooEntityManager + foo-unit + Transaction + + + + org.superbiz.calculator.MyBean/myBarEntityManager + bar-unit + Transaction + + org.superbiz.calculator.MyBean + myBarEntityManager + + +.... diff --git a/docs/persistence-context.md b/docs/persistence-context.md deleted file mode 100644 index 9b23af91f6d..00000000000 --- a/docs/persistence-context.md +++ /dev/null @@ -1,57 +0,0 @@ -index-group=JPA -type=page -status=published -title=persistence-context -~~~~~~ - -# Via annotation - -Both lookup and injection of an EntityManager can be configured via the -`@PersistenceContext` annotation. - - package org.superbiz; - - import javax.persistence.PersistenceContext; - import javax.persistence.EntityManager; - import javax.ejb.Stateless; - import javax.naming.InitialContext; - - @Stateless - @PersistenceContext(name = "myFooEntityManager", unitName = "foo-unit") - public class MyBean implements MyInterface { - - @PersistenceContext(unitName = "bar-unit") - private EntityManager myBarEntityManager; - - public void someBusinessMethod() throws Exception { - if (myBarEntityManager == null) throw new NullPointerException("myBarEntityManager not injected"); - - // Both can be looked up from JNDI as well - InitialContext context = new InitialContext(); - EntityManager fooEntityManager = (EntityManager) context.lookup("java:comp/env/myFooEntityManager"); - EntityManager barEntityManager = (EntityManager) context.lookup("java:comp/env/org.superbiz.MyBean/myBarEntityManager"); - } - } - - - -# Via xml - -The above @PersistenceContext annotation usage is 100% equivalent to the -following xml. - - - myFooEntityManager - foo-unit - Transaction - - - - org.superbiz.calculator.MyBean/myBarEntityManager - bar-unit - Transaction - - org.superbiz.calculator.MyBean - myBarEntityManager - - diff --git a/docs/persistence-unit-ref.adoc b/docs/persistence-unit-ref.adoc new file mode 100644 index 00000000000..447829df071 --- /dev/null +++ b/docs/persistence-unit-ref.adoc @@ -0,0 +1,91 @@ +# persistence-unit-ref +:index-group: JPA +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +Both lookup and injection of an +EntityManagerFactory can be configured via the @PersistenceUnit +annotation or in xml. Annotations and xml have equal function in both +lookup and injection. + +# Injection and Lookup + +== Via annotation + +.... +package org.superbiz; + +import javax.persistence.PersistenceUnit; +import javax.persistence.EntityManagerFactory; +import javax.ejb.Stateless; +import javax.naming.InitialUnit; + +@Stateless +public class MyBean implements MyInterface { + + @PersistenceUnit(unitName = "bar-unit") + private EntityManagerFactory myBarEntityManagerFactory; + + public void someBusinessMethod() throws Exception { + if (myBarEntityManagerFactory == null) throw new NullPointerException("myBarEntityManagerFactory not injected"); + + // Both can be looked up from JNDI as well + InitialContext unit = new InitialContext(); + EntityManagerFactory barEntityManagerFactory = (EntityManagerFactory) context.lookup("java:comp/env/org.superbiz.MyBean/myBarEntityManagerFactory"); + } +} +.... + +== Via xml + +The above @PersistenceUnit annotation usage is 100% equivalent to the +following xml. + +.... + + org.superbiz.calculator.MyBean/myBarEntityManagerFactory + bar-unit + Transaction + + org.superbiz.calculator.MyBean + myBarEntityManagerFactory + + +.... + +== Lookup only + +=== Via annotation + +.... +package org.superbiz; + +import javax.persistence.PersistenceUnit; +import javax.persistence.EntityManagerFactory; +import javax.ejb.Stateless; +import javax.naming.InitialUnit; + +@Stateless +@PersistenceUnit(name = "myFooEntityManagerFactory", unitName = "foo-unit") +public class MyBean implements MyInterface { + + public void someBusinessMethod() throws Exception { + InitialContext context = new InitialContext(); + EntityManagerFactory fooEntityManagerFactory = (EntityManagerFactory) context.lookup("java:comp/env/myFooEntityManagerFactory"); + } +} +.... + +# Via xml + +The above @PersistenceUnit annotation usage is 100% equivalent to the +following xml. + +.... + + myFooEntityManagerFactory + foo-unit + Transaction + +.... diff --git a/docs/persistence-unit-ref.md b/docs/persistence-unit-ref.md deleted file mode 100644 index d980b6bcd00..00000000000 --- a/docs/persistence-unit-ref.md +++ /dev/null @@ -1,91 +0,0 @@ -index-group=JPA -type=page -status=published -title=persistence-unit-ref -~~~~~~ -Both lookup and injection of an EntityManagerFactory can be configured via -the @PersistenceUnit annotation or in xml. -Annotations and xml have equal function in both lookup and injection. - - -# Injection and Lookup - - -## Via annotation - - package org.superbiz; - - import javax.persistence.PersistenceUnit; - import javax.persistence.EntityManagerFactory; - import javax.ejb.Stateless; - import javax.naming.InitialUnit; - - @Stateless - public class MyBean implements MyInterface { - - @PersistenceUnit(unitName = "bar-unit") - private EntityManagerFactory myBarEntityManagerFactory; - - public void someBusinessMethod() throws Exception { - if (myBarEntityManagerFactory == null) throw new NullPointerException("myBarEntityManagerFactory not injected"); - - // Both can be looked up from JNDI as well - InitialContext unit = new InitialContext(); - EntityManagerFactory barEntityManagerFactory = (EntityManagerFactory) context.lookup("java:comp/env/org.superbiz.MyBean/myBarEntityManagerFactory"); - } - } - - - -## Via xml - -The above @PersistenceUnit annotation usage is 100% equivalent to the -following xml. - - - org.superbiz.calculator.MyBean/myBarEntityManagerFactory - bar-unit - Transaction - - org.superbiz.calculator.MyBean - myBarEntityManagerFactory - - - - - -# Lookup only - -## Via annotation - - package org.superbiz; - - import javax.persistence.PersistenceUnit; - import javax.persistence.EntityManagerFactory; - import javax.ejb.Stateless; - import javax.naming.InitialUnit; - - @Stateless - @PersistenceUnit(name = "myFooEntityManagerFactory", unitName = "foo-unit") - public class MyBean implements MyInterface { - - public void someBusinessMethod() throws Exception { - InitialContext context = new InitialContext(); - EntityManagerFactory fooEntityManagerFactory = (EntityManagerFactory) context.lookup("java:comp/env/myFooEntityManagerFactory"); - } - } - - - -# Via xml - -The above @PersistenceUnit annotation usage is 100% equivalent to the -following xml. - - - myFooEntityManagerFactory - foo-unit - Transaction - - - diff --git a/docs/properties-listing.adoc b/docs/properties-listing.adoc new file mode 100644 index 00000000000..27738b39cff --- /dev/null +++ b/docs/properties-listing.adoc @@ -0,0 +1,729 @@ +# System Properties Listing +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +== OpenEJB system properties + +Name + +Value + +Description + +openejb.embedded.remotable + +bool + +activate or not the remote services when available + +.bind, .port, .disabled, .threads + +host or IP, port, bool + +override the host. Available for ejbd and httpejbd services (used by +jaxws and jaxrs), number of thread to maneg requests + +openejb.embedded.initialcontext.close + +LOGOUT or DESTROY + +configure the hook called when closing the initial context. Useful when +starting OpenEJB from a new InitialContext([properties]) instantiation. +By default it simply logs out the logged user if it exists. DESTROY +means clean the container. + +javax.persistence.provider + +string + +override the JPA provider value + +javax.persistence.transactionType + +string + +override the transaction type for persistence contexts + +javax.persistence.jtaDataSource + +string + +override the JTA datasource value for persistence contexts + +javax.persistence.nonJtaDataSource + +string + +override the non JTA datasource value for persistence contexts + +openejb.descriptors.output + +bool + +dump memory deployment descriptors. Can be used to set complete metadata +to true and avoid scanning when starting the container or to check the +used configuration. + +openejb.deployments.classpath.require.descriptor + +CLIENT or EJB + +can allow to filter what you want to scan (client modules or ejb +modules) + +openejb.descriptors.output.folder + +path + +where to dump deployement descriptors if activated. + +openejb.strict.interface.declaration + +bool + +add some validations on session beans (spec validations in particular). +false by default. + +openejb.conf.file or openejb.configuration + +string + +OpenEJB configuration file path + +openejb.debuggable-vm-hackery + +bool + +remove JMS informations from deployment + +openejb.validation.skip + +bool + +skip the validations done when OpenEJB deploys beans + +openejb.deployments.classpath.ear + +bool + +deploy the classpath as an ear + +openejb.webservices.enabled + +bool + +activate or not webservices + +openejb.validation.output.level + +TERSE or MEDIUM or VERBOSE + +level of the logs used to report validation errors + +openejb.user.mbeans.list + +* or a list of classes separated by , ++ ++ ++ +list of mbeans to deploy automatically ++ ++ ++ ++ ++ +openejb.deploymentId.format ++ ++ ++ +composition (+string) of \{ejbName} \{ejbType} \{ejbClass} and +\{ejbClass.simpleName} ++ ++ ++ +default \{ejbName}. The format to use to deploy ejbs. ++ ++ ++ ++ ++ +openejb.deployments.classpath ++ ++ ++ +bool ++ ++ ++ +whether or not deploy from classpath ++ ++ ++ ++ ++ +openejb.deployments.classpath.include and +openejb.deployments.classpath.exclude ++ ++ ++ +regex ++ ++ ++ +regex to filter the scanned classpath (when you are in this case) ++ ++ ++ ++ ++ +openejb.deployments.package.include and +openejb.deployments.package.exclude ++ ++ ++ +regex ++ ++ ++ +regex to filter scanned packages ++ ++ ++ ++ ++ +openejb.autocreate.jta-datasource-from-non-jta-one ++ ++ ++ +bool ++ ++ ++ +whether or not auto create the jta datasource if it doesn't exist but a +non jta datasource exists. Useful when using hibernate to be able to get +a real non jta datasource. ++ ++ ++ ++ ++ +openejb.altdd.prefix ++ ++ ++ +string ++ ++ ++ +prefix use for altDD (example test to use a test.ejb-jar.xml). ++ ++ ++ ++ ++ +org.apache.openejb.default.system.interceptors ++ ++ ++ +list of interceptor (qualified names) separated by a comma or a space ++ ++ ++ +add these interceptor on all beans ++ ++ ++ ++ ++ +openejb.jndiname.strategy.class ++ ++ ++ +class name ++ ++ ++ +an implementation of +org.apache.openejb.assembler.classic.JndiBuilder.JndiNameStrategy ++ ++ ++ ++ ++ +openejb.jndiname.failoncollision ++ ++ ++ +bool ++ ++ ++ +if a NameAlreadyBoundException is thrown or not when 2 EJBs have the +same name ++ ++ ++ ++ ++ +openejb.jndiname.format ++ ++ ++ +composition (+string) of these properties: ejbType, ejbClass, +ejbClass.simpleName, ejbClass.packageName, ejbName, deploymentId, +interfaceType, interfaceType.annotationName, +interfaceType.annotationNameLC, interfaceType.xmlName, +interfaceType.xmlNameCc, interfaceType.openejbLegacyName, +interfaceClass, interfaceClass.simpleName, interfaceClass.packageName ++ ++ ++ +default \{deploymentId}\{interfaceType.annotationName}. Change the name +used for the ejb. ++ ++ ++ ++ ++ +openejb.org.quartz.threadPool.class ++ ++ ++ +class qualified name which implements org.quartz.spi.ThreadPool ++ ++ ++ +the thread pool used by quartz (used to manage ejb timers) ++ ++ ++ ++ ++ +openejb.localcopy ++ ++ ++ +bool ++ ++ ++ +default true. whether or not copy EJB arguments[/method/interface] for +remote invocations. ++ ++ ++ ++ ++ +openejb.cxf.jax-rs.providers ++ ++ ++ +the list of the qualified name of the JAX-RS providers separated by +comma or space. Note: to specify a provider for a specific service +suffix its class qualified name by ".providers", the value follow the +same rules. Note 2: default is a shortcut for jaxb and json providers. ++ ++ ++ ++ ++ ++ ++ +openejb.wsAddress.format ++ ++ ++ +composition (+string) of \{ejbJarId}, ejbDeploymentId, ejbType, +ejbClass, ejbClass.simpleName, ejbName, portComponentName, wsdlPort, +wsdlService ++ ++ ++ +default /\{ejbDeploymentId}. The WS name format. ++ ++ ++ ++ ++ +org.apache.openejb.server.webservices.saaj.provider ++ ++ ++ +axis2, sun or null ++ ++ ++ +specified the saaj configuration ++ ++ ++ ++ ++ +[.]. or [.] ++ ++ ++ +whatever is supported (generally string, int ...) ++ ++ ++ +set this value to the corresponding service. example: +[EnterpriseBean.].activation., +[PERSISTENCEUNIT.]., [RESOURCE.] ++ ++ ++ ++ ++ +log4j.category.OpenEJB.options ++ ++ ++ +DEBUG, INFO, ... ++ ++ ++ +active one OpenEJB log level. need log4j in the classpath ++ ++ ++ ++ ++ +openejb.jmx.active ++ ++ ++ +bool ++ ++ ++ +activate (by default) or not the OpenEJB JMX MBeans ++ ++ ++ ++ ++ +openejb.nobanner ++ ++ ++ +bool ++ ++ ++ +activate or not the OpenEJB banner (activated by default) ++ ++ ++ +openejb.check.classloader ++ ++ ++ +bool ++ ++ ++ +if true print some information about duplicated classes ++ ++ ++ ++ ++ +openejb.check.classloader.verbose ++ ++ ++ +bool ++ ++ ++ +if true print classes intersections ++ ++ ++ ++ ++ +openejb.additional.exclude ++ ++ ++ +string separated by comma ++ ++ ++ +list of prefixes you want to exclude and are not in the default list of +exclusion ++ ++ ++ ++ ++ +openejb.additional.include ++ ++ ++ +string separated by comma ++ ++ ++ +list of prefixes you want to remove from thedefault list of exclusion ++ ++ ++ ++ ++ +openejb.offline ++ ++ ++ +bool ++ ++ ++ +if true can create datasources and containers automatically ++ ++ ++ ++ ++ +openejb.exclude-include.order ++ ++ ++ +include-exclude or exclude-include ++ ++ ++ +if the inclusion/exclusion should win on conflicts (intersection) ++ ++ ++ ++ ++ +openejb.log.color ++ ++ ++ +bool ++ ++ ++ +activate or not the color in the console in embedded mode ++ ++ ++ ++ ++ +openejb.log.color. ++ ++ ++ +color in uppercase ++ ++ ++ +set a color for a particular level. Color are BLACK, RED, GREEN, YELLOW, +BLUE, MAGENTA, CYAN, WHITE, DEFAULT. ++ ++ ++ ++ ++ +tomee.serialization.class.blacklist ++ ++ ++ +string ++ ++ ++ +default list of packages/classnames excluded for EJBd deserialization +(needs to be set on server and client sides). Please see the description +of Ejbd Transport for details. ++ ++ ++ ++ ++ +tomee.serialization.class.whitelist ++ ++ ++ +string ++ ++ ++ +default list of packages/classnames allowed for EJBd deserialization +(blacklist wins over whitelist, needs to be set on server and client +sides). Please see the description of Ejbd Transport for details. ++ ++ ++ ++ ++ +tomee.remote.support ++ ++ ++ +boolean ++ ++ ++ +if true /tomee webapp is auto-deployed and EJBd is active (true by +default for 1.x, false for 7.x excepted for tomee maven plugin and +arquillian) ++ ++ ++ + +Note: all resources can be configured by properties, see +http://tomee.apache.org/embedded-configuration.html and +http://tomee.apache.org/properties-tool.html + +== OpenEJB client + +Name + +Value + +Description + +openejb.client.identityResolver + +implementation of org.apache.openejb.client.IdentityResolver + +default org.apache.openejb.client.JaasIdentityResolver. The class to get +the client identity. + +openejb.client.connection.pool.timeout or +openejb.client.connectionpool.timeout + +int (ms) + +the timeout of the client + +openejb.client.connection.pool.size or +openejb.client.connectionpool.size + +int + +size of the socket pool + +openejb.client.keepalive + +int (ms) + +the keepalive duration + +openejb.client.protocol.version + +string + +Optional legacy server protocol compatibility level. Allows 4.6.x +clients to potentially communicate with older servers. OpenEJB 4.5.2 and +older use version "3.1", and 4.6.x currently uses version "4.6" +(Default). This does not allow old clients to communicate with new +servers prior to 4.6.0 + +== TomEE specific system properties + +Name + +Value + +Description + +openejb.crosscontext + +bool + +set the cross context property on tomcat context (can be done in the +traditionnal way if the deployment is don through the webapp discovery +and not the OpenEJB Deployer EJB) + +openejb.jsessionid-support + +bool + +remove URL from session tracking modes for this context (see +javax.servlet.SessionTrackingMode) + +openejb.myfaces.disable-default-values + +bool + +by default TomEE will initialize myfaces with some its default values to +avoid useless logging + +openejb.web.xml.major + +int + +major version of web.xml. Can be useful to force tomcat to scan servlet +3 annotatino when deploying with a servlet 2.x web.xml + +tomee.jaxws.subcontext + +string + +sub context used to bind jaxws web services, default is webservices + +openejb.servicemanager.enabled + +bool + +run all services detected or only known available services (WS and RS + +tomee.jaxws.oldsubcontext + +bool + +wether or not activate old way to bind jaxws webservices directly on +root context + +openejb.modulename.useHash + +bool + +add a hash after the module name of the webmodule if it is generated +from the webmodule location, it avoids conflicts between multiple +deployment (through ear) of the same webapp. Note: it disactivated by +default since names are less nice this way. + +openejb.session.manager + +qualified name (string) + +configure a session managaer to use for all contexts + +== TomEE Arquillian adaptor + +Name + +Value + +Description + +tomee.ejbcontainer.http.port + +int + +tomee port, -1 means random. When using a random port you can retreive +it getting this property too. + +tomee.arquillian.http + +int + +http port used by the embedded arquillian adaptor + +tomee.arquillian.stop + +int + +shutdown port used by the embedded arquillian adaptor diff --git a/docs/properties-listing.md b/docs/properties-listing.md deleted file mode 100644 index a207bd0f65f..00000000000 --- a/docs/properties-listing.md +++ /dev/null @@ -1,94 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=System Properties Listing -~~~~~~ - -# OpenEJB system properties - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameValueDescription
openejb.embedded.remotable bool activate or not the remote services when available
.bind, <service prefix>.port, <service prefix>.disabled, <service prefix>.threads host or IP, port, bool override the host. Available for ejbd and httpejbd services (used by jaxws and jaxrs), number of thread to maneg requests
openejb.embedded.initialcontext.close LOGOUT or DESTROY configure the hook called when closing the initial context. Useful when starting OpenEJB from a new InitialContext([properties]) instantiation. By default it simply logs out the logged user if it exists. DESTROY means clean the container.
javax.persistence.provider string override the JPA provider value
javax.persistence.transactionType string override the transaction type for persistence contexts
javax.persistence.jtaDataSource string override the JTA datasource value for persistence contexts
javax.persistence.nonJtaDataSource string override the non JTA datasource value for persistence contexts
openejb.descriptors.output bool dump memory deployment descriptors. Can be used to set complete metadata to true and avoid scanning when starting the container or to check the used configuration.
openejb.deployments.classpath.require.descriptor CLIENT or EJB can allow to filter what you want to scan (client modules or ejb modules)
openejb.descriptors.output.folder path where to dump deployement descriptors if activated.
openejb.strict.interface.declaration bool add some validations on session beans (spec validations in particular). false by default.
openejb.conf.file or openejb.configuration string OpenEJB configuration file path
openejb.debuggable-vm-hackery bool remove JMS informations from deployment
openejb.validation.skip bool skip the validations done when OpenEJB deploys beans
openejb.deployments.classpath.ear bool deploy the classpath as an ear
openejb.webservices.enabled bool activate or not webservices
openejb.validation.output.level TERSE or MEDIUM or VERBOSE level of the logs used to report validation errors
openejb.user.mbeans.list * or a list of classes separated by , list of mbeans to deploy automatically
openejb.deploymentId.format composition (+string) of {ejbName} {ejbType} {ejbClass} and {ejbClass.simpleName} default {ejbName}. The format to use to deploy ejbs.
openejb.deployments.classpath bool whether or not deploy from classpath
openejb.deployments.classpath.include and openejb.deployments.classpath.exclude regex regex to filter the scanned classpath (when you are in this case)
openejb.deployments.package.include and openejb.deployments.package.exclude regex regex to filter scanned packages
openejb.autocreate.jta-datasource-from-non-jta-one bool whether or not auto create the jta datasource if it doesn't exist but a non jta datasource exists. Useful when using hibernate to be able to get a real non jta datasource.
openejb.altdd.prefix string prefix use for altDD (example test to use a test.ejb-jar.xml).
org.apache.openejb.default.system.interceptors list of interceptor (qualified names) separated by a comma or a space add these interceptor on all beans
openejb.jndiname.strategy.class class name an implementation of org.apache.openejb.assembler.classic.JndiBuilder.JndiNameStrategy
openejb.jndiname.failoncollision bool if a NameAlreadyBoundException is thrown or not when 2 EJBs have the same name
openejb.jndiname.format composition (+string) of these properties: ejbType, ejbClass, ejbClass.simpleName, ejbClass.packageName, ejbName, deploymentId, interfaceType, interfaceType.annotationName, interfaceType.annotationNameLC, interfaceType.xmlName, interfaceType.xmlNameCc, interfaceType.openejbLegacyName, interfaceClass, interfaceClass.simpleName, interfaceClass.packageName default {deploymentId}{interfaceType.annotationName}. Change the name used for the ejb.
openejb.org.quartz.threadPool.class class qualified name which implements org.quartz.spi.ThreadPool the thread pool used by quartz (used to manage ejb timers)
openejb.localcopy bool default true. whether or not copy EJB arguments[/method/interface] for remote invocations.
openejb.cxf.jax-rs.providers the list of the qualified name of the JAX-RS providers separated by comma or space. Note: to specify a provider for a specific service suffix its class qualified name by ".providers", the value follow the same rules. Note 2: default is a shortcut for jaxb and json providers.
openejb.wsAddress.format composition (+string) of {ejbJarId}, ejbDeploymentId, ejbType, ejbClass, ejbClass.simpleName, ejbName, portComponentName, wsdlPort, wsdlService default /{ejbDeploymentId}. The WS name format.
org.apache.openejb.server.webservices.saaj.provider axis2, sun or null specified the saaj configuration
[<uppercase service name>.]<service id>.<name> or [<uppercase service name>.]<service id> whatever is supported (generally string, int ...) set this value to the corresponding service. example: [EnterpriseBean.]<ejb-name>.activation.<property>, [PERSISTENCEUNIT.]<persistence unit name>.<property>, [RESOURCE.]<name>
log4j.category.OpenEJB.options DEBUG, INFO, ... active one OpenEJB log level. need log4j in the classpath
openejb.jmx.active bool activate (by default) or not the OpenEJB JMX MBeans
openejb.nobanner bool activate or not the OpenEJB banner (activated by default) -
openejb.check.classloader bool if true print some information about duplicated classes
openejb.check.classloader.verbose bool if true print classes intersections
openejb.additional.exclude string separated by comma list of prefixes you want to exclude and are not in the default list of exclusion
openejb.additional.include string separated by comma list of prefixes you want to remove from thedefault list of exclusion
openejb.offline bool if true can create datasources and containers automatically
openejb.exclude-include.order include-exclude or exclude-include if the inclusion/exclusion should win on conflicts (intersection)
openejb.log.color bool activate or not the color in the console in embedded mode
openejb.log.color.<level in lowercase> color in uppercase set a color -for a particular level. Color are BLACK, RED, GREEN, YELLOW, BLUE, MAGENTA, CYAN, WHITE, DEFAULT.
tomee.serialization.class.blacklist string default list of packages/classnames excluded for EJBd deserialization (needs to be set on server and client sides). Please see the description of Ejbd Transport for details.
tomee.serialization.class.whitelist string default list of packages/classnames allowed for EJBd deserialization (blacklist wins over whitelist, needs to be set on server and client sides). Please see the description of Ejbd Transport for details.
tomee.remote.support boolean if true /tomee webapp is auto-deployed and EJBd is active (true by default for 1.x, false for 7.x excepted for tomee maven plugin and arquillian)
- -Note: all resources can be configured by properties, see http://tomee.apache.org/embedded-configuration.html and http://tomee.apache.org/properties-tool.html - - -# OpenEJB client - - - - - - - -
NameValueDescription
openejb.client.identityResolver implementation of org.apache.openejb.client.IdentityResolver default org.apache.openejb.client.JaasIdentityResolver. The class to get the client identity.
openejb.client.connection.pool.timeout or openejb.client.connectionpool.timeout int (ms) the timeout of the client
openejb.client.connection.pool.size or openejb.client.connectionpool.size int size of the socket pool
openejb.client.keepalive int (ms) the keepalive duration
openejb.client.protocol.version string Optional legacy server protocol compatibility level. Allows 4.6.x clients to potentially communicate with older servers. OpenEJB 4.5.2 and older use version "3.1", and 4.6.x currently uses version "4.6" (Default). This does not allow old clients to communicate with new servers prior to 4.6.0
- -# TomEE specific system properties - - - - - - - - - - - -
NameValueDescription
openejb.crosscontext bool set the cross context property on tomcat context (can be done in the traditionnal way if the deployment is don through the webapp discovery and not the OpenEJB Deployer EJB)
openejb.jsessionid-support bool remove URL from session tracking modes for this context (see javax.servlet.SessionTrackingMode)
openejb.myfaces.disable-default-values bool by default TomEE will initialize myfaces with some its default values to avoid useless logging
openejb.web.xml.major int major version of web.xml. Can be useful to force tomcat to scan servlet 3 annotatino when deploying with a servlet 2.x web.xml
tomee.jaxws.subcontext string sub context used to bind jaxws web services, default is webservices
openejb.servicemanager.enabled bool run all services detected or only known available services (WS and RS
tomee.jaxws.oldsubcontext bool wether or not activate old way to bind jaxws webservices directly on root context
openejb.modulename.useHash bool add a hash after the module name of the webmodule if it is generated from the webmodule location, it avoids conflicts between multiple deployment (through ear) of the same webapp. Note: it disactivated by default since names are less nice this way.
openejb.session.manager qualified name (string) configure a session managaer to use for all contexts
- -# TomEE Arquillian adaptor - - - - - -
NameValueDescription
tomee.ejbcontainer.http.port int tomee port, -1 means random. When using a random port you can retreive it getting this property too.
tomee.arquillian.http int http port used by the embedded arquillian adaptor
tomee.arquillian.stop int shutdown port used by the embedded arquillian adaptor
diff --git a/docs/properties-tool.adoc b/docs/properties-tool.adoc new file mode 100644 index 00000000000..aa376832a70 --- /dev/null +++ b/docs/properties-tool.adoc @@ -0,0 +1,219 @@ +:index-group: OpenEJB +Standalone Server +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published +:jbake-title: Properties Tool + +# Properties Command line Tool + +To see all configurable properties in use by OpenEJB, using the +following tool against a running server: + +________________________ +./bin/openejb properties +________________________ + +The output of this tool takes all overrideable components OpenEJB sees +and outputs their properties along with the current value. This allows +you to easily see what is running in your system, what properties are +available for overriding, and what exact values are for each component. +OpenEJB has a number of flags that can be passed to it not associated +with any particular component, these are output as well. + +Content from this file can be safely copied as-is into the +conf/system.properties file or sent to the users list with bug reports. +These properties may also be applied back into the openejb.xml file by +pasting the properties without the "." prefix into the respective +component declarations. The only warning is that any properties of type +".password" will have their values masked, so make sure you edit them if +you reapply them back into conf/openejb.xml or conf/system.properties. + +# Property Overriding + +Any component configured in OpenEJB via the openejb.xml (and some that +aren't) can be overridden using system properties. The format is: + +`.=` + +And this can be done on the command line as follows: + +`./bin/openejb -D.= ...` + +Or by adding the property to the conf/system.properties file. Note that +command line overrides win over overrides in the conf/system.properties +file. + +In an embedded environment, the properties can be added to the Hashtable +passed into the javax.naming.InitialContext when using the +LocalInitialContextFactory or also to the System.getProperties() object +before OpenEJB is embedded (which will be when the first InitialContext +is created). + +At startup, OpenEJB will find the component with the given id and apply +the new property value before constructing the individual component. + +# Example output + +.... +# Container(id=Default CMP Container) +# className: org.apache.openejb.core.cmp.CmpContainer +# +Default\ CMP\ Container.CmpEngineFactory=org.apache.openejb.core.cmp.jpa.JpaCmpEngineFactory +Default\ CMP\ Container.Engine=instantdb +Default\ CMP\ Container.ConnectorName=Default JDBC Database + +# Container(id=Default BMP Container) +# className: org.apache.openejb.core.entity.EntityContainer +# +Default\ BMP\ Container.PoolSize=10 + +# Container(id=Default Stateful Container) +# className: org.apache.openejb.core.stateful.StatefulContainer +# +Default\ Stateful\ Container.BulkPassivate=50 +Default\ Stateful\ Container.Passivator=org.apache.openejb.core.stateful.SimplePassivater +Default\ Stateful\ Container.TimeOut=20 +Default\ Stateful\ Container.PoolSize=500 + +# Container(id=Default Stateless Container) +# className: org.apache.openejb.core.stateless.StatelessContainer +# +Default\ Stateless\ Container.PoolSize=10 +Default\ Stateless\ Container.StrictPooling=true +Default\ Stateless\ Container.TimeOut=0 + +# Container(id=Default MDB Container) +# className: org.apache.openejb.core.mdb.MdbContainer +# +Default\ MDB\ Container.ResourceAdapter=Default JMS Resource Adapter +Default\ MDB\ Container.InstanceLimit=10 +Default\ MDB\ Container.MessageListenerInterface=javax.jms.MessageListener +Default\ MDB\ Container.ActivationSpecClass=org.apache.activemq.ra.ActiveMQActivationSpec + +# ConnectionManager(id=Default Local TX ConnectionManager) +# className: org.apache.openejb.resource.SharedLocalConnectionManager +# + +# Resource(id=Default JMS Resource Adapter) +# className: org.apache.activemq.ra.ActiveMQResourceAdapter +# +Default\ JMS\ Resource\ Adapter.ServerUrl=vm\://localhost?async\=true +Default\ JMS\ Resource\ Adapter.BrokerXmlConfig=broker\:(tcp\://localhost\:61616) +Default\ JMS\ Resource\ Adapter.ThreadPoolSize=30 + +# Resource(id=Default JDBC Database) +# className: org.apache.openejb.resource.jdbc.BasicManagedDataSource +# +Default\ JDBC\ Database.MinIdle=0 +Default\ JDBC\ Database.Password=xxxx +Default\ JDBC\ Database.JdbcUrl=jdbc\:hsqldb\:file\:hsqldb +Default\ JDBC\ Database.MaxIdle=20 +Default\ JDBC\ Database.ConnectionProperties= +Default\ JDBC\ Database.MaxWait=-1 +Default\ JDBC\ Database.TimeBetweenEvictionRunsMillis=-1 +Default\ JDBC\ Database.MaxActive=20 +Default\ JDBC\ Database.DefaultAutoCommit=true +Default\ JDBC\ Database.AccessToUnderlyingConnectionAllowed=false +Default\ JDBC\ Database.JdbcDriver=org.hsqldb.jdbcDriver +Default\ JDBC\ Database.TestWhileIdle=false +Default\ JDBC\ Database.UserName=sa +Default\ JDBC\ Database.MaxOpenPreparedStatements=0 +Default\ JDBC\ Database.TestOnBorrow=true +Default\ JDBC\ Database.PoolPreparedStatements=false +Default\ JDBC\ Database.ConnectionInterface=javax.sql.DataSource +Default\ JDBC\ Database.TestOnReturn=false +Default\ JDBC\ Database.MinEvictableIdleTimeMillis=1800000 +Default\ JDBC\ Database.NumTestsPerEvictionRun=3 +Default\ JDBC\ Database.InitialSize=0 + +# Resource(id=Default Unmanaged JDBC Database) +# className: org.apache.openejb.resource.jdbc.BasicDataSource +# +Default\ Unmanaged\ JDBC\ Database.MaxWait=-1 +Default\ Unmanaged\ JDBC\ Database.InitialSize=0 +Default\ Unmanaged\ JDBC\ Database.DefaultAutoCommit=true +Default\ Unmanaged\ JDBC\ Database.ConnectionProperties= +Default\ Unmanaged\ JDBC\ Database.MaxActive=10 +Default\ Unmanaged\ JDBC\ Database.TestOnBorrow=true +Default\ Unmanaged\ JDBC\ Database.JdbcUrl=jdbc\:hsqldb\:file\:hsqldb +Default\ Unmanaged\ JDBC\ Database.TestOnReturn=false +Default\ Unmanaged\ JDBC\ Database.AccessToUnderlyingConnectionAllowed=false +Default\ Unmanaged\ JDBC\ Database.Password=xxxx +Default\ Unmanaged\ JDBC\ Database.MinEvictableIdleTimeMillis=1800000 +Default\ Unmanaged\ JDBC\ Database.PoolPreparedStatements=false +Default\ Unmanaged\ JDBC\ Database.MaxOpenPreparedStatements=0 +Default\ Unmanaged\ JDBC\ Database.ConnectionInterface=javax.sql.DataSource +Default\ Unmanaged\ JDBC\ Database.MinIdle=0 +Default\ Unmanaged\ JDBC\ Database.NumTestsPerEvictionRun=3 +Default\ Unmanaged\ JDBC\ Database.TimeBetweenEvictionRunsMillis=-1 +Default\ Unmanaged\ JDBC\ Database.JdbcDriver=org.hsqldb.jdbcDriver +Default\ Unmanaged\ JDBC\ Database.UserName=sa +Default\ Unmanaged\ JDBC\ Database.MaxIdle=10 +Default\ Unmanaged\ JDBC\ Database.TestWhileIdle=false + +# Resource(id=Default JMS Connection Factory) +# className: org.apache.activemq.ra.ActiveMQManagedConnectionFactory +# +Default\ JMS\ Connection\ Factory.ConnectionInterface=javax.jms.ConnectionFactory, \ +javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory +Default\ JMS\ Connection\ Factory.ResourceAdapter=Default JMS Resource Adapter + +# SecurityService(id=Default Security Service) +# className: org.apache.openejb.core.security.SecurityServiceImpl +# + +# TransactionManager(id=Default Transaction Manager) +# className: org.apache.geronimo.transaction.manager.GeronimoTransactionManager +# + +# ServerService(id=httpejbd) +# className: org.apache.openejb.server.httpd.HttpEjbServer +# +httpejbd.port=4204 +httpejbd.name=httpejbd +httpejbd.disabled=false +httpejbd.server=org.apache.openejb.server.httpd.HttpEjbServer +httpejbd.threads=200 +httpejbd.bind=127.0.0.1 + +# ServerService(id=telnet) +# className: org.apache.openejb.server.telnet.TelnetServer +# +telnet.port=4202 +telnet.name=telnet +telnet.disabled=false +telnet.bind=127.0.0.1 +telnet.threads=5 +telnet.server=org.apache.openejb.server.telnet.TelnetServer + +# ServerService(id=ejbd) +# className: org.apache.openejb.server.ejbd.EjbServer +# +ejbd.disabled=false +ejbd.bind=127.0.0.1 +ejbd.server=org.apache.openejb.server.ejbd.EjbServer +ejbd.port=4201 +ejbd.name=ejbd +ejbd.threads=200 + +# ServerService(id=hsql) +# className: org.apache.openejb.server.hsql.HsqlService +# +hsql.port=9001 +hsql.name=hsql +hsql.disabled=false +hsql.server=org.apache.openejb.server.hsql.HsqlService +hsql.bind=127.0.0.1 + +# ServerService(id=admin) +# className: org.apache.openejb.server.admin.AdminDaemon +# +admin.disabled=false +admin.bind=127.0.0.1 +admin.only_from=localhost +admin.port=4200 +admin.threads=1 +admin.name=admin +admin.server=org.apache.openejb.server.admin.AdminDaemon +.... diff --git a/docs/properties-tool.md b/docs/properties-tool.md deleted file mode 100644 index 07531ef7bac..00000000000 --- a/docs/properties-tool.md +++ /dev/null @@ -1,216 +0,0 @@ -index-group=OpenEJB Standalone Server -type=page -status=published -title=Properties Tool -~~~~~~ - -# Properties Command line Tool - -To see all configurable properties in use by OpenEJB, using the following -tool against a running server: - -> ./bin/openejb properties - -The output of this tool takes all overrideable components OpenEJB sees and -outputs their properties along with the current value. This allows you to -easily see what is running in your system, what properties are available -for overriding, and what exact values are for each component. OpenEJB has -a number of flags that can be passed to it not associated with any -particular component, these are output as well. - -Content from this file can be safely copied as-is into the -conf/system.properties file or sent to the users list with bug reports. -These properties may also be applied back into the openejb.xml file by -pasting the properties without the "." prefix into the respective -component declarations. The only warning is that any properties of type -".password" will have their values masked, so make sure you edit them -if you reapply them back into conf/openejb.xml or conf/system.properties. - - -# Property Overriding - -Any component configured in OpenEJB via the openejb.xml (and some that -aren't) can be overridden using system properties. The format is: - -`.=` - -And this can be done on the command line as follows: - -`./bin/openejb -D.= ...` - -Or by adding the property to the conf/system.properties file. Note that -command line overrides win over overrides in the -conf/system.properties file. - -In an embedded environment, the properties can be added to the Hashtable -passed into the javax.naming.InitialContext when using the -LocalInitialContextFactory or also to the System.getProperties() object -before OpenEJB is embedded (which will be when the first InitialContext is -created). - -At startup, OpenEJB will find the component with the given id and apply the -new property value before constructing the individual component. - - -# Example output - - # Container(id=Default CMP Container) - # className: org.apache.openejb.core.cmp.CmpContainer - # - Default\ CMP\ Container.CmpEngineFactory=org.apache.openejb.core.cmp.jpa.JpaCmpEngineFactory - Default\ CMP\ Container.Engine=instantdb - Default\ CMP\ Container.ConnectorName=Default JDBC Database - - # Container(id=Default BMP Container) - # className: org.apache.openejb.core.entity.EntityContainer - # - Default\ BMP\ Container.PoolSize=10 - - # Container(id=Default Stateful Container) - # className: org.apache.openejb.core.stateful.StatefulContainer - # - Default\ Stateful\ Container.BulkPassivate=50 - Default\ Stateful\ Container.Passivator=org.apache.openejb.core.stateful.SimplePassivater - Default\ Stateful\ Container.TimeOut=20 - Default\ Stateful\ Container.PoolSize=500 - - # Container(id=Default Stateless Container) - # className: org.apache.openejb.core.stateless.StatelessContainer - # - Default\ Stateless\ Container.PoolSize=10 - Default\ Stateless\ Container.StrictPooling=true - Default\ Stateless\ Container.TimeOut=0 - - # Container(id=Default MDB Container) - # className: org.apache.openejb.core.mdb.MdbContainer - # - Default\ MDB\ Container.ResourceAdapter=Default JMS Resource Adapter - Default\ MDB\ Container.InstanceLimit=10 - Default\ MDB\ Container.MessageListenerInterface=javax.jms.MessageListener - Default\ MDB\ Container.ActivationSpecClass=org.apache.activemq.ra.ActiveMQActivationSpec - - # ConnectionManager(id=Default Local TX ConnectionManager) - # className: org.apache.openejb.resource.SharedLocalConnectionManager - # - - # Resource(id=Default JMS Resource Adapter) - # className: org.apache.activemq.ra.ActiveMQResourceAdapter - # - Default\ JMS\ Resource\ Adapter.ServerUrl=vm\://localhost?async\=true - Default\ JMS\ Resource\ Adapter.BrokerXmlConfig=broker\:(tcp\://localhost\:61616) - Default\ JMS\ Resource\ Adapter.ThreadPoolSize=30 - - # Resource(id=Default JDBC Database) - # className: org.apache.openejb.resource.jdbc.BasicManagedDataSource - # - Default\ JDBC\ Database.MinIdle=0 - Default\ JDBC\ Database.Password=xxxx - Default\ JDBC\ Database.JdbcUrl=jdbc\:hsqldb\:file\:hsqldb - Default\ JDBC\ Database.MaxIdle=20 - Default\ JDBC\ Database.ConnectionProperties= - Default\ JDBC\ Database.MaxWait=-1 - Default\ JDBC\ Database.TimeBetweenEvictionRunsMillis=-1 - Default\ JDBC\ Database.MaxActive=20 - Default\ JDBC\ Database.DefaultAutoCommit=true - Default\ JDBC\ Database.AccessToUnderlyingConnectionAllowed=false - Default\ JDBC\ Database.JdbcDriver=org.hsqldb.jdbcDriver - Default\ JDBC\ Database.TestWhileIdle=false - Default\ JDBC\ Database.UserName=sa - Default\ JDBC\ Database.MaxOpenPreparedStatements=0 - Default\ JDBC\ Database.TestOnBorrow=true - Default\ JDBC\ Database.PoolPreparedStatements=false - Default\ JDBC\ Database.ConnectionInterface=javax.sql.DataSource - Default\ JDBC\ Database.TestOnReturn=false - Default\ JDBC\ Database.MinEvictableIdleTimeMillis=1800000 - Default\ JDBC\ Database.NumTestsPerEvictionRun=3 - Default\ JDBC\ Database.InitialSize=0 - - # Resource(id=Default Unmanaged JDBC Database) - # className: org.apache.openejb.resource.jdbc.BasicDataSource - # - Default\ Unmanaged\ JDBC\ Database.MaxWait=-1 - Default\ Unmanaged\ JDBC\ Database.InitialSize=0 - Default\ Unmanaged\ JDBC\ Database.DefaultAutoCommit=true - Default\ Unmanaged\ JDBC\ Database.ConnectionProperties= - Default\ Unmanaged\ JDBC\ Database.MaxActive=10 - Default\ Unmanaged\ JDBC\ Database.TestOnBorrow=true - Default\ Unmanaged\ JDBC\ Database.JdbcUrl=jdbc\:hsqldb\:file\:hsqldb - Default\ Unmanaged\ JDBC\ Database.TestOnReturn=false - Default\ Unmanaged\ JDBC\ Database.AccessToUnderlyingConnectionAllowed=false - Default\ Unmanaged\ JDBC\ Database.Password=xxxx - Default\ Unmanaged\ JDBC\ Database.MinEvictableIdleTimeMillis=1800000 - Default\ Unmanaged\ JDBC\ Database.PoolPreparedStatements=false - Default\ Unmanaged\ JDBC\ Database.MaxOpenPreparedStatements=0 - Default\ Unmanaged\ JDBC\ Database.ConnectionInterface=javax.sql.DataSource - Default\ Unmanaged\ JDBC\ Database.MinIdle=0 - Default\ Unmanaged\ JDBC\ Database.NumTestsPerEvictionRun=3 - Default\ Unmanaged\ JDBC\ Database.TimeBetweenEvictionRunsMillis=-1 - Default\ Unmanaged\ JDBC\ Database.JdbcDriver=org.hsqldb.jdbcDriver - Default\ Unmanaged\ JDBC\ Database.UserName=sa - Default\ Unmanaged\ JDBC\ Database.MaxIdle=10 - Default\ Unmanaged\ JDBC\ Database.TestWhileIdle=false - - # Resource(id=Default JMS Connection Factory) - # className: org.apache.activemq.ra.ActiveMQManagedConnectionFactory - # - Default\ JMS\ Connection\ Factory.ConnectionInterface=javax.jms.ConnectionFactory, \ - javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory - Default\ JMS\ Connection\ Factory.ResourceAdapter=Default JMS Resource Adapter - - # SecurityService(id=Default Security Service) - # className: org.apache.openejb.core.security.SecurityServiceImpl - # - - # TransactionManager(id=Default Transaction Manager) - # className: org.apache.geronimo.transaction.manager.GeronimoTransactionManager - # - - # ServerService(id=httpejbd) - # className: org.apache.openejb.server.httpd.HttpEjbServer - # - httpejbd.port=4204 - httpejbd.name=httpejbd - httpejbd.disabled=false - httpejbd.server=org.apache.openejb.server.httpd.HttpEjbServer - httpejbd.threads=200 - httpejbd.bind=127.0.0.1 - - # ServerService(id=telnet) - # className: org.apache.openejb.server.telnet.TelnetServer - # - telnet.port=4202 - telnet.name=telnet - telnet.disabled=false - telnet.bind=127.0.0.1 - telnet.threads=5 - telnet.server=org.apache.openejb.server.telnet.TelnetServer - - # ServerService(id=ejbd) - # className: org.apache.openejb.server.ejbd.EjbServer - # - ejbd.disabled=false - ejbd.bind=127.0.0.1 - ejbd.server=org.apache.openejb.server.ejbd.EjbServer - ejbd.port=4201 - ejbd.name=ejbd - ejbd.threads=200 - - # ServerService(id=hsql) - # className: org.apache.openejb.server.hsql.HsqlService - # - hsql.port=9001 - hsql.name=hsql - hsql.disabled=false - hsql.server=org.apache.openejb.server.hsql.HsqlService - hsql.bind=127.0.0.1 - - # ServerService(id=admin) - # className: org.apache.openejb.server.admin.AdminDaemon - # - admin.disabled=false - admin.bind=127.0.0.1 - admin.only_from=localhost - admin.port=4200 - admin.threads=1 - admin.name=admin - admin.server=org.apache.openejb.server.admin.AdminDaemon diff --git a/docs/property-overriding.adoc b/docs/property-overriding.adoc new file mode 100644 index 00000000000..00cda3482f1 --- /dev/null +++ b/docs/property-overriding.adoc @@ -0,0 +1,64 @@ +# Property Overriding +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + +OpenEJB consists of several components (containers, +resource adapters, security services, etc.) all of which are pluggable +and have their own unique set of configurable properties. These +components are required to specify their default property values in +their service-jar.xml file. This means that at a minimum you as a user +only need to specify what you'd like to be different. You specify the +property name and the new value and the default value will be +overwritten before the component is created. + +We call this overriding and there are several ways to do it. + +# The openejb.xml + +The default openejb.xml file has most of the useful properties for each +component explicitly listed with default values for documentation +purposes. It is safe to delete them and be assured that no behavior will +change if a smaller config file is desired. + +Overriding can also be done via the command line or plain Java system +properties. See link:system-properties.html[System Properties] for +details. + +== What properties are available? + +To know what properties can be overriden the './bin/openejb properties' +command is very useful: see link:properties-tool.html[Properties Tool] + +It's function is to connect to a running server and print a canonical +list of all properties OpenEJB can see via the various means of +configuration. When sending requests for help to the users list or jira, +it is highly encouraged to send the output of this tool with your +message. + +== Not configurable via openejb.xml + +The only thing not yet configurable via this file are ServerServices due +to OpenEJB's embeddable nature and resulting long standing tradition of +keeping the container system separate from the server layer. This may +change someday, but untill then ServerServices are configurable via +conf/.properties files such as conf/ejbd.properties to configure the +main protocol that services EJB client requests. + +The format those properties files is greatly adapted from the xinet.d +style of configuration and even shares similar functionality and +properties such as host-based authorization (HBA) via the 'only_from' +property. + +== Restoring openejb.xml to the defaults + +To restore this file to its original default state, you can simply +delete it or rename it and OpenEJB will see it's missing and unpack +another openejb.xml into the conf/ directory when it starts. + +This is not only handy for recovering from a non-functional config, but +also for upgrading as OpenEJB will not overwrite your existing +configuration file should you choose to unpack an new distro over the +top of an old one -- this style of upgrade is safe provided you move +your old lib/ directory first. diff --git a/docs/property-overriding.md b/docs/property-overriding.md deleted file mode 100644 index 0a45e283eca..00000000000 --- a/docs/property-overriding.md +++ /dev/null @@ -1,65 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=Property Overriding -~~~~~~ -OpenEJB consists of several components (containers, resource adapters, -security services, etc.) all of which are pluggable and have their own -unique set of configurable properties. These components are required to -specify their default property values in their service-jar.xml file. This -means that at a minimum you as a user only need to specify what you'd like -to be different. You specify the property name and the new value and the -default value will be overwritten before the component is created. - -We call this overriding and there are several ways to do it. - - -# The openejb.xml - -The default openejb.xml file has most of the useful properties for each -component explicitly listed with default values for documentation purposes. - It is safe to delete them and be assured that no behavior will change if a -smaller config file is desired. - - -Overriding can also be done via the command line or plain Java system -properties. See [System Properties](system-properties.html) - for details. - - -## What properties are available? - -To know what properties can be overriden the './bin/openejb properties' -command is very useful: see [Properties Tool](properties-tool.html) - -It's function is to connect to a running server and print a canonical list -of all properties OpenEJB can see via the various means of configuration. -When sending requests for help to the users list or jira, it is highly -encouraged to send the output of this tool with your message. - - -## Not configurable via openejb.xml - -The only thing not yet configurable via this file are ServerServices due to -OpenEJB's embeddable nature and resulting long standing tradition of -keeping the container system separate from the server layer. This may -change someday, but untill then ServerServices are configurable via -conf/.properties files such as conf/ejbd.properties to -configure the main protocol that services EJB client requests. - -The format those properties files is greatly adapted from the xinet.d style -of configuration and even shares similar functionality and properties such -as host-based authorization (HBA) via the 'only_from' property. - - -## Restoring openejb.xml to the defaults - -To restore this file to its original default state, you can simply delete -it or rename it and OpenEJB will see it's missing and unpack another -openejb.xml into the conf/ directory when it starts. - -This is not only handy for recovering from a non-functional config, but -also for upgrading as OpenEJB will not overwrite your existing -configuration file should you choose to unpack an new distro over the top -of an old one -- this style of upgrade is safe provided you move your old -lib/ directory first. diff --git a/docs/provisioning.adoc b/docs/provisioning.adoc new file mode 100644 index 00000000000..306ff734a54 --- /dev/null +++ b/docs/provisioning.adoc @@ -0,0 +1,96 @@ +# TomEE/OpenEJB provisioning +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +== Summary + +Provioning is about the way to get binaries or information. It is the +answer to how do i get my application, my webapp, my configuration. + +TomEE and OpenEJB brings some help about it allowing you to point out +some resources instead of providing it directly. + +This indirection is clearly very useful to industrialize your software +or simply to cloudify it. + +== A word about this page + +This page will not explain you how to deploy an application or how to +enhance your container. It will simply explain you how which kind of +urls are supported for such features. + +These feature are explained in other places. + +== Supported provionings + +=== file + +This is the default and well know provisioning. Simply give a file path +the container is able to access through its filesystem. + +Example: + +.... +/MIDDLE/foo/bar/my-local-file.jar +.... + +=== Http/https + +Here you give an url to access the desired file. Proxies used are the +JVM ones. + +Example: + +.... +http://atos.net/foo/bar/my-http-file.jar +.... + +=== Maven + +==== Usage + +Probably the most fun but very useful for cloud deployments: maven. Use +maven informations to deploy your application. + +The location should follow: + +.... +mvn:groupId/artifactId[/[version]/[type]] +.... + +or + +.... +mvn:groupId:artifactId[:[version]:[type]] +.... + +Note: classifier are supported (through version field) + +For instance you can use: + +.... +mvn:net.atos.xa/my-application/1.0.0/war +.... + +==== Installation + +The maven url parsing is not included by default in OpenEJB/TomEE +bundle. It needs to be installed. + +If you are using an embedded application and maven simply add +org.apache.openejb:openejb-provisionning:VERSION dependency. + +If you are using TomEE you have to extract the +org.apache.openejb:openejb-provisionning zip in the same classloader +than tomee (webapps/tomee/lib for instance, for other places please have +a look to other tip pages). + +Another way to install it with tomee is to edit or create the file +/conf/provisioning.properties and add the line: + +.... +zip=http://repo1.maven.org/maven2/org/apache/openejb/openejb-provisionning//openejb-provisionning-.zip +.... diff --git a/docs/provisioning.md b/docs/provisioning.md deleted file mode 100644 index ce1fd095dff..00000000000 --- a/docs/provisioning.md +++ /dev/null @@ -1,78 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=TomEE/OpenEJB provisioning -~~~~~~ - -# Summary - -Provioning is about the way to get binaries or information. It is the answer to -how do i get my application, my webapp, my configuration. - -TomEE and OpenEJB brings some help about it allowing you to point out some -resources instead of providing it directly. - -This indirection is clearly very useful to industrialize your software -or simply to cloudify it. - -# A word about this page - -This page will not explain you how to deploy an application or -how to enhance your container. It will simply explain you how which -kind of urls are supported for such features. - -These feature are explained in other places. - -# Supported provionings -## file - -This is the default and well know provisioning. Simply give a -file path the container is able to access through its filesystem. - -Example: - - /MIDDLE/foo/bar/my-local-file.jar - -## Http/https - -Here you give an url to access the desired file. Proxies used are the JVM ones. - -Example: - - http://atos.net/foo/bar/my-http-file.jar - -## Maven -### Usage - -Probably the most fun but very useful for cloud deployments: maven. -Use maven informations to deploy your application. - -The location should follow: - - mvn:groupId/artifactId[/[version]/[type]] - -or - - mvn:groupId:artifactId[:[version]:[type]] - -Note: classifier are supported (through version field) - -For instance you can use: - - mvn:net.atos.xa/my-application/1.0.0/war - -### Installation - -The maven url parsing is not included by default in OpenEJB/TomEE bundle. It needs to be installed. - -If you are using an embedded application and maven simply add -org.apache.openejb:openejb-provisionning:VERSION dependency. - -If you are using TomEE you have to extract the org.apache.openejb:openejb-provisionning zip -in the same classloader than tomee (webapps/tomee/lib for instance, for other places please have -a look to other tip pages). - -Another way to install it with tomee is to edit or create the file /conf/provisioning.properties -and add the line: - - zip=http://repo1.maven.org/maven2/org/apache/openejb/openejb-provisionning//openejb-provisionning-.zip diff --git a/docs/proxyfactory-config.adoc b/docs/proxyfactory-config.adoc new file mode 100644 index 00000000000..d970fa6841c --- /dev/null +++ b/docs/proxyfactory-config.adoc @@ -0,0 +1,42 @@ +# ProxyFactory Configuration +:index-group: Unrevised +:jbake-date: 2018-12-05 +:jbake-type: page +:jbake-status: published + + +A ProxyFactory can be declared via xml in the +`/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. + +.... + + +.... + +Alternatively, a ProxyFactory can be declared via properties in the +`/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` + +.... +myProxyFactory = new://ProxyFactory?type=ProxyFactory +.... + +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 ProxyFactory a +warning will be logged. If a ProxyFactory is needed by the application +and one is not declared, TomEE will create one dynamically using default +settings. Multiple ProxyFactory declarations are allowed. # Supported +Properties + +Property + +Type + +Default + +Description diff --git a/docs/proxyfactory-config.md b/docs/proxyfactory-config.md deleted file mode 100644 index 716a5f4b993..00000000000 --- a/docs/proxyfactory-config.md +++ /dev/null @@ -1,26 +0,0 @@ -index-group=Unrevised -type=page -status=published -title=ProxyFactory Configuration -~~~~~~ - - -A ProxyFactory can be declared via xml in the `/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. - - - - -Alternatively, a ProxyFactory can be declared via properties in the `/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` - - myProxyFactory = new://ProxyFactory?type=ProxyFactory - -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 ProxyFactory a warning will be logged. If a ProxyFactory is needed by the application and one is not declared, TomEE will create one dynamically using default settings. Multiple ProxyFactory declarations are allowed. -# Supported Properties - - - - - - - -
PropertyTypeDefaultDescription
From 05b3c8378ec37d0f5d8fa55aec8f8bc3a1d87e6d Mon Sep 17 00:00:00 2001 From: Carlos Chacin Date: Wed, 5 Dec 2018 23:06:57 -0800 Subject: [PATCH 2/2] TOMEE-2316 Convert Markdown files to Asciidoc in the docs folder - 8 --- docs/multicast-discovery.adoc | 5 ++--- docs/multipoint-considerations.adoc | 5 ++--- docs/multipoint-discovery.adoc | 5 ++--- docs/multipoint-recommendations.adoc | 5 ++--- docs/multipulse-discovery.adoc | 5 ++--- docs/new-in-openejb-3.0.adoc | 5 ++--- docs/openejb.xml.adoc | 4 ++-- docs/properties-tool.adoc | 5 ++--- 8 files changed, 16 insertions(+), 23 deletions(-) diff --git a/docs/multicast-discovery.adoc b/docs/multicast-discovery.adoc index 6fd67f4d60c..fd6d5308b53 100644 --- a/docs/multicast-discovery.adoc +++ b/docs/multicast-discovery.adoc @@ -1,9 +1,8 @@ -:index-group: Discovery -and Failover +# Multicast (UDP) Discovery +: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 diff --git a/docs/multipoint-considerations.adoc b/docs/multipoint-considerations.adoc index 24d36440fb1..e232020c96b 100644 --- a/docs/multipoint-considerations.adoc +++ b/docs/multipoint-considerations.adoc @@ -1,9 +1,8 @@ -:index-group: Discovery -and Failover +# Multipoint Considerations +:index-group: Discovery and Failover :jbake-date: 2018-12-05 :jbake-type: page :jbake-status: published -:jbake-title: Multipoint Considerations == Network size diff --git a/docs/multipoint-discovery.adoc b/docs/multipoint-discovery.adoc index a8a4daade61..171ee4621aa 100644 --- a/docs/multipoint-discovery.adoc +++ b/docs/multipoint-discovery.adoc @@ -1,9 +1,8 @@ -:index-group: Discovery -and Failover +# Multipoint (TCP) Discovery +: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 diff --git a/docs/multipoint-recommendations.adoc b/docs/multipoint-recommendations.adoc index 97644796809..5b93ee9b9a8 100644 --- a/docs/multipoint-recommendations.adoc +++ b/docs/multipoint-recommendations.adoc @@ -1,9 +1,8 @@ -:index-group: Discovery -and Failover +# Multipoint Recommendations +: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 diff --git a/docs/multipulse-discovery.adoc b/docs/multipulse-discovery.adoc index 63d6518c8db..ec2fd38362f 100644 --- a/docs/multipulse-discovery.adoc +++ b/docs/multipulse-discovery.adoc @@ -1,9 +1,8 @@ -:index-group: Discovery -and Failover +# MultiPulse (UDP) Discovery +: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 diff --git a/docs/new-in-openejb-3.0.adoc b/docs/new-in-openejb-3.0.adoc index f5d871f6ded..204064924fa 100644 --- a/docs/new-in-openejb-3.0.adoc +++ b/docs/new-in-openejb-3.0.adoc @@ -1,10 +1,9 @@ -:jbake-title: New in OpenEJB 3.0 +# New in OpenEJB 3.0 :jbake-date: 2018-12-05 :jbake-type: page :jbake-status: published - -# EJB 3.0 +## 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: diff --git a/docs/openejb.xml.adoc b/docs/openejb.xml.adoc index 00dd7f678c8..258c49dd12d 100644 --- a/docs/openejb.xml.adoc +++ b/docs/openejb.xml.adoc @@ -1,10 +1,10 @@ -:jbake-title: openejb.xml +# openejb.xml :jbake-date: 2018-12-05 :jbake-type: page :jbake-status: published -# Overview +## Overview The openejb.xml is the main configuration file for the container system and its services such as transaction, security, and data sources. diff --git a/docs/properties-tool.adoc b/docs/properties-tool.adoc index aa376832a70..90fa8ecdfa7 100644 --- a/docs/properties-tool.adoc +++ b/docs/properties-tool.adoc @@ -1,9 +1,8 @@ -:index-group: OpenEJB -Standalone Server +# Properties Tool +:index-group: OpenEJB Standalone Server :jbake-date: 2018-12-05 :jbake-type: page :jbake-status: published -:jbake-title: Properties Tool # Properties Command line Tool