General
Yes, this is an annoying bug in EJOE 0.4.0. It will be fixed in the next minor version. Please use the workaround explained in the Tracker [1733079].
| [top] |
Versions from 0.3.2 to 0.3.4 use NIO only for connection
accept/select operations by default, so that invoking of (de)serialize
adapters can be done directly using blocking io streams.
This can be a significantly improvement over non blocking IO. Support for
partial NIO read/write was also added in version 0.3.2.
Even though blocking I/O streams perform better in some
enviroments with large objects, the performance differences aren't so
abundantly clear now. If you are using a prior version than
0.3.2 there is no possibility to avoid these performance
issues.
Take a look at this
article if you want to know why usage of non-blocking
I/O can cause some major drawbacks in EJOE.
With 0.3.4 EJOE restarted using non-blocking I/O by default because in most scenarios non-blocking I/O does outperform the blocking mode. Usage of blocking mode can be helpful only if your are exchanging *really* large objects. To disable non blocking mode anyway use EJServer#enableNonBlockingIO(false).
| [top] |
See above to get an idea why that happens. As of version 0.3.2 this shouldn't happen anymore when using blocking IO. Don't use EJServer.enableNonBlockingIO(true). For version =0.3.4 you can use EJServer#enableNonBlockingIO(false) to try blocking mode.
| [top] |
Use blocking I/O (see above) and/or Increase the value for the max. used memory:
java -mx256m -cp ...
| [top] |
Good news: As of version 0.3.2 EJOE offers selective compression. It will be used if compression is enabled in the EJOE server and a client requests compression.
To enable compression on serverside use:
ejserver.enableCompression();
To request compression on clientside use:
ejclient.enableCompression(true);
| [top] |
Not at the moment. We are looking for options how to support HTTP-Tunneling in conjunction with java nio. Hints are very welcome...
This feature is scheduled for version 0.4.0
| [top] |
Yes, from version 0.3.3 EJOE uses the XStreamAdapter (de.netseeker.adapter.XStreamAdapter) as default (de)serialization mechanism.
The XStreamAdapter is based on the great XStream library
which is known to (de)serialize nearly everything on the (java) planet.
For prior versions you have to enable the XStreamAdapter in EJServer and EJClient manually:
EJServer ejserver = new EJServer(myServerHandler, new XStreamAdapter())
| [top] |
This feature was implemented in version 0.3.3.
Prior versions doesn't support selective adapter handling and require
the same SerializeAdapter on client- and serverside.
| [top] |
One of the fastest adapters is the ObjectStreamAdapter. Be aware that using this adapter has some (possible) drawbacks:
Another efficient solution is to use the JavolutionAdapter with custom XML Formats. Again this solution has drawbacks too:
| [top] |
Either you are using the CastorAdapter without a mapping file or the adapter can not locate the mapping file or your mapping is incomplete. In general using the CastorAdapter makes sense only when providing a castor mapping file.
| [top] |
You are using javolution 4.0. EJOE does not support javolution = 4.0 yet, because they decided to break backward compatibility within their XML-marshalling/unmarshalling API.
| [top] |
Unfortunately it is just simple: You can not use these types with EJOEs RemoteReflection and Hessian. Hessian maps these types to other java types during serialization/deserialization so that the argument types within a reflection call will not match. Please see the Hessian/Burlap Java Binding Draft Spec for details.
| [top] |
Unfortunately it is just simple: You can not use byte[] with EJOEs RemoteReflection and SoJo. SoJo maps byte[] to java.util.ArrayList during serialization/deserialization so that the argument type within a reflection call will not match.
| [top] |
For beans you will need a so called "dotBetwixtFile" (.betwixt). Please take a look into the betwixt documentation.
| [top] |
Versions prior to 0.4.0 don't support that feature. It was scheduled for 0.4.0 and is already implemented in the current version in CVS. Use EJClient#setAdapterStrategy( EJConstants.ADAPTER_STRATEGY_DIRECT ) to tell the client to use ByteBuffers in direct manner. Then you can invok EJClient#execute() with a ByteBuffer and it will return a ByteBuffer. Note: Your ServerHandler has to return a ByteBuffer to EJOE otherwise a ClassCastExeption will be thrown.
| [top] |
Use the AdapterFactory to register the adapter.
| [top] |
Not at the moment, but support for symetric key encryption using stream ciphers is scheduled for 0.5.0. At the meantime you can use netseekers HC128Adapter to protect your network traffic.
| [top] |
1.4 or later.
| [top] |
The following dependencies are required when using the default SerializeAdapter (de.netseeker.adapter.XStreamAdapter):
They can be avoided when using the ObjectStreamAdapter or JavaBeansXmlAdapter.The following dependencies are required only when using the CastorAdapter:
The following dependencies are required only when using the BetwixtAdapter:
The following dependencies are required only when using the JavolutionAdapter:
| [top] |
EJOE uses the standard java logging mechanism (java.util.logging).
See http://javaalmanac.com/egs/java.util.logging/pkg.html#Configuration,
respectively http://javaalmanac.com/egs/java.util.logging/Props.html for details.
| [top] |
Download the source archive or checkout from CVS (see the download and cvs links on the left side) and run maven with the following commandline:
maven dist -Djava.util.logging.config.file=maven-logging.properties
| [top] |
Sure there are. We don't know all and the following list is neither a recommendation nor a benchmark and may contain also projects which aren't really related to EJOE.
| [top] |
Hehe, because we are poor german developers and we speak german here. English is not our first language, hence our english documentation is more or less readable but far from perfect. Well, to be honest it is more than far from perfect. Please, please help us with really good translations of our german documentation!
| [top] |
Please see above. Once again: Please, please help us with really good
translations of our german documentation!
A translation of our german entry guide
would solve a lot of documentation issues...
| [top] |