<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 12px;" lang="x-western">Hey
folks,
<br>
<br>
The general purpose of this note is to explore refactoring some of our
jars to reduce some problems that have come about due to our signing of
jars.
<br>
<br>
So, let me start with a description of the problem. Essentially, the
core issue is around the simple replacement of an EAP signed jar with
an unsigned jar. While we have a system in place to have QE get
one-off patches signed in a relatively responsive manner, we are still
left with cases such as a diagnostic jar created by support to track
down problems, or a customer that, understanding that it would not be
supported, wishes to make a change for their system (one of the
advantages of OSS, of course).
<br>
<br>
The problem with such a substitution is the fact that a classloader
will not load classes from a packages that appear in differently signed
jars. So, for example, even though class org.jboss.A may only occur in
an unsigned A.jar, loading it will cause a security exception if class
org.jboss.B was loaded from a signed B.jar. Now, the first step to
resolve this would be to replace both A.jar and B.jar with unsigned
versions. But, we then often run into a transitive entanglement.
B.jar may contain classes from package org.jboss, but also
org.hibernate. So, you have to have unsigned versions of C.jar and
D.jar that contain the hibernate packages. But, they have an
org.apache package, and so on.
<br>
<br>
Using TattleTale with some custom reports, I generated "signed jar
groups" identifying clusters of jars that would need to all be replaced
as unsigned if any one is unsigned. For the largest group, I created a
graph of the dependencies shown in
<a class="moz-txt-link-freetext" href="http://community.jboss.org/wiki/SignedJarDependenciesExample">http://community.jboss.org/wiki/SignedJarDependenciesExample</a>
(getopt_jar_Group.png, named by the first jar listed in the group from
the report.)
<br>
<br>
The figure shows the jars with a line connecting them if they have one
or more packages in common (I also generate detailed plots with a
labelled line for each package in common if anyone wants to see them,
but for the "getopt" group, the detailed plot is quite large and hard
to read.) Clearly, lots of unrelated jars are wound up in this group.
But, we can chip away at this with a bit of analysis. I'll give three
examples.
<br>
<br>
First, consider the set of jar files just to the right of the center
grouped around jboss-ejb3-core.jar. This set of jars is tied into the
rest of the graph through the connection between
jboss-as-ejb3-deployer.jar and jboss.jar. The package that ties them
is org.jboss.as.javaee. In this case there appears to be only two
classes involved. In jboss.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleIdentifier and in
jboss-as-ejb3-deployer.jar there is
org.jboss.as.javaee.SimpleJavaEEModuleInformer (which has an inner
class). So, in this case, we can break off a chunk of the signed jar
group by, for example, changing a package name:
org.jboss.as.javaee.ejb3.SimpleJavaEEModuleInformer
<br>
<br>
Next, from the graph, we can see that there is a group of jar files on
the far left that is tied in by a connection between the
jboss-system-jmx.jar and the jboss.jar. In this case, the package is
org.jboss.deployment. There are several classes in jboss.jar and a
handful in jboss-system-jmx.jar that are in this package. So, options
might include renaming the package for the classes in the
jboss-system-jmx.jar, moving them to jboss.jar, or separating the
org.jboss.deployment classes between them into a new jar:
jboss-deployment.jar.
<br>
<br>
Finally, staying on the far left of the graph we see that run.jar and
shutdown.jar are tied into some third party jars such as getopt.jar,
hsqldb.jar and jdom-1.0.jar. These are due to use of classes in the
default package. Further, the default package is included because the
contents of the getopt.jar are incorporated into run.jar and
shutdown.jar. So, this connection to third party jars can be broken
out by removing the GetOpt related classes from run.jar and
shutdown.jar and relying on the Class-Path: attribute in their
manifests.
<br>
<br>
So, in the end, it would seem to be beneficial to refactor package
locations such that there is not such widespread entanglement. From
the signed jar perspective, it would be best if each package only
appeared in one jar. Of course, there are often engineering reasons to
separate classes in the same package into different jars. However, I
think it's not unreasonable that these should be relatively small in
number and they should be functionally coherent. At any rate, it would
appear to be something we could attack incrementally as indicated by
the three examples above.
<br>
<br>
Originally, when discussing this with other folks, we thought perhaps
we should just open jiras to address the problem. But, on considering
that, it seemed that perhaps a discussion on a larger game plan would
be a better approach, even if it just ended up with the original plan
of opening some jiras to "chip away" at the problem.
<br>
<br>
So, I apologize for a long, dense note. For those of you that made it
through, any thoughts, suggestions?
<br>
<br>
Cheers,
<br>
Mike C.
<br>
</div>
</body>
</html>