<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<body link="#355491" alink="#4262a1" vlink="#355491" style="background: #e2e2e2; margin: 0; padding: 20px;">
<div>
<table cellpadding="0" bgcolor="#FFFFFF" border="0" cellspacing="0" style="border: 1px solid #dadada; margin-bottom: 30px; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td>
<table border="0" cellpadding="0" cellspacing="0" bgcolor="#FFFFFF" style="border: solid 2px #ccc; background: #dadada; width: 100%; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
<tbody>
<tr>
<td bgcolor="#000000" valign="middle" height="58px" style="border-bottom: 1px solid #ccc; padding: 20px; -moz-border-radius-topleft: 3px; -moz-border-radius-topright: 3px; -webkit-border-top-right-radius: 5px; -webkit-border-top-left-radius: 5px;">
<h1 style="color: #333333; font: bold 22px Arial, Helvetica, sans-serif; margin: 0; display: block !important;">
<!-- To have a header image/logo replace the name below with your img tag -->
<!-- Email clients will render the images when the message is read so any image -->
<!-- must be made available on a public server, so that all recipients can load the image. -->
<a href="http://community.jboss.org/index.jspa" style="text-decoration: none; color: #E1E1E1">JBoss Community</a></h1>
</td>
</tr>
<tr>
<td bgcolor="#FFFFFF" style="font: normal 12px Arial, Helvetica, sans-serif; color:#333333; padding: 20px; -moz-border-radius-bottomleft: 4px; -moz-border-radius-bottomright: 4px; -webkit-border-bottom-right-radius: 5px; -webkit-border-bottom-left-radius: 5px;"><h3 style="margin: 10px 0 5px; font-size: 17px; font-weight: normal;">
Modular Serialization
</h3>
<span style="margin-bottom: 10px;">
modified by <a href="http://community.jboss.org/people/jason.greene">Jason Greene</a> in <i>JBoss AS7 Development</i> - <a href="http://community.jboss.org/docs/DOC-17244">View the full document</a>
</span>
<hr style="margin: 20px 0; border: none; background-color: #dadada; height: 1px;">
<div class="jive-rendered-content"><h2>Understanding Class-loading Issues</h2><p>When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inheriting classes. The class reference is simply a class name.<strong><em> The assumption is that the recieving party has all of the sender's class definitions readily accessable to the thread's current context class loader. </em></strong>This means very different semantics than those commonly expected in a normal in-vm invocation accross class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same phsysical, already constructed, object instance is being passed around. </p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themesleves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility. </p><h2>Problem A - Subclass Visibility</h2><p>In this example a common super class is shared between a sender and a receiver, but an extened subclass used by the sender's implementation is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.</p><p><a href="http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-7-17060/ModularSerializationExample.png"><span> http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-7-17060/450-438/ModularSerializationExample.png </span></a></p><h2>Problem B - Reference / Aggregation Visibility</h2><p>In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.</p><p><a href="http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-7-17061/ModularSerializationProblemB.png"><span> http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-7-17061/450-439/ModularSerializationProblemB.png </span></a></p><h2>Solution 1 - Require Components To Share All Needed Classes</h2><p>This may require altering the application / component code to always use common shared classes in the serialization stream. A negative side effect of this is that it puts a larger burdeon on the application / component developer. A positive benefit is that the wire format is compatible standard serialization.</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><h2>Solution 2 - JBoss Marshaling - Modular Serialization</h2><p>This solution is currently available using the ModularClassResolver like so:</p><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><pre class="jive-pre"><code class="jive-code jive-java"> RiverMarshallerFactory factory = <font color="navy"><b>new</b></font> RiverMarshallerFactory();
MarshallingConfiguration configuration = <font color="navy"><b>new</b></font> MarshallingConfiguration();
configuration.setClassResolver(ModularClassResolver.getInstance(moduleLoader));
</code></pre><p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p><p>This changes the format of the stream such that the owning module identifier is written in addition to the name of any class referenced in the stream. This allows jboss marshalling to easily locate the "correct" class loader for deserializing the class. The advantage of this approach is that application/component code need not be changed, and that the same practices used in local invocation also apply with remote serialization. The drawback is that the serialization format must be alteredm potentially introducing compatiblity problems with older clients. In addition non-modular clients, if they need to be supported, will not understand the format. Solution 3 is the recommended approach when compatibility is a concern</p><h2>Solution 3 - Support both Modular and Standard Serialization</h2><p>This is the same approach as 2 but adds the ability to handle both styles of streaming. This is achieved by either having the client ignore the information, or having some kind of negotiation process (protocol version etc).</p></div>
<div style="background-color: #f4f4f4; padding: 10px; margin-top: 20px;">
<p style="margin: 0;">Comment by <a href="http://community.jboss.org/docs/DOC-17244">going to Community</a></p>
<p style="margin: 0;">Create a new document in JBoss AS7 Development at <a href="http://community.jboss.org/choose-container!input.jspa?contentType=102&containerType=14&container=2225">Community</a></p>
</div></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>