from a disinterested 3rd party. This does not constitute a formal response
of any kind, but is rather part of the required development discussion
regarding this.
This is posted WITHOUT PREJUDICE.
In general, considering that some of the Geronimo developers also
contributed code to JBoss, it would be neither surprising nor improper if
there were found to be some identical pieces. The requirement should be
that authors submit only such code for which they have clear title.
Although "former project members cannot avoid the rights of the copyright
owner of the collective work that they intend to copy or change", that
does not preclude an author from also providing his or her own code to the
ASF for licensing under the ASL. As far as is known, there is no code
within Geronimo that was exclusively licensed to JBoss, or is included in
Geronimo without the author's permission.
With respect to the specific exhibits:
Exhibit A: Similarities between two subclasses of
org.apache.lo4j.Level, each of which
implements a TRACE level.The classes in question are org.apache.geronimo.code.log.XLevel and
org.jboss.logging.XLevel. Both of them extend org.apache.log4j.Level,
which imposes (and provides) some of the common structure and names. The
classes, themselves, are trivial implementations of a new logging level,
the structure of which is dictated by Apache Log4J. The code seems to be
as similar, and as different, as one would expect from two authors
implementing a Log4J TRACE log level based upon existing Log4J code.
Exhibit B: Similarities between two PatternParser subclasses
in support of the nested diagnostic context pattern.The similarities come from the fact that both code bases implement "nested
diagnostic contexts" as described by Neil Harrison in "Patterns for
Logging Diagnostic Messages", which can be found in the book "Pattern
Languages of Program Design 3", published in 1997 by Addison-Wesley (ISBN:
0201310112). Apache Log4J implements this class in org.apache.log4j.NDC.
This class describes how it is to be used, including the use of a
"distinctive stamp."
The two classes in question, org.apache.geronimo.code.log.PatternParser
and org.jboss.logging.layout.PatternParserEx, are both trivial extentions
of org.apache.log4j.helpers.PatternParser in support of this documented
pattern. Again, Apache Log4J provides and imposes structure. I would
expect this similarity to morph shortly because both Geronimo and JBoss
are using Log4J v1.2.8. Log4J v1.3, still in development, completely
refactors how pattern handling is done within Log4J.
ref: http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html
Exhibit C: InvocationType
The pattern
public static final TYPE NAME = new TYPE(...);
is boilerplate. It is a well-established Java implementation pattern
found in the JDK and many other code bases. The aforementioned Log4J code
base has an almost identical set of lines, differing only in TYPE, NAME
and parameters to the TYPE constructor.
The class name, InvocationType, is entirely descriptive of what the class
represents. The term "Invocation" is also found in the term RMI -- Remote
Method Invocation -- and the class simply represents the type of
invocation. The values of the first parameter: "REMOTE", "HOME", "LOCAL"
and "LOCALHOME" are defined by a J2EE Specification, not by JBoss. The
second parameter is an ordinal from 0 to 3, and provides its location
within a static array. If "I" were writing the code, "I" might have not had
that parameter, but most programmers probably would. The remaining
parameters are unique to Geronimo, not found in JBoss, and define the
properties of the invocation.
ref:
http://cvs.apache.org/viewcvs/incubator-geronimo/modules/core/src/java/ org/a
pache/geronimo/core/service/InvocationType.java?annotate=HEAD
"Further, although not reproduced as an exhibit, we direct your attention to the similarities in the files named org.apache.geronimo.common.Invocation (Geronimo) and org.jboss.invocation.Invocation (JBoss). Both of these files contain what JBoss believes is highly JBoss-specific payloads, which are named "AsIs", "Transient," and "Marshalled."
Upon investigation, it is seen that Geronimo's Invocation class was entirely
rewritten more than two months prior to the communication from Testa, Hurwitz
and Thibeault. The well-established RPC/RMI concepts of transient and
marshalled data are implemented completely differently in current Geronimo
code.
