You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by jl...@apache.org on 2018/12/06 08:52:53 UTC
[08/44] tomee git commit: TOMEE-2316 Convert Markdown files to
Asciidoc in the docs folder - 5
TOMEE-2316 Convert Markdown files to Asciidoc in the docs folder - 5
Project: http://git-wip-us.apache.org/repos/asf/tomee/repo
Commit: http://git-wip-us.apache.org/repos/asf/tomee/commit/6bbcdc10
Tree: http://git-wip-us.apache.org/repos/asf/tomee/tree/6bbcdc10
Diff: http://git-wip-us.apache.org/repos/asf/tomee/diff/6bbcdc10
Branch: refs/heads/master
Commit: 6bbcdc10d2b8fd9cdf56208b4b42e6813c85f66d
Parents: 388460f
Author: Carlos Chacin <cc...@gmail.com>
Authored: Wed Dec 5 22:07:21 2018 -0800
Committer: Carlos Chacin <cc...@gmail.com>
Committed: Wed Dec 5 22:07:21 2018 -0800
----------------------------------------------------------------------
docs/eclipse-plugin.adoc | 41 ++++
docs/eclipse-plugin.md | 42 ----
docs/ejb-failover.adoc | 94 +++++++
docs/ejb-failover.md | 89 -------
docs/ejb-local-ref.adoc | 54 +++++
docs/ejb-local-ref.md | 52 ----
docs/ejb-over-ssl.adoc | 132 ++++++++++
docs/ejb-over-ssl.md | 100 --------
docs/ejb-ref.adoc | 53 ++++
docs/ejb-ref.md | 50 ----
docs/ejb-refs.adoc | 190 +++++++++++++++
docs/ejb-refs.md | 178 --------------
docs/ejb-request-logging.adoc | 155 ++++++++++++
docs/ejb-request-logging.md | 98 --------
docs/ejbd-transport.adoc | 205 ++++++++++++++++
docs/ejbd-transport.md | 136 -----------
docs/embedded-and-remotable.adoc | 175 +++++++++++++
docs/embedded-and-remotable.md | 181 --------------
docs/embedded-configuration.adoc | 135 +++++++++++
docs/embedded-configuration.md | 135 -----------
docs/embedding.adoc | 34 +++
docs/embedding.md | 30 ---
docs/failover-logging.adoc | 54 +++++
docs/failover-logging.md | 42 ----
docs/faq.adoc | 105 ++++++++
docs/faq.md | 99 --------
docs/features.adoc | 6 +
docs/features.md | 6 -
docs/from-glassfish-to-tomee.adoc | 11 +
docs/from-glassfish-to-tomee.md | 7 -
...esting-with-openejb,-jetty-and-selenium.adoc | 243 +++++++++++++++++++
...-testing-with-openejb,-jetty-and-selenium.md | 240 ------------------
32 files changed, 1687 insertions(+), 1485 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/eclipse-plugin.adoc
----------------------------------------------------------------------
diff --git a/docs/eclipse-plugin.adoc b/docs/eclipse-plugin.adoc
new file mode 100644
index 0000000..5bf8e39
--- /dev/null
+++ b/docs/eclipse-plugin.adoc
@@ -0,0 +1,41 @@
+# Eclipse Plugin
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+# What is it?
+
+The _OpenEJB Eclipse Plugin_ will be a suite of tools made available via
+Eclipse to make EJB development with OpenEJB easier. The initial
+offering will probably provide basic functionality by taking advantage
+of http://www.eclipse.org/webtools[WebTools] to allow for OpenEJB to be
+an available container/runtime within Eclipse. This means full debugging
+and Eclipse project integration. From there, the sky is the limit so
+feel free to suggest features on the [OpenEJB Dev list|Mailing
+Lists#MailingLists-DeveloperMailingList] .
+
+# How to get involved?
+
+Just the same as getting involved with any part of OpenEJB -- send a
+mail to the
+link:mailing-lists#mailinglists-developermailinglist.html[OpenEJB Dev
+list] and say "Hi!" We're a very relaxed group so no need to be perfect
+or overly prepared. Just dive right in, we're always happy to have more.
+
+# Where do I get it?
+
+The initiative is just launching, but you can grab what we have right
+here and start hacking.
+
+http://svn.apache.org/repos/asf/tomee/openejb-eclipse-plugin/trunk/
+
+# What do I need to help?
+
+http://www.eclipse.org[Eclipse] http://www.eclipse.org/webtools[Eclipse
+Web Tools]
+
+# Resources
+
+http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3581[EclipseCon
+Presentation for Extending WTP]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/eclipse-plugin.md
----------------------------------------------------------------------
diff --git a/docs/eclipse-plugin.md b/docs/eclipse-plugin.md
deleted file mode 100644
index dd85c45..0000000
--- a/docs/eclipse-plugin.md
+++ /dev/null
@@ -1,42 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=Eclipse Plugin
-~~~~~~
-<a name="EclipsePlugin-Whatisit?"></a>
-# What is it?
-
-The *OpenEJB Eclipse Plugin* will be a suite of tools made available via
-Eclipse to make EJB development with OpenEJB easier. The initial offering
-will probably provide basic functionality by taking advantage of [WebTools](http://www.eclipse.org/webtools)
- to allow for OpenEJB to be an available container/runtime within Eclipse.
-This means full debugging and Eclipse project integration. From there, the
-sky is the limit so feel free to suggest features on the [OpenEJB Dev list|Mailing Lists#MailingLists-DeveloperMailingList]
-.
-
-<a name="EclipsePlugin-Howtogetinvolved?"></a>
-# How to get involved?
-
-Just the same as getting involved with any part of OpenEJB -- send a mail
-to the [OpenEJB Dev list](mailing-lists#mailinglists-developermailinglist.html)
- and say "Hi!" We're a very relaxed group so no need to be perfect or
-overly prepared. Just dive right in, we're always happy to have more.
-
-<a name="EclipsePlugin-WheredoIgetit?"></a>
-# Where do I get it?
-
-The initiative is just launching, but you can grab what we have right here
-and start hacking.
-
- http://svn.apache.org/repos/asf/tomee/openejb-eclipse-plugin/trunk/
-
-<a name="EclipsePlugin-WhatdoIneedtohelp?"></a>
-# What do I need to help?
-
- [Eclipse](http://www.eclipse.org)
- [Eclipse Web Tools](http://www.eclipse.org/webtools)
-
-<a name="EclipsePlugin-Resources"></a>
-# Resources
-
- [EclipseCon Presentation for Extending WTP](http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=3581)
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-failover.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-failover.adoc b/docs/ejb-failover.adoc
new file mode 100644
index 0000000..04f0ee3
--- /dev/null
+++ b/docs/ejb-failover.adoc
@@ -0,0 +1,94 @@
+:index-group: Discovery
+and Failover
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+:jbake-title: EJB Client/Server Failover
+
+
+OpenEJB supports stateless failover. Specifically, the ability for an
+EJB client to failover from one server to the next if a request cannot
+be completed. No application state information is communicated between
+the servers, so this functionality should be used only with applications
+that are inherently stateless. A common term for this sort of setup is a
+server farm.
+
+The basic design assumption is that all servers in the same group have
+the same applications deployed and are capable of doing the same job.
+Servers can be brought online and offline while clients are running. As
+members join/leave this information is sent to the client as part of
+normal EJB request/response communication so active clients always have
+the most current information on servers that can process their request
+should communication with a particular server fail.
+
+== Client Behavior
+
+On each request to the server, the client will send the version number
+associated with the list of servers in the cluster it is aware of.
+Initially this version will be zero and the list will be empty. Only
+when the server sees the client has an old list will the server send the
+updated list. This is an important distinction as the list is not
+transmitted back and forth on every request, only on change. If the
+membership of the cluster is stable there is essentially no clustering
+overhead to the protocol -- 8 byte overhead to each request and 1 byte
+on each response -- so you will _not_ see an exponential slowdown in
+response times the more members are added to the cluster. This new list
+takes affect for all proxies that share the same connection.
+
+When a server shuts down, more connections are refused, existing
+connections not in mid-request are closed, any remaining connections are
+closed immediately after completion of the request in progress and
+clients can failover gracefully to the next server in the list. If a
+server crashes requests are retried on the next server in the list (or
+depending on the `ConnectionStrategy`). This failover pattern is
+followed until there are no more servers in the list at which point the
+client attempts a final multicast search (if it was created with a
+`PROVIDER_URL` starting with `multicast://`) before abandoning the
+request and throwing an exception to the caller.
+
+By default, the failover is ordered but random selection is supported.
+The multicast discovery aspect of the client adds a nice randomness to
+the selection of the first server.
+
+== Discovery
+
+Each discoverable service has a URI which is broadcast as a heartbeat to
+other servers in the cluster. This URI advertises the service's type,
+its cluster group, and its location in the format of
+'group:jbake-date: 2018-12-05
+:jbake-type:location'. Say for example
+"cluster1:ejb:ejbd://thehost:4201". The URI is sent out repeatedly in a
+pulse and its presence on the network indicates its availability and its
+absence indicates the service is no longer available.
+
+The sending of this pulse (the heartbeat) can be done via UDP or TCP:
+multicast and "multipoint" respectively. More on that in the following
+section. The rate at which the heartbeat is pulsed to the network can be
+specified via the 'heart_rate' property. The default is 500
+milliseconds. This rate is also used when listening for services on the
+network. If a service goes missing for the duration of 'heart_rate'
+multiplied by 'max_missed_heartbeats', then the service is considered
+dead.
+
+The 'group' property, cluster1 in the example, is used to dissect the
+servers on the network into smaller logical clusters. A given server
+will broadcast all it's services with the group prefixed in the URI, as
+well it will ignore any services it sees broadcast if they do not share
+the same group name.
+
+#Details
+
+Multicast
+
+* link:multicast-discovery.html[Multicast UDP Discovery]
+* link:multipulse-discovery.html[Multipulse UDP Discovery]
+
+Multipoint
+
+* link:multipoint-discovery.html[Multipoint TCP Discovery]
+* link:multipoint-considerations.html[Considerations]
+* link:multipoint-recommendations.html[Recommendations]
+
+Logging
+
+* link:failover-logging.html[Failover Logging Events]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-failover.md
----------------------------------------------------------------------
diff --git a/docs/ejb-failover.md b/docs/ejb-failover.md
deleted file mode 100644
index 8e2029e..0000000
--- a/docs/ejb-failover.md
+++ /dev/null
@@ -1,89 +0,0 @@
-index-group=Discovery and Failover
-type=page
-status=published
-title=EJB Client/Server Failover
-~~~~~~
-
-OpenEJB supports stateless failover. Specifically, the ability for an EJB
-client to failover from one server to the next if a request cannot be
-completed. No application state information is communicated between the
-servers, so this functionality should be used only with applications that
-are inherently stateless. A common term for this sort of setup is a server
-farm.
-
-The basic design assumption is that all servers in the same group have the
-same applications deployed and are capable of doing the same job. Servers
-can be brought online and offline while clients are running. As members
-join/leave this information is sent to the client as part of normal EJB
-request/response communication so active clients always have the most
-current information on servers that can process their request should
-communication with a particular server fail.
-
-# Client Behavior
-
-On each request to the server, the client will send the version number
-associated with the list of servers in the cluster it is aware of.
-Initially this version will be zero and the list will be empty. Only when
-the server sees the client has an old list will the server send the updated
-list. This is an important distinction as the list is not transmitted back
-and forth on every request, only on change. If the membership of the
-cluster is stable there is essentially no clustering overhead to the
-protocol -- 8 byte overhead to each request and 1 byte on each response --
-so you will *not* see an exponential slowdown in response times the more
-members are added to the cluster. This new list takes affect for all
-proxies that share the same connection.
-
-When a server shuts down, more connections are refused, existing
-connections not in mid-request are closed, any remaining connections are
-closed immediately after completion of the request in progress and clients
-can failover gracefully to the next server in the list. If a server
-crashes requests are retried on the next server in the list (or depending
-on the `ConnectionStrategy`). This failover pattern is followed until there
-are no more servers in the list at which point the client attempts a final
-multicast search (if it was created with a `PROVIDER_URL` starting with
-`multicast://`) before abandoning the request and throwing an exception to
-the caller.
-
-By default, the failover is ordered but random selection is supported. The
-multicast discovery aspect of the client adds a nice randomness to the
-selection of the first server.
-
-# Discovery
-
-Each discoverable service has a URI which is broadcast as a heartbeat to
-other servers in the cluster. This URI advertises the service's type, its
-cluster group, and its location in the format of 'group:type:location'.
-Say for example "cluster1:ejb:ejbd://thehost:4201". The URI is sent out
-repeatedly in a pulse and its presence on the network indicates its
-availability and its absence indicates the service is no longer available.
-
-The sending of this pulse (the heartbeat) can be done via UDP or TCP:
-multicast and "multipoint" respectively. More on that in the following
-section. The rate at which the heartbeat is pulsed to the network can be
-specified via the 'heart_rate' property. The default is 500 milliseconds.
-This rate is also used when listening for services on the network. If a
-service goes missing for the duration of 'heart_rate' multiplied by
-'max_missed_heartbeats', then the service is considered dead.
-
-The 'group' property, cluster1 in the example, is used to dissect the
-servers on the network into smaller logical clusters. A given server will
-broadcast all it's services with the group prefixed in the URI, as well it
-will ignore any services it sees broadcast if they do not share the same
-group name.
-
-#Details
-
-Multicast
-
- - [Multicast UDP Discovery](multicast-discovery.html)
- - [Multipulse UDP Discovery](multipulse-discovery.html)
-
-Multipoint
-
- - [Multipoint TCP Discovery](multipoint-discovery.html)
- - [Considerations](multipoint-considerations.html)
- - [Recommendations](multipoint-recommendations.html)
-
-Logging
-
- - [Failover Logging Events](failover-logging.html)
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-local-ref.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-local-ref.adoc b/docs/ejb-local-ref.adoc
new file mode 100644
index 0000000..a7787c6
--- /dev/null
+++ b/docs/ejb-local-ref.adoc
@@ -0,0 +1,54 @@
+# ejb-local-ref
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+# Via annotation
+
+Usable by EJB, Interceptor, Servlet, Filter, or Listener
+
+....
+package org.superbiz.refs;
+
+import javax.ejb.EJB;
+import javax.ejb.Stateless;
+import javax.naming.InitialContext;
+
+@Stateless
+@EJB(name = "myFooEjb", beanInterface = FooLocal.class)
+public class MyEjbLocalRefBean implements MyBeanInterface {
+
+ @EJB
+ private BarLocal myBarEjb;
+
+ public void someBusinessMethod() throws Exception {
+ if (myBarEjb == null) throw new NullPointerException("myBarEjb not injected");
+
+ // Both can be looked up from JNDI as well
+ InitialContext context = new InitialContext();
+ FooLocal fooLocal = (FooLocal) context.lookup("java:comp/env/myFooEjb");
+ BarLocal barLocal = (BarLocal) context.lookup("java:comp/env/org.superbiz.refs.MyEjbLocalRefBean/myBarEjb");
+ }
+}
+....
+
+# Via xml
+
+The above @EJB annotation usage is 100% equivalent to the following xml.
+
+....
+<ejb-local-ref>
+ <ejb-ref-name>myFooEjb</ejb-ref-name>
+ <local>org.superbiz.refs.FooLocal</local>
+</ejb-local-ref>
+
+<ejb-local-ref>
+ <ejb-ref-name>org.superbiz.refs.MyEjbLocalRefBean/myBarEjb</ejb-ref-name>
+ <local>org.superbiz.refs.BarLocal</local>
+ <injection-target>
+ <injection-target-class>org.superbiz.refs.MyEjbLocalRefBean</injection-target-class>
+ <injection-target-name>myBarEjb</injection-target-name>
+ </injection-target>
+</ejb-local-ref>
+....
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-local-ref.md
----------------------------------------------------------------------
diff --git a/docs/ejb-local-ref.md b/docs/ejb-local-ref.md
deleted file mode 100644
index 1b716b6..0000000
--- a/docs/ejb-local-ref.md
+++ /dev/null
@@ -1,52 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=ejb-local-ref
-~~~~~~
-<a name="ejb-local-ref-Viaannotation"></a>
-# Via annotation
-
-Usable by EJB, Interceptor, Servlet, Filter, or Listener
-
- package org.superbiz.refs;
-
- import javax.ejb.EJB;
- import javax.ejb.Stateless;
- import javax.naming.InitialContext;
-
- @Stateless
- @EJB(name = "myFooEjb", beanInterface = FooLocal.class)
- public class MyEjbLocalRefBean implements MyBeanInterface {
-
- @EJB
- private BarLocal myBarEjb;
-
- public void someBusinessMethod() throws Exception {
- if (myBarEjb == null) throw new NullPointerException("myBarEjb not injected");
-
- // Both can be looked up from JNDI as well
- InitialContext context = new InitialContext();
- FooLocal fooLocal = (FooLocal) context.lookup("java:comp/env/myFooEjb");
- BarLocal barLocal = (BarLocal) context.lookup("java:comp/env/org.superbiz.refs.MyEjbLocalRefBean/myBarEjb");
- }
- }
-
-
-<a name="ejb-local-ref-Viaxml"></a>
-# Via xml
-
-The above @EJB annotation usage is 100% equivalent to the following xml.
-
- <ejb-local-ref>
- <ejb-ref-name>myFooEjb</ejb-ref-name>
- <local>org.superbiz.refs.FooLocal</local>
- </ejb-local-ref>
-
- <ejb-local-ref>
- <ejb-ref-name>org.superbiz.refs.MyEjbLocalRefBean/myBarEjb</ejb-ref-name>
- <local>org.superbiz.refs.BarLocal</local>
- <injection-target>
- <injection-target-class>org.superbiz.refs.MyEjbLocalRefBean</injection-target-class>
- <injection-target-name>myBarEjb</injection-target-name>
- </injection-target>
- </ejb-local-ref>
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-over-ssl.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-over-ssl.adoc b/docs/ejb-over-ssl.adoc
new file mode 100644
index 0000000..6b799a6
--- /dev/null
+++ b/docs/ejb-over-ssl.adoc
@@ -0,0 +1,132 @@
+# EJB over SSL
+:index-group: Configuration
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+It is possible to setup client/server requests over SSL. EJB requests
+from a remote client can happen two different ways:
+
+* *https* for when an EJB is running in TomEE
+* *ejbds* for when an EJB is running in OpenEJB Standalone
+
+Note, TomEE can be setup to support *ejbds*.
+
+== https
+
+First, you'll need to setup Tomcat (TomEE) with SSL as described here:
+
+http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html
+
+Once that is done and the `tomee` webapp can be accessed with `https`,
+an EJB client can invoke over `https` using the following
+`InitialContext` setup:
+
+....
+Properties p = new Properties();
+p.put("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put("java.naming.provider.url", "https://127.0.0.1:8443/tomee/ejb");
+// user and pass optional
+p.put("java.naming.security.principal", "myuser");
+p.put("java.naming.security.credentials", "mypass");
+
+InitialContext ctx = new InitialContext(p);
+
+MyBean myBean = (MyBean) ctx.lookup("MyBeanRemote");
+....
+
+If you setup Tomcat (TomEE) to use the APR (Apache Portable Runitme)
+implementation of SSL on the server side, and you have connection issues
+like connection reset, you'll have to set 'https.protocols' system
+property. 'https.protocols' property must be set according to the
+SSLProtocol parameter of the HTTPS connector configuration :
+
+http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
+
+You can also have a look a this :
+
+http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html
+
+== ejbds
+
+The SSL version of the `ejbd` protocol is called `ejbds` and is enabled
+and setup in OpenEJB Standalone by default.
+
+Its configuration `conf/ejbds.properties` looks like this:
+
+....
+server = org.apache.openejb.server.ejbd.EjbServer
+bind = 127.0.0.1
+port = 4203
+disabled = false
+threads = 200
+backlog = 200
+secure = true
+discovery = ejb:ejbds://{bind}:{port}
+....
+
+To access this service from a remote client, the `InitialContext` would
+be setup like the following:
+
+....
+Properties p = new Properties();
+p.put("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
+p.put("java.naming.provider.url", "ejbd://localhost:4201");
+// user and pass optional
+p.put("java.naming.security.principal", "myuser");
+p.put("java.naming.security.credentials", "mypass");
+
+InitialContext ctx = new InitialContext(p);
+
+MyBean myBean = (MyBean) ctx.lookup("MyBeanRemote");
+....
+
+=== Changing the Cipher Suite
+
+https://issues.apache.org/jira/browse/OPENEJB-1856[This is a pending
+feature] By default, the ejbds protocol connects with
+SSL_DH_anon_WITH_RC4_128_MD5. That means your connection is encrypted
+and the integrity of the transmission is verified. However, this only
+protects your from eavesdroppers, it offers absolutely zero protection
+from Man in the Middle attacks. This sort of attack could be pulled off
+without your knowledge and the attacker has the ability to intercept,
+monitor, and even modify your messages. If the attacker could control a
+router on your connection path, this attack could be trivially pulled
+off with nothing more but the OpenEJB server and client.
+
+To secure your connections against this sort of attack, your client can
+cryptographically prove it's talking to the correct server before
+sending any data. To do this, simply select one or more secure cipher
+suites that your J2SE provider supports from
+http://docs.oracle.com/cd/E19728-01/820-2550/cipher_suites.html[this
+listing].
+
+You must now instruct the client and server to use that suite.
+
+On the server:
+
+....
+server = org.apache.openejb.server.ejbd.EjbServer
+bind = 127.0.0.1
+port = 4203
+disabled = false
+threads = 200
+backlog = 200
+secure = true
+enabledCipherSuites = TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
+discovery = ejb:ejbds://{bind}:{port}
+....
+
+On the client, you must supply a property:
+
+....
+-Dopenejb.client.enabledCipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
+....
+
+The final piece is to make sure your server has available a private
+certificate that the the client can trust. This can be certificate from
+an authority or a self signed certificate. The javax.net.ssl.trustStore
+and javax.net.ssl.keyStore JVM properties
+http://fusesource.com/docs/broker/5.3/security/SSL-SysProps.html[are
+used to set this up.]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-over-ssl.md
----------------------------------------------------------------------
diff --git a/docs/ejb-over-ssl.md b/docs/ejb-over-ssl.md
deleted file mode 100644
index f221331..0000000
--- a/docs/ejb-over-ssl.md
+++ /dev/null
@@ -1,100 +0,0 @@
-index-group=Configuration
-type=page
-status=published
-title=EJB over SSL
-~~~~~~
-
-It is possible to setup client/server requests over SSL. EJB requests from a remote client can happen two different ways:
-
- - **https** for when an EJB is running in TomEE
- - **ejbds** for when an EJB is running in OpenEJB Standalone
-
-Note, TomEE can be setup to support **ejbds**.
-
-# https
-
-First, you'll need to setup Tomcat (TomEE) with SSL as described here:
-
- [http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html](http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html)
-
-Once that is done and the `tomee` webapp can be accessed with `https`, an EJB client can invoke over `https` using the following
-`InitialContext` setup:
-
-
- Properties p = new Properties();
- p.put("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put("java.naming.provider.url", "https://127.0.0.1:8443/tomee/ejb");
- // user and pass optional
- p.put("java.naming.security.principal", "myuser");
- p.put("java.naming.security.credentials", "mypass");
-
- InitialContext ctx = new InitialContext(p);
-
- MyBean myBean = (MyBean) ctx.lookup("MyBeanRemote");
-
-If you setup Tomcat (TomEE) to use the APR (Apache Portable Runitme) implementation of SSL on the server side, and you have connection issues like connection reset, you'll have to set 'https.protocols' system property.
-'https.protocols' property must be set according to the SSLProtocol parameter of the HTTPS connector configuration :
-
-[http://tomcat.apache.org/tomcat-7.0-doc/config/http.html][1]
-
-You can also have a look a this :
-
-[http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html][2]
-
-# ejbds
-
-The SSL version of the `ejbd` protocol is called `ejbds` and is enabled and setup in OpenEJB Standalone by default.
-
-Its configuration `conf/ejbds.properties` looks like this:
-
- server = org.apache.openejb.server.ejbd.EjbServer
- bind = 127.0.0.1
- port = 4203
- disabled = false
- threads = 200
- backlog = 200
- secure = true
- discovery = ejb:ejbds://{bind}:{port}
-
-To access this service from a remote client, the `InitialContext` would be setup like the following:
-
- Properties p = new Properties();
- p.put("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
- p.put("java.naming.provider.url", "ejbd://localhost:4201");
- // user and pass optional
- p.put("java.naming.security.principal", "myuser");
- p.put("java.naming.security.credentials", "mypass");
-
- InitialContext ctx = new InitialContext(p);
-
- MyBean myBean = (MyBean) ctx.lookup("MyBeanRemote");
-
-## Changing the Cipher Suite
-[This is a pending feature](https://issues.apache.org/jira/browse/OPENEJB-1856)
-By default, the ejbds protocol connects with SSL_DH_anon_WITH_RC4_128_MD5. That means your connection is encrypted and the integrity of the transmission is verified. However, this only protects your from eavesdroppers, it offers absolutely zero protection from Man in the Middle attacks. This sort of attack could be pulled off without your knowledge and the attacker has the ability to intercept, monitor, and even modify your messages. If the attacker could control a router on your connection path, this attack could be trivially pulled off with nothing more but the OpenEJB server and client.
-
-To secure your connections against this sort of attack, your client can cryptographically prove it's talking to the correct server before sending any data. To do this, simply select one or more secure cipher suites that your J2SE provider supports from [this listing](http://docs.oracle.com/cd/E19728-01/820-2550/cipher_suites.html).
-
-You must now instruct the client and server to use that suite.
-
-On the server:
-
- server = org.apache.openejb.server.ejbd.EjbServer
- bind = 127.0.0.1
- port = 4203
- disabled = false
- threads = 200
- backlog = 200
- secure = true
- enabledCipherSuites = TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
- discovery = ejb:ejbds://{bind}:{port}
-
-On the client, you must supply a property:
-
- -Dopenejb.client.enabledCipherSuites=TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA
-
-The final piece is to make sure your server has available a private certificate that the the client can trust. This can be certificate from an authority or a self signed certificate. The javax.net.ssl.trustStore and javax.net.ssl.keyStore JVM properties [are used to set this up.](http://fusesource.com/docs/broker/5.3/security/SSL-SysProps.html)
-
-
- [1]: http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
- [2]: http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-ref.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-ref.adoc b/docs/ejb-ref.adoc
new file mode 100644
index 0000000..1c3a6a8
--- /dev/null
+++ b/docs/ejb-ref.adoc
@@ -0,0 +1,53 @@
+# ejb-ref
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+#
+Via annotation
+
+....
+package org.superbiz.refs;
+
+import javax.ejb.EJB;
+import javax.ejb.Stateless;
+import javax.naming.InitialContext;
+
+@Stateless
+@EJB(name = "myFooEjb", beanInterface = FooRemote.class)
+public class MyEjbRemoteRefBean implements MyBeanInterface {
+
+ @EJB
+ private BarRemote myBarEjb;
+
+ public void someBusinessMethod() throws Exception {
+ if (myBarEjb == null) throw new NullPointerException("myBarEjb not injected");
+
+ // Both can be looked up from JNDI as well
+ InitialContext context = new InitialContext();
+ FooRemote fooRemote = (FooRemote) context.lookup("java:comp/env/myFooEjb");
+ BarRemote barRemote = (BarRemote) context.lookup("java:comp/env/org.superbiz.refs.MyEjbRemoteRefBean/myBarEjb");
+ }
+}
+....
+
+# Via xml
+
+The above @EJB annotation usage is 100% equivalent to the following xml.
+
+....
+<ejb-ref>
+ <ejb-ref-name>myFooEjb</ejb-ref-name>
+ <remote>org.superbiz.refs.FooRemote</remote>
+</ejb-ref>
+<ejb-ref>
+
+<ejb-ref-name>org.superbiz.refs.MyEjbRemoteRefBean/myBarEjb</ejb-ref-name>
+ <remote>org.superbiz.refs.BarRemote</remote>
+ <injection-target>
+ <injection-target-class>org.superbiz.refs.MyEjbRemoteRefBean</injection-target-class>
+ <injection-target-name>myBarEjb</injection-target-name>
+ </injection-target>
+</ejb-ref>
+....
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-ref.md
----------------------------------------------------------------------
diff --git a/docs/ejb-ref.md b/docs/ejb-ref.md
deleted file mode 100644
index 8e66acf..0000000
--- a/docs/ejb-ref.md
+++ /dev/null
@@ -1,50 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=ejb-ref
-~~~~~~
-<a name="ejb-ref-Viaannotation"></a>
-# Via annotation
-
- package org.superbiz.refs;
-
- import javax.ejb.EJB;
- import javax.ejb.Stateless;
- import javax.naming.InitialContext;
-
- @Stateless
- @EJB(name = "myFooEjb", beanInterface = FooRemote.class)
- public class MyEjbRemoteRefBean implements MyBeanInterface {
-
- @EJB
- private BarRemote myBarEjb;
-
- public void someBusinessMethod() throws Exception {
- if (myBarEjb == null) throw new NullPointerException("myBarEjb not injected");
-
- // Both can be looked up from JNDI as well
- InitialContext context = new InitialContext();
- FooRemote fooRemote = (FooRemote) context.lookup("java:comp/env/myFooEjb");
- BarRemote barRemote = (BarRemote) context.lookup("java:comp/env/org.superbiz.refs.MyEjbRemoteRefBean/myBarEjb");
- }
- }
-
-
-<a name="ejb-ref-Viaxml"></a>
-# Via xml
-
-The above @EJB annotation usage is 100% equivalent to the following xml.
-
- <ejb-ref>
- <ejb-ref-name>myFooEjb</ejb-ref-name>
- <remote>org.superbiz.refs.FooRemote</remote>
- </ejb-ref>
- <ejb-ref>
-
- <ejb-ref-name>org.superbiz.refs.MyEjbRemoteRefBean/myBarEjb</ejb-ref-name>
- <remote>org.superbiz.refs.BarRemote</remote>
- <injection-target>
- <injection-target-class>org.superbiz.refs.MyEjbRemoteRefBean</injection-target-class>
- <injection-target-name>myBarEjb</injection-target-name>
- </injection-target>
- </ejb-ref>
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-refs.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-refs.adoc b/docs/ejb-refs.adoc
new file mode 100644
index 0000000..f108da5
--- /dev/null
+++ b/docs/ejb-refs.adoc
@@ -0,0 +1,190 @@
+# EJB Refs
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+TomEE complains it doesn't know the container type, so I added
+type="javax.naming.InitialContext" and it worked (mostly). ##
+Referencing a bean in another jar (with annotations)
+
+When using annotations to reference a bean from another ejb in your ear
+you have to supplement the @EJB reference with a small chunk of xml in
+the ejb-jar.xml of the referring bean.
+
+So in ejb app A colorsApp.jar you have this bean:
+
+....
+package com.foo.colors;
+
+import javax.ejb.Stateless;
+
+@Stateless
+public class OrangeBean implements OrangeRemote {
+}
+....
+
+Then in ejb app B shapesApp.jar you have this bean with a reference to
+OrangeRemote:
+
+....
+package com.foo.shapes;
+
+import javax.ejb.Stateless;
+import com.foo.colors.OrangeRemote;
+
+@Stateless
+public class SquareBean implements SquareRemote {
+ @EJB OrangeRemote orangeRemote;
+}
+....
+
+To hook this reference up you need to override this ref and add more
+info in the ejb-jar.xml of shapesApp.jar as follows:
+
+....
+<ejb-jar>
+ <enterprise-beans>
+
+ <session>
+ <ejb-name>SquareBean</ejb-name>
+ <ejb-ref>
+ <ejb-ref-name>com.foo.shapes.SquareBean/orangeRemote</ejb-ref-name>
+ <ejb-link>colorsApp.jar#OrangeBean</ejb-link>
+ </ejb-ref>
+ </session>
+
+ </enterprise-beans>
+</ejb-jar>
+....
+
+== Referencing a bean in another jar (xml only, no annotations)
+
+The same basic approach applies and dependency injection is still
+possible, however more information must be described in the xml.
+
+In ejb app A colorsApp.jar you have this bean:
+
+....
+package com.foo.colors;
+
+import javax.ejb.Stateless;
+
+@Stateless
+public class OrangeBean implements OrangeRemote {
+}
+....
+
+Then in ejb app B shapesApp.jar -- note there is no @EJB annotation:
+
+....
+package com.foo.shapes;
+
+import javax.ejb.Stateless;
+import com.foo.colors.OrangeRemote;
+
+@Stateless
+public class SquareBean implements SquareRemote {
+ OrangeRemote orangeRemote;
+}
+....
+
+Here's how you would hook this reference up, injection and all, with
+just xml. The following would be added to the ejb-jar.xml of
+shapesApp.jar:
+
+....
+<ejb-jar>
+ <enterprise-beans>
+
+ <session>
+ <ejb-name>SquareBean</ejb-name>
+ <ejb-ref>
+ <ejb-ref-name>com.foo.shapes.SquareBean/orangeRemote</ejb-ref-name>
+ <ejb-ref-type>Session</ejb-ref-type>
+ <remote>com.foo.colors.OrangeRemote</remote>
+ <ejb-link>colorsApp.jar#OrangeBean</ejb-link>
+ <injection-target>
+ <injection-target-class>com.foo.shapes.SquareBean</injection-target-class>
+ <injection-target-name>orangeRemote</injection-target-name>
+ </injection-target>
+ </ejb-ref>
+ </session>
+
+ </enterprise-beans>
+</ejb-jar>
+....
+
+Note that the value of could actually be anything and the above example
+would still work as there is no annotation that needs to match the and
+no one will likely be looking up the EJB as it's injected.
+
+== Referencing a bean in another server
+
+As of OpenEJB 4.0.0-beta-3, server to server references work.
+
+First we need to configure and name the InitialContext that will be used
+to satisfy the lookup to the other server.
+
+In this example we are calling our InitialContext `shoe` for fun.
+
+....
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<openejb>
+
+ <JndiProvider id="shoe" type="javax.naming.InitialContext">
+ java.naming.provider.url = ejbd://localhost:4201
+ java.naming.factory.initial = org.apache.openejb.client.RemoteInitialContextFactory
+ </JndiProvider>
+
+</openejb>
+....
+
+Declaring the `@EJB` reference is then done using a `mappedName` that
+references the named `InitialContext`
+
+....
+public class BlueBean implements BlueRemote {
+
+ @EJB(mappedName = "jndi:ext://shoe/OrangeBeanRemote")
+ private OrangeRemote orangeRemote;
+
+ public void hasOrangeRemote() {
+ Assert.assertNotNull("orangeRemote is null", orangeRemote);
+ assertEquals("olleh", orangeRemote.echo("hello"));
+ }
+}
+....
+
+Specifically, the `mappedName` syntax is as follows:
+
+* jndi:ext://`<contextId>`/`<jndiName>`
+
+=== Referencing a bean in "many" servers
+
+Note the above also works with the various forms of failover that TomEE
+supports.
+
+If say, there are two servers that have the `OrangeBeanRemote` bean, you
+could expand the `<JndiProvider>` delcaration like so:
+
+....
+ <JndiProvider id="shoe" type="javax.naming.InitialContext">
+ java.naming.provider.url = failover:ejbd://192.168.1.20:4201,ejbd://192.168.1.30:4201
+ java.naming.factory.initial = org.apache.openejb.client.RemoteInitialContextFactory
+ </JndiProvider>
+....
+
+In the event that the `ejbd://192.168.1.20:4201` server cannot be
+contacted, the second server will be tried.
+
+This sort of arangement can also happen dynamicall against a list of
+servers that continuously grows and shrinks. The server list is
+maintained behind the scenes using server discovery logic that can
+function on either UDP or TCP. See these docs for more details on
+Failover and Discovery:
+
+* link:multicast-discovery.html[Multicast Discovery (UDP)]
+* link:multipulse-discovery.html[Multipulse Discovery (TCP)]
+* link:multipoint-discovery.html[Multipoint Discovery (TCP)]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-refs.md
----------------------------------------------------------------------
diff --git a/docs/ejb-refs.md b/docs/ejb-refs.md
deleted file mode 100644
index 2e03567..0000000
--- a/docs/ejb-refs.md
+++ /dev/null
@@ -1,178 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=EJB Refs
-~~~~~~
-
-TomEE complains it doesn't know the container type, so I added type="javax.naming.InitialContext" and it worked (mostly).
-<a name="EJBRefs-Referencingabeaninanotherjar(withannotations)"></a>
-## Referencing a bean in another jar (with annotations)
-
-When using annotations to reference a bean from another ejb in your ear you
-have to supplement the @EJB reference with a small chunk of xml in the
-ejb-jar.xml of the referring bean.
-
-So in ejb app A colorsApp.jar you have this bean:
-
-
- package com.foo.colors;
-
- import javax.ejb.Stateless;
-
- @Stateless
- public class OrangeBean implements OrangeRemote {
- }
-
-
-Then in ejb app B shapesApp.jar you have this bean with a reference to
-OrangeRemote:
-
-
- package com.foo.shapes;
-
- import javax.ejb.Stateless;
- import com.foo.colors.OrangeRemote;
-
- @Stateless
- public class SquareBean implements SquareRemote {
- @EJB OrangeRemote orangeRemote;
- }
-
-
-To hook this reference up you need to override this ref and add more info
-in the ejb-jar.xml of shapesApp.jar as follows:
-
-
- <ejb-jar>
- <enterprise-beans>
-
- <session>
- <ejb-name>SquareBean</ejb-name>
- <ejb-ref>
- <ejb-ref-name>com.foo.shapes.SquareBean/orangeRemote</ejb-ref-name>
- <ejb-link>colorsApp.jar#OrangeBean</ejb-link>
- </ejb-ref>
- </session>
-
- </enterprise-beans>
- </ejb-jar>
-
-
-<a name="EJBRefs-Referencingabeaninanotherjar(xmlonly,noannotations)"></a>
-## Referencing a bean in another jar (xml only, no annotations)
-
-The same basic approach applies and dependency injection is still possible,
-however more information must be described in the xml.
-
-
-In ejb app A colorsApp.jar you have this bean:
-
-
- package com.foo.colors;
-
- import javax.ejb.Stateless;
-
- @Stateless
- public class OrangeBean implements OrangeRemote {
- }
-
-
-Then in ejb app B shapesApp.jar -- note there is no @EJB annotation:
-
-
- package com.foo.shapes;
-
- import javax.ejb.Stateless;
- import com.foo.colors.OrangeRemote;
-
- @Stateless
- public class SquareBean implements SquareRemote {
- OrangeRemote orangeRemote;
- }
-
-
-Here's how you would hook this reference up, injection and all, with just
-xml. The following would be added to the ejb-jar.xml of shapesApp.jar:
-
-
- <ejb-jar>
- <enterprise-beans>
-
- <session>
- <ejb-name>SquareBean</ejb-name>
- <ejb-ref>
- <ejb-ref-name>com.foo.shapes.SquareBean/orangeRemote</ejb-ref-name>
- <ejb-ref-type>Session</ejb-ref-type>
- <remote>com.foo.colors.OrangeRemote</remote>
- <ejb-link>colorsApp.jar#OrangeBean</ejb-link>
- <injection-target>
- <injection-target-class>com.foo.shapes.SquareBean</injection-target-class>
- <injection-target-name>orangeRemote</injection-target-name>
- </injection-target>
- </ejb-ref>
- </session>
-
- </enterprise-beans>
- </ejb-jar>
-
-
-Note that the value of <ejb-ref-name> could actually be anything and the
-above example would still work as there is no annotation that needs to
-match the <ejb-ref-name> and no one will likely be looking up the EJB as
-it's injected.
-
-# Referencing a bean in another server
-
-As of OpenEJB 4.0.0-beta-3, server to server references work.
-
-First we need to configure and name the InitialContext that will be used to satisfy the lookup to the other server.
-
-In this example we are calling our InitialContext `shoe` for fun.
-
- <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
- <openejb>
-
- <JndiProvider id="shoe" type="javax.naming.InitialContext">
- java.naming.provider.url = ejbd://localhost:4201
- java.naming.factory.initial = org.apache.openejb.client.RemoteInitialContextFactory
- </JndiProvider>
-
- </openejb>
-
-Declaring the `@EJB` reference is then done using a `mappedName` that references the named `InitialContext`
-
- public class BlueBean implements BlueRemote {
-
- @EJB(mappedName = "jndi:ext://shoe/OrangeBeanRemote")
- private OrangeRemote orangeRemote;
-
- public void hasOrangeRemote() {
- Assert.assertNotNull("orangeRemote is null", orangeRemote);
- assertEquals("olleh", orangeRemote.echo("hello"));
- }
- }
-
-Specifically, the `mappedName` syntax is as follows:
-
- - jndi:ext://`<contextId>`/`<jndiName>`
-
-
-## Referencing a bean in "many" servers
-
-Note the above also works with the various forms of failover that TomEE supports.
-
-If say, there are two servers that have the `OrangeBeanRemote` bean, you could expand the `<JndiProvider>` delcaration like so:
-
- <JndiProvider id="shoe" type="javax.naming.InitialContext">
- java.naming.provider.url = failover:ejbd://192.168.1.20:4201,ejbd://192.168.1.30:4201
- java.naming.factory.initial = org.apache.openejb.client.RemoteInitialContextFactory
- </JndiProvider>
-
-In the event that the `ejbd://192.168.1.20:4201` server cannot be contacted, the second server will be tried.
-
-This sort of arangement can also happen dynamicall against a list of servers that continuously grows and shrinks. The server list is maintained behind
-the scenes using server discovery logic that can function on either UDP or TCP. See these docs for more details on Failover and Discovery:
-
- - [Multicast Discovery (UDP)](multicast-discovery.html)
- - [Multipulse Discovery (TCP)](multipulse-discovery.html)
- - [Multipoint Discovery (TCP)](multipoint-discovery.html)
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-request-logging.adoc
----------------------------------------------------------------------
diff --git a/docs/ejb-request-logging.adoc b/docs/ejb-request-logging.adoc
new file mode 100644
index 0000000..48a48bf
--- /dev/null
+++ b/docs/ejb-request-logging.adoc
@@ -0,0 +1,155 @@
+# EJB Request Logging
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+NOTE: Licensed to the Apache Software Foundation (ASF)
+under one or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information regarding
+copyright ownership. The ASF licenses this file to you under the Apache
+License, Version 2.0 (the "License"); you may not use this file except
+in compliance with the License. You may obtain a copy of the License at
+. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by
+applicable law or agreed to in writing, software distributed under the
+License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
+CONDITIONS OF ANY KIND, either express or implied. See the License for
+the specific language governing permissions and limitations under the
+License.
+
+Both client-side and server-side request logging is supported and
+includes various invocation times aimed at helping to identify where
+time is going in a request.
+
+== Client-side
+
+On the client requests/responses are logged on java.util.logging
+`FINEST` level in category `OpenEJB.client`. The code is similar to the
+following:
+
+....
+final long time = System.nanoTime() - start;
+final String message = String.format("Invocation %sns - %s - Request(%s) - Response(%s)", time, conn.getURI(), req, res);
+logger.log(Level.FINEST, message);
+....
+
+Note that the check to see if FINEST is enabled is cached for
+performance reasons, so it must be set at VM startup.
+
+== Server-side
+
+On the server requests/responses are logged in java.util.logging `FINE`
+in category`"OpenEJB.server.remote.ejb`. The code for that is similar to
+this:
+
+....
+logger.fine("EJB REQUEST: " + req + " -- RESPONSE: " + res);
+....
+
+== Request times
+
+Three times are tracked per request and logged in the above statements
+as part of the formatting of the EJB Response. They're best understood
+in reverse:
+
+* *Container time* -- this is the raw time of invoking the bean
+including its interceptors and any transaction begin/commit time. This
+time is effectively "business logic".
+* *Server time* -- this timer starts the (nano)second the request is
+seen by the server and the (nano)second the response is actually
+written. The serverTime minus the containerTime will effectively show
+you how long serialization and deserialization is taking pre request.
+* *Client time* -- entire begin to end including attempting to contact
+the server and fully reading the response. The clientTime minus the
+serverTime will show network latency for the most part.
+
+The container time and server time are written in the EJB response and
+visible to the client. The client will log all three times, the server
+will log the first two. All log statements are on a single line.
+
+== Bean-time and JMX Statistics
+
+The above information applies purely to remote EJB calls made over a
+network. Calls on `@Remote` or `@Local` interfaces between two
+components in the same server are not logged.
+
+However, *all* EJB invocations to business methods _or_ callbacks like
+`@PostConstruct` are tracked for statistical analysis. By default a
+floating window of 2000 samples are kept. The time tracked is purely
+*bean time* which includes interceptors, decorators and the bean itself,
+but does not include other container services like transactions or
+security.
+
+This information is available in JMX. A sample JMX ObjectName for a
+`CounterBean` will look like this:
+
+....
+openejb.management:J2EEServer=openejb,J2EEApplication=null,EJBModule=StatsModule,StatelessSessionBean=CounterBean,j2eeType=Invocations,name=CounterBean
+....
+
+All beans have the following MBean attributes, listed here in shorthand:
+
+* javax.management.MBeanAttributeInfo[description=,
+name=InvocationCount, type=long, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=, name=InvocationTime,
+type=long, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=MonitoredMethods, type=long, read-only, descriptor=\{}]
+* javax.management.MBeanOperationInfo[description=,
+name=FilterAttributes, returnType=void,
+signature=[javax.management.MBeanParameterInfo[description="",
+name=excludeRegex, type=java.lang.String, descriptor=\{}],
+javax.management.MBeanParameterInfo[description="", name=includeRegex,
+type=java.lang.String, descriptor=\{}]], impact=unknown, descriptor=\{}]
+
+Then for every method there will be these attributes and operations:
+
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Count, type=long, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().GeometricMean, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Kurtosis, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Max, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Mean, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Min, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile01, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile10, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile25, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile50, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile75, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile90, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Percentile99, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().SampleSize, type=int, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Skewness, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().StandardDeviation, type=double, read-only,
+descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Sum, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Sumsq, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanAttributeInfo[description=,
+name=someMethod().Variance, type=double, read-only, descriptor=\{}]
+* javax.management.MBeanOperationInfo[description=,
+name=someMethod().setSampleSize, returnType=void,
+signature=[javax.management.MBeanParameterInfo[description=, name=p1,
+type=int, descriptor=\{}]], impact=unknown, descriptor=\{}]
+* javax.management.MBeanOperationInfo[description=,
+name=someMethod().sortedValues, returnType=[D, signature=[],
+impact=unknown, descriptor=\{}]
+* javax.management.MBeanOperationInfo[description=,
+name=someMethod().values, returnType=[D, signature=[], impact=unknown,
+descriptor=\{}]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejb-request-logging.md
----------------------------------------------------------------------
diff --git a/docs/ejb-request-logging.md b/docs/ejb-request-logging.md
deleted file mode 100644
index 068fdbf..0000000
--- a/docs/ejb-request-logging.md
+++ /dev/null
@@ -1,98 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=EJB Request Logging
-~~~~~~
-Notice: Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
- .
- http://www.apache.org/licenses/LICENSE-2.0
- .
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
-
-Both client-side and server-side request logging is supported and includes various invocation times aimed at helping to identify where time
-is going in a request.
-
-## Client-side
-
-On the client requests/responses are logged on java.util.logging `FINEST` level in category `OpenEJB.client`. The code is similar to the following:
-
- final long time = System.nanoTime() - start;
- final String message = String.format("Invocation %sns - %s - Request(%s) - Response(%s)", time, conn.getURI(), req, res);
- logger.log(Level.FINEST, message);
-
-Note that the check to see if FINEST is enabled is cached for performance reasons, so it must be set at VM startup.
-
-## Server-side
-
-On the server requests/responses are logged in java.util.logging `FINE` in category`"OpenEJB.server.remote.ejb`. The code for that
-is similar to this:
-
- logger.fine("EJB REQUEST: " + req + " -- RESPONSE: " + res);
-
-## Request times
-
-Three times are tracked per request and logged in the above statements as part of the formatting of the EJB Response. They're best understood in reverse:
-
- - **Container time** -- this is the raw time of invoking the bean including its
-interceptors and any transaction begin/commit time. This time is effectively "business logic".
- - **Server time** -- this timer starts the (nano)second the request is seen by the server and
- the (nano)second the response is actually written. The serverTime minus the containerTime will
-effectively show you how long serialization and deserialization is taking pre request.
- - **Client time** -- entire begin to end including attempting to contact the server and fully reading the response. The clientTime minus the serverTime will show network latency for the most part.
-
-The container time and server time are written in the EJB response and visible to the client. The client will log all three times, the server will log the first two. All log statements are on a single line.
-
-## Bean-time and JMX Statistics
-
-The above information applies purely to remote EJB calls made over a network. Calls on `@Remote` or `@Local` interfaces between two components in the same server are not logged.
-
-However, **all** EJB invocations to business methods *or* callbacks like `@PostConstruct` are tracked for statistical analysis.
-By default a floating window of 2000 samples are kept. The time tracked is purely **bean time** which includes
-interceptors, decorators and the bean itself, but does not include other container services like transactions or security.
-
-This information is available in JMX. A sample JMX ObjectName for a `CounterBean` will look like this:
-
- openejb.management:J2EEServer=openejb,J2EEApplication=null,EJBModule=StatsModule,StatelessSessionBean=CounterBean,j2eeType=Invocations,name=CounterBean
-
-All beans have the following MBean attributes, listed here in shorthand:
-
- * javax.management.MBeanAttributeInfo[description=, name=InvocationCount, type=long, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=InvocationTime, type=long, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=MonitoredMethods, type=long, read-only, descriptor={}]
- * javax.management.MBeanOperationInfo[description=, name=FilterAttributes, returnType=void, signature=[javax.management.MBeanParameterInfo[description="", name=excludeRegex, type=java.lang.String, descriptor={}], javax.management.MBeanParameterInfo[description="", name=includeRegex, type=java.lang.String, descriptor={}]], impact=unknown, descriptor={}]
-
-Then for every method there will be these attributes and operations:
-
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Count, type=long, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().GeometricMean, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Kurtosis, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Max, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Mean, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Min, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile01, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile10, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile25, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile50, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile75, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile90, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Percentile99, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().SampleSize, type=int, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Skewness, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().StandardDeviation, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Sum, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Sumsq, type=double, read-only, descriptor={}]
- * javax.management.MBeanAttributeInfo[description=, name=someMethod().Variance, type=double, read-only, descriptor={}]
- * javax.management.MBeanOperationInfo[description=, name=someMethod().setSampleSize, returnType=void, signature=[javax.management.MBeanParameterInfo[description=, name=p1, type=int, descriptor={}]], impact=unknown, descriptor={}]
- * javax.management.MBeanOperationInfo[description=, name=someMethod().sortedValues, returnType=[D, signature=[], impact=unknown, descriptor={}]
- * javax.management.MBeanOperationInfo[description=, name=someMethod().values, returnType=[D, signature=[], impact=unknown, descriptor={}]
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejbd-transport.adoc
----------------------------------------------------------------------
diff --git a/docs/ejbd-transport.adoc b/docs/ejbd-transport.adoc
new file mode 100644
index 0000000..5d07978
--- /dev/null
+++ b/docs/ejbd-transport.adoc
@@ -0,0 +1,205 @@
+# Ejbd Transport
+:index-group: EJB
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+The Ejbd Transport allows to remotely access EJBs that have a remote
+interface. Nevertheless it is not based on IIOP.
+
+Ejbd Transport is different using TomEE or OpenEJB.
+
+In OpenEJB it uses openejb http layer and ejbd is configured through
+ejbd service (same for ejbds). So to activate/deactivate them use
+conf/ejbd(s).properties files. You can set property disabled to true if
+you don't want them to be started.
+
+In TomEE the transport is the Tomcat one. It uses a servlet brought by
+TomEE webapp. Here is the servlet as defined in TomEE webapp:
+
+....
+<servlet>
+ <servlet-name>ServerServlet</servlet-name>
+ <servlet-class>org.apache.openejb.server.httpd.ServerServlet</servlet-class>
+</servlet>
+
+<servlet-mapping>
+ <servlet-name>ServerServlet</servlet-name>
+ <url-pattern>/ejb/*</url-pattern>
+</servlet-mapping>
+....
+
+You can easily remove it if you don't use remote EJBs. Another way is to
+deactivate the servlet using the "activated" init parameter of the
+servlet.
+
+Finally you can move this servlet in your own webapp if you want to use
+a provider url containing your webapp context. Simply copy paste the
+servlet definition in your web.xml and set the url mapping to what you
+want (let say /foo/*). Then use the provider url
+http://<host>:<port>/<webapp context name>/foo
+
+== Remote communication and serialization
+
+Remotely calling EJBs, independent of using Ejbd or other RMI/IIOP based
+protocols, involves serialization and deserialization of objects.
+Deserializing unknown content coming from an untrusted source imposes a
+security risk as the stream could be manipulated. A much publicized
+http://www.kb.cert.org/vuls/id/576313[vulnerability] was found in the
+commons-collections library which allowed to remotely execute arbitrary
+code simply by deserializing instances of the class
+`InvokerTransformer`.
+
+To prevent this risk TomEE and the OpenEJB client since 1.7.4 before
+deserializing every object checks its class against a configurable
+blacklist and a whitelist. The default black list is defined as `*`,
+meaning that requests cannot be deserialized at all and the Ejbd
+transport in fact cannot be used.
+
+The blacklist and whitelist is configured via the system properties:
+
+* `tomee.serialization.class.whitelist`
+* `tomee.serialization.class.blacklist`
+
+You will also find these properties in
+link:properties-listing.html[System Properties Listing]
+
+These rules apply for the whitelist:
+
+* The whitelist has a lower priority than the blacklist. That means a
+class that is part of the blacklist cannot be whitelisted and will
+always be refused.
+* If a whitelist is not defined, either by not defining the property at
+all or defining it with an empty value, every class is on the whitelist.
+In this case only the blacklist applies.
+* If a whitelist is defined it must be a comma separated list of
+prefixes of fully qualified class names. Then deserialization of an
+object fails if its class is not part of this whitelist. A class is on
+the whitelist if its fully qualified classname is prefixed by one of the
+values in the whitelist.
+
+These rules apply for the blacklist:
+
+* If the blacklist should be deactivated it must be configured to the
+value `-`. This will open your system to the serialization vulnerability
+if you don't configure a whitelist!
+* If the blacklist is not configured its default value is
+`org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Process`
+so that for example the class
+`org.apache.commons.collections.functors.InvokerTransformer` cannot be
+deserialized.
+* If the blacklist is configured with an empty value the blacklist is
+effectively `*`, therefore preventing any Ejbd communication.
+* If you want to blacklist certain classes the property must be
+configured to a comma separated list of prefixes of fully qualified
+class names. A class is on the blacklist if its fully qualified
+classname is prefixed by one of the values in the blacklist.
+
+The default for `tomee.serialization.class.whitelist` is empty, the
+default for `tomee.serialization.class.blacklist` is `*` since TomEE
+1.7.4.
+
+If an EJB request fails because a class is not whitelisted you will find
+this log entry:
+
+....
+WARN - "null OEJP/4.7" FAIL "Security error - foo.Bar is not whitelisted as deserializable, prevented before loading it." - Debug for StackTrace
+....
+
+If you trust this class and want to support serialization in remote
+communication you have to configure these properties appropriately both
+on server side as well as on client side.
+
+If you only want to support serialization of the classes `foo.Bar` and
+`foo.Baz` you can configure the properties like this:
+
+....
+tomee.serialization.class.whitelist = foo.Bar,foo.Baz
+tomee.serialization.class.blacklist = -
+....
+
+If you trust all classes in the package `foo` define the properties like
+this:
+
+....
+tomee.serialization.class.whitelist = foo.
+tomee.serialization.class.blacklist = -
+....
+
+(Don't forget the trailing `.` after foo, as it will also whitelist all
+classes in the package `foo2` otherwise.)
+
+If you trust all classes in the package `foo` except the class `foo.Bar`
+you have to configure the properties like this:
+
+....
+tomee.serialization.class.whitelist = foo.
+tomee.serialization.class.blacklist = foo.Bar
+....
+
+=== Revert to behavior of TomEE 1.7.3
+
+TomEE 1.7.3 already contained a fixed blacklist that was not
+configurable and contained the packages org.codehaus.groovy.runtime,
+org.apache.commons.collections.functors and org.apache.xalan including
+subpackages and the class java.lang.Process. If you know that your
+applications runs on TomEE 1.7.3 but does not on TomEE 1.7.4 showing the
+aforementioned log message, you can define the configuration so that the
+serialization will work in the same way as it did with TomEE 1.7.3:
+
+....
+tomee.serialization.class.whitelist =
+tomee.serialization.class.blacklist = org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Process
+....
+
+Please note that with this configuration your server may be vulnerable
+to Java serialization attacks not yet identified by the Zero Day
+initiative. Also note that the following versions of the affected
+libraries have been patched and approved by the Zero Day initiative and
+_may_ be safe to deserialize.
+
+* Groovy 2.4.4
+* Commons Collections 3.2.2
+* Xalan 2.7.2
+
+As Ejbd transport is tunneled over HTTP please make sure that the
+`ServerServlet` is not publicly accessible. When the applications
+running on TomEE do not package the `ServerServlet` themselves ensure
+that the URL http://<host>:<port>/tomee/ejb is not accessible from
+untrusted sources.
+
+If your applications package declare it in their own web.xml make sure
+that the respective URL is not accessible from untrusted sources.
+
+=== Revert to behavior of TomEE 1.7.2
+
+TomEE 1.7.2 did not have any kind of blacklist when deserializing
+objects over Ejbd. If you want to revert to this behavior you can simply
+deactivate the blacklist with this configuration:
+
+....
+tomee.serialization.class.whitelist =
+tomee.serialization.class.blacklist = -
+....
+
+Note that this configuration makes your system highly vulnerable to
+serialization attacks! Consider your system as unsafe!
+
+=== Remote communication and Arquillian tests
+
+The mechanism described above principally also works when running
+Arquillian tests. As the Ejbd transport is already used for deploying
+applications all Arquillian tests would fail with the default settings.
+
+Therefore the TomEE Arquillian adapter automatically starts the
+container so that all classes except for a set of well-know dangerous
+classes are whitelisted.
+
+As Ejbd is by default disabled since TomEE 7.0.0, the TomEE Arquillian
+adapter automatically activates it when starting a remote container.
+
+=== Remote communication and the TomEE Maven Plugin
+
+The same mentioned above on Arquillian and TomEE is also valid when
+using the TomEE Maven Plugin.
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/ejbd-transport.md
----------------------------------------------------------------------
diff --git a/docs/ejbd-transport.md b/docs/ejbd-transport.md
deleted file mode 100644
index 784c6f5..0000000
--- a/docs/ejbd-transport.md
+++ /dev/null
@@ -1,136 +0,0 @@
-index-group=EJB
-type=page
-status=published
-title=Ejbd Transport
-~~~~~~
-
-The Ejbd Transport allows to remotely access EJBs that have a remote interface.
-Nevertheless it is not based on IIOP.
-
-Ejbd Transport is different using TomEE or OpenEJB.
-
-In OpenEJB it uses openejb http layer and ejbd is configured through ejbd service (same for ejbds).
-So to activate/deactivate them use conf/ejbd(s).properties files. You can set property disabled to true
-if you don't want them to be started.
-
-In TomEE the transport is the Tomcat one. It uses a servlet brought by TomEE webapp.
-Here is the servlet as defined in TomEE webapp:
-
- <servlet>
- <servlet-name>ServerServlet</servlet-name>
- <servlet-class>org.apache.openejb.server.httpd.ServerServlet</servlet-class>
- </servlet>
-
- <servlet-mapping>
- <servlet-name>ServerServlet</servlet-name>
- <url-pattern>/ejb/*</url-pattern>
- </servlet-mapping>
-
-
-You can easily remove it if you don't use remote EJBs. Another way is to deactivate the servlet
-using the "activated" init parameter of the servlet.
-
-Finally you can move this servlet in your own webapp if you want to use a provider url
-containing your webapp context. Simply copy paste the servlet definition in your web.xml
-and set the url mapping to what you want (let say /foo/*). Then use the provider url
-http://<host>:<port>/<webapp context name>/foo
-
-### Remote communication and serialization
-
-Remotely calling EJBs, independent of using Ejbd or other RMI/IIOP based protocols, involves serialization and deserialization of objects.
-Deserializing unknown content coming from an untrusted source imposes a security risk as the stream could be manipulated.
-A much publicized [vulnerability](http://www.kb.cert.org/vuls/id/576313) was found in the commons-collections library which allowed to remotely execute arbitrary code simply by deserializing instances of the class `InvokerTransformer`.
-
-To prevent this risk TomEE and the OpenEJB client since 1.7.4 before deserializing every object checks its class against a configurable blacklist and a whitelist.
-The default black list is defined as `*`, meaning that requests cannot be deserialized at all and the Ejbd transport in fact cannot be used.
-
-The blacklist and whitelist is configured via the system properties:
-
-- `tomee.serialization.class.whitelist`
-- `tomee.serialization.class.blacklist`
-
-You will also find these properties in [System Properties Listing](properties-listing.html)
-
-These rules apply for the whitelist:
-
-- The whitelist has a lower priority than the blacklist. That means a class that is part of the blacklist cannot be whitelisted and will always be refused.
-- If a whitelist is not defined, either by not defining the property at all or defining it with an empty value, every class is on the whitelist. In this case only the blacklist applies.
-- If a whitelist is defined it must be a comma separated list of prefixes of fully qualified class names. Then deserialization of an object fails if its class is not part of this whitelist. A class is on the whitelist if its fully qualified classname is prefixed by one of the values in the whitelist.
-
-These rules apply for the blacklist:
-
-- If the blacklist should be deactivated it must be configured to the value `-`. This will open your system to the serialization vulnerability if you don't configure a whitelist!
-- If the blacklist is not configured its default value is `org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Process` so that for example the class `org.apache.commons.collections.functors.InvokerTransformer` cannot be deserialized.
-- If the blacklist is configured with an empty value the blacklist is effectively `*`, therefore preventing any Ejbd communication.
-- If you want to blacklist certain classes the property must be configured to a comma separated list of prefixes of fully qualified class names. A class is on the blacklist if its fully qualified classname is prefixed by one of the values in the blacklist.
-
-The default for `tomee.serialization.class.whitelist` is empty, the default for `tomee.serialization.class.blacklist` is `*` since TomEE 1.7.4.
-
-If an EJB request fails because a class is not whitelisted you will find this log entry:
-
- WARN - "null OEJP/4.7" FAIL "Security error - foo.Bar is not whitelisted as deserializable, prevented before loading it." - Debug for StackTrace
-
-If you trust this class and want to support serialization in remote communication you have to configure these properties appropriately both on server side as well as on client side.
-
-If you only want to support serialization of the classes `foo.Bar` and `foo.Baz` you can configure the properties like this:
-
- tomee.serialization.class.whitelist = foo.Bar,foo.Baz
- tomee.serialization.class.blacklist = -
-
-If you trust all classes in the package `foo` define the properties like this:
-
- tomee.serialization.class.whitelist = foo.
- tomee.serialization.class.blacklist = -
-
-(Don't forget the trailing `.` after foo, as it will also whitelist all classes in the package `foo2` otherwise.)
-
-If you trust all classes in the package `foo` except the class `foo.Bar` you have to configure the properties like this:
-
- tomee.serialization.class.whitelist = foo.
- tomee.serialization.class.blacklist = foo.Bar
-
-
-
-#### Revert to behavior of TomEE 1.7.3
-
-TomEE 1.7.3 already contained a fixed blacklist that was not configurable and contained the packages org.codehaus.groovy.runtime, org.apache.commons.collections.functors and org.apache.xalan including subpackages and the class java.lang.Process.
-If you know that your applications runs on TomEE 1.7.3 but does not on TomEE 1.7.4 showing the aforementioned log message, you can define the configuration so that the serialization will work in the same way as it did with TomEE 1.7.3:
-
- tomee.serialization.class.whitelist =
- tomee.serialization.class.blacklist = org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan,java.lang.Process
-
-Please note that with this configuration your server may be vulnerable to Java serialization attacks not yet identified by the Zero Day initiative.
-Also note that the following versions of the affected libraries have been patched and approved by the Zero Day initiative and *may* be safe to deserialize.
-
-- Groovy 2.4.4
-- Commons Collections 3.2.2
-- Xalan 2.7.2
-
-As Ejbd transport is tunneled over HTTP please make sure that the `ServerServlet` is not publicly accessible.
-When the applications running on TomEE do not package the `ServerServlet` themselves ensure that the URL http://<host>:<port>/tomee/ejb is not accessible from untrusted sources.
-
-If your applications package declare it in their own web.xml make sure that the respective URL is not accessible from untrusted sources.
-
-#### Revert to behavior of TomEE 1.7.2
-
-TomEE 1.7.2 did not have any kind of blacklist when deserializing objects over Ejbd.
-If you want to revert to this behavior you can simply deactivate the blacklist with this configuration:
-
- tomee.serialization.class.whitelist =
- tomee.serialization.class.blacklist = -
-
-Note that this configuration makes your system highly vulnerable to serialization attacks!
-Consider your system as unsafe!
-
-#### Remote communication and Arquillian tests
-
-The mechanism described above principally also works when running Arquillian tests.
-As the Ejbd transport is already used for deploying applications all Arquillian tests would fail with the default settings.
-
-Therefore the TomEE Arquillian adapter automatically starts the container so that all classes except for a set of well-know dangerous classes are whitelisted.
-
-As Ejbd is by default disabled since TomEE 7.0.0, the TomEE Arquillian adapter automatically activates it when starting a remote container.
-
-#### Remote communication and the TomEE Maven Plugin
-
-The same mentioned above on Arquillian and TomEE is also valid when using the TomEE Maven Plugin.
http://git-wip-us.apache.org/repos/asf/tomee/blob/6bbcdc10/docs/embedded-and-remotable.adoc
----------------------------------------------------------------------
diff --git a/docs/embedded-and-remotable.adoc b/docs/embedded-and-remotable.adoc
new file mode 100644
index 0000000..ee6cc5e
--- /dev/null
+++ b/docs/embedded-and-remotable.adoc
@@ -0,0 +1,175 @@
+# Embedded and Remotable
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+# Overview
+
+This example shows how to use OpenEJB3's remoting capabilities in an
+embedded scenario. By remoting we mean that you wish to allow _clients
+in other vms_ access your ejbs. _Note, you do not need to go to this
+extreme to unit test ejbs with remote interfaces._
+
+The basic recipe is the same for a standard embedded scenario but with
+these added ingreditents:
+
+* _openejb.embedded.remotable_ property
+* _openejb-ejbd_ jar
+
+While creating the InitialContext, pass in the
+openejb.embedded.remotable property with the value of "true". When this
+is seen by the LocalInitialContextFactory, it will boot up the Server
+ServiceManager in the VM which will in turn look for ServerServices in
+the classpath.
+
+Provided you have the openejb-ejbd jar in your classpath along with it's
+dependencies (openejb-server, openejb-client, openejb-core), then those
+services will be brought online and remote clients will be able to
+connect into your vm and invoke beans.
+
+If you want to add more ServerServices such as the http version of the
+ejbd protocol you'd simply add the openejb-httpejbd jar to your
+classpath. A number of ServerServices are available currently:
+
+* openejb-ejbd
+* openejb-http
+* openejb-telnet
+* openejb-derbynet
+* openejb-hsql
+* openejb-activemq
+
+_The source for this example is in the "telephone-stateful" directory
+located in the openejb:download.html[openejb-examples.zip] available on
+the http://tomee.apache.org/downloads.html[download page]._
+
+\{note} If your goal is simply to unit test beans with remote
+interfaces, this is _not_ the right example for you. The
+LocalInitialContextFactory completely supports remote interfaces and all
+spec required pass-by-value (serialization) semantics without the need
+for network sockets. This example shows the use of OpenEJB in an
+embedded environment where connection _outside_ the vm is
+required.\{note}
+
+# The Code
+
+For this example we have a simple Stateful bean called TelephoneBean as
+defined below. As a simple way of demonstrating the state we have to
+methods: speak and listen. You call _speak_ and pass in some text, then
+you call _listen_ to get your answer.
+
+== bean
+
+\{snippet:id=code|url=openejb3/examples/telephone-stateful/src/main/java/org/superbiz/telephone/TelephoneBean.java|lang=java}
+
+== business interface
+
+\{snippet:id=code|url=openejb3/examples/telephone-stateful/src/main/java/org/superbiz/telephone/Telephone.java|lang=java}
+
+:jbake-title: EJB3 Notes} The bean class uses the annotation _@Remote_ but
+does not specify a list of interfaces as is normally required. Per EJB3
+rules, if the bean implements exactly _one business interface_ it may
+use @Remote with no other values and that business interface is then
+implied to be a remote business interface. The same rule applies to
+identical usage of @Local.
+
+The critical thing to know is that if you add another interface the
+rules change and require that you specify both interfaces in the @Remote
+annotation as in @Remote(\{Telephone.class, SecondInterface.class}).
+\{tip}
+
+# Embedding
+
+We're going to embed OpenEJB3 into a plain JUnit TestCase as a simple
+means of demonstrating the remote capabilities. We'll do the embedding
+in our test setUp method, then will make two test methods: - one for
+invoking the bean's remote interface via the
+_LocalInitialContextFactory_ which goes straight against the embedded
+container system - one for invoking the bean's remote interface via the
+_RemoteInitialContextFactory_ which connects to a Socket and
+communicates to the embedded container system over the ejbd protocol.
+
+== setUp
+
+\{snippet:id=setup|url=openejb3/examples/telephone-stateful/src/test/java/org/superbiz/telephone/TelephoneTest.java|lang=java}
+
+== LocalInitialContextFactory: making in-vm calls to a remote business
+
+interface
+
+\{snippet:id=localcontext|url=openejb3/examples/telephone-stateful/src/test/java/org/superbiz/telephone/TelephoneTest.java|lang=java}
+
+== RemoteInitialContextFactory: making networked calls to a remote
+
+business interface
+
+This is the part you would want to do in apps that are running a
+different VM than the one in which the ejb container is embedded. These
+"client" VMs need only have the the _openejb-client jar_ in their
+classpath and connect to OpenEJB via the RemoteInitialContextFactory
+like any other remote EJB client.
+
+\{snippet:id=remotecontext|url=openejb3/examples/telephone-stateful/src/test/java/org/superbiz/telephone/TelephoneTest.java|lang=java}
+
+# Maven setup
+
+\{snippet:id=desc|url=openejb3/examples/telephone-stateful/pom.xml}
+
+\{snippet:id=openejbdep|url=openejb3/examples/telephone-stateful/pom.xml|lang=xml}
+
+# Running
+
+Running the example is fairly simple. In the "telephone-stateful"
+directory of the openejb:download.html[examples zip] , just run:
+
+$ mvn clean install
+
+Which should create output like the following.
+
+....
+-------------------------------------------------------
+ T E S T S
+-------------------------------------------------------
+Running org.superbiz.telephone.TelephoneTest
+Apache OpenEJB 3.0 build: 20080408-04:13
+http://tomee.apache.org/
+INFO - openejb.home =
+....
+
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful INFO -
+openejb.base =
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful INFO -
+Configuring Service(id=Default Security Service, type=SecurityService,
+provider-id=Default Security Service) INFO - Configuring
+Service(id=Default Transaction Manager, type=TransactionManager,
+provider-id=Default Transaction Manager) INFO - Configuring
+Service(id=Default JDK 1.3 ProxyFactory, type=ProxyFactory,
+provider-id=Default JDK 1.3 ProxyFactory) INFO - Found EjbModule in
+classpath:
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful/target/classes
+INFO - Configuring app:
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful/target/classes
+INFO - Configuring Service(id=Default Stateful Container,
+type=Container, provider-id=Default Stateful Container) INFO -
+Auto-creating a container for bean TelephoneBean:
+Container(type=STATEFUL, id=Default Stateful Container) INFO - Loaded
+Module:
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful/target/classes
+INFO - Assembling app:
+/Users/dblevins/work/openejb-3.0/examples/telephone-stateful/target/classes
+INFO - Jndi(name=TelephoneBeanRemote) -->
+Ejb(deployment-id=TelephoneBean) INFO - Created
+Ejb(deployment-id=TelephoneBean, ejb-name=TelephoneBean,
+container=Default Stateful Container) INFO - Deployed
+Application(path=/Users/dblevins/work/openejb-3.0/examples/telephone-stateful/target/classes)
+** Starting Services ** NAME IP PORT +
+ejbd 127.0.0.1 4201 +
+admin thread 127.0.0.1 4200 +
+------- Ready! Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time
+elapsed: 0.89 sec
+
+....
+Results :
+
+Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
+....