Bug 152255

Summary: Can't build xerces-j2 SRPM
Product: [Fedora] Fedora Reporter: Anthony Green <green>
Component: xerces-j2Assignee: Gary Benson <gbenson>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: gbenson, tromey, vnasardinov
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-14 12:58:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 136450    
Attachments:
Description Flags
Build log.
none
test case showing that xerces-j2 references but doesn't provide org.w3c.dom.TypeInfo none

Description Anthony Green 2005-03-26 20:44:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

Description of problem:
The xerces-j2 SRPM fails to build with java-1.4.2-gcj-compat.

It appears to be picking up org.w3c.dom classes from libgcj, instead of using the ones in xerces-j2.  The libgcj ones define extra abstract methods which xerces classes don't implement.

I'll attach the build log for review.

I'm using gcc-java-4.0.0-0.35.


Version-Release number of selected component (if applicable):
xerces-j2-2.6.2-4jpp

How reproducible:
Always

Steps to Reproduce:
1.Try to build the xerces-j2 SRPM
2.
3.
  

Additional info:

Comment 1 Anthony Green 2005-03-26 20:46:39 UTC
Created attachment 112364 [details]
Build log.

Comment 2 Tom Tromey 2005-03-30 21:12:09 UTC
I looked at this a little.

I suspect we want to back out xerces-j-build.patch and
instead use the "IBM JDK 1.4" task to handle setting the
compiler's bootclasspath properly.

This note seems vaguely relevant:

https://www.zarb.org/pipermail/jpackage-discuss/2004-June/005267.html

I think we would also have to include the xerces tool jar in the SRPM.
At least, the current sources don't include the ant task in question.
Also, based on the above, we may need to hack the ant task a little,
depending on whether and how it does the check of java.vendor.

Comment 3 Gary Benson 2005-04-01 15:33:46 UTC
The xalan-j2 SRPM is also failing to build because of the extra abstract
methods.  Hopefully this will disappear when the endorsed dirs stuff happens.

Comment 4 Tom Tromey 2005-04-01 17:38:10 UTC
I don't think the java.endorsed.dirs patch will change anything here.
That patch affects the runtime behavior of libgcj.  In particular it
lets you override selected parts of the core library.

But as I read this bug, the problem is that the compiler is picking
up newer XML classes than what it expects.  That is, it is pulling
these classes out of libgcj.jar directly (compilers don't as a rule
use reflection for this sort of thing).

So, endorsed dirs won't change anything there.  That, plus some other
stuff I read, suggests that the fix is to use the "IBM 1.4" build path.


Comment 5 Gary Benson 2005-04-21 10:23:18 UTC
I've made a hacked xjavac task which builds this correctly, and submitted a
patch as http://issues.apache.org/bugzilla/show_bug.cgi?id=34551.  Thanks for
your help Tom.

Comment 6 Gary Benson 2005-04-27 09:00:07 UTC
This fix depended on both the xjavac hack and my adding gcj endorsed dirs
support to xml-commons apis.  The latter caused no end of problems (see bug
155693) and I've had to revert it, so I'm reopening this while I try and figure
out other, less invasive ways to fix it.

Comment 7 Gary Benson 2005-05-23 09:44:37 UTC
Fixed in xerces-j2-2.6.2-4jpp_3fc

Comment 8 Vadim Nasardinov 2005-06-09 21:33:51 UTC
Created attachment 115279 [details]
test case showing that xerces-j2 references but doesn't provide org.w3c.dom.TypeInfo

xerces-j2-bz152255.patch breaks the xerces-j2 package under Sun's JDK.
See the attached test case.

The Apache-provided binary Ant (apache-ant-1.6.5-bin.tar.gz)
references org.apache.xerces.dom3.TypeInfo and provides same:

 | $ jcf-dump \
 |   --classpath $ANT_HOME/lib/xercesImpl.jar \
 |   --print-constants \
 |   org.apache.xerces.dom.AttrImpl | grep -F .TypeInfo
 | - Implements: 106=org.apache.xerces.dom3.TypeInfo
 | Method name:"getSchemaTypeInfo" public Signature:
144=()org.apache.xerces.dom3.TypeInfo
 | 
 | $ jar tvf $ANT_HOME/lib/xercesImpl.jar | grep TypeInfo
 |    411 Fri Feb 20 13:56:50 EST 2004 org/apache/xerces/dom3/TypeInfo.class


In contrast, FC4's xerces-j2 references
  org.w3c.dom.TypeInfo
but only provides
  org.apache.xerces.dom3.TypeInfo:

 | $ jcf-dump \
 |   --classpath /usr/share/java/xerces-j2-2.6.2.jar \
 |   --print-constants \
 |   org.apache.xerces.dom.AttrImpl | grep -F .TypeInfo
 | - Implements: 8=org.w3c.dom.TypeInfo
 | Method name:"getSchemaTypeInfo" public Signature: 140=()org.w3c.dom.TypeInfo

 | 
 | $ jar tvf /usr/share/java/xerces-j2-2.6.2.jar | grep TypeInfo
 |    411 Thu May 05 09:16:28 EDT 2005 org/apache/xerces/dom3/TypeInfo.class

Hence the exception in the attached test case.

Comment 9 Vadim Nasardinov 2005-06-09 21:35:27 UTC
Reopening.  See comment #8.


Comment 10 Gary Benson 2005-06-10 12:40:51 UTC
Can you try it with xerces-j2-2.6.2-4jpp_8fc (from dist-fc5) and see if it fixed it?

Comment 11 Vadim Nasardinov 2005-06-10 19:01:26 UTC
I tested it and it fixes both the simple test case (attachment 115279 [details])  and
my original use case that led me to this bug.

I'm not sure what I should change the status to -- I'll leave that to you.

Thanks.