RE: Re[2]: Xerces 1 use in XMLC

Jacob,

I was trying to run the unit tests, but I encountered some problems. The plan was to run the unit tests on a freshly-checked-out version of xmlc first, and then rerun them with my modifications to see if there were any failures....

Unfortunately, some unit tests seem to fail on the stock xmlc itself (haven't gotten to the tests with my changes yet).

I am using redhat linux with j2sdk1.4.1, ant 1.5.1. I tried to run the tests with and without jikes1.17, and I get different results. Could anybody look at the output and tell me what might be wrong? I am attaching 2 files (one for the javac test and the other for jikes)....

 

Thanks,

Enrico.

-----Original Message-----
From: Jacob Kjome [mailto:hoju@xxxxxxxx]
Sent: Tuesday, October 22, 2002 8:04 AM
To: xmlc@xxxxxxxxxxx
Subject: RE: Re[2]: Xmlc: Xerces 1 use in XMLC

See comments inline below....

At 09:01 PM 10/21/2002 -0500, you wrote:

Jacob,

>>We are thinking of using barracuda as a presentation framework, along
>>with using axis as our wsdl/web services toolkit. It seems like the
>>coexistence of xerces1 (needed by XMLC/barracuda) and xerces2 (needed by
>>axis) is going to create problems. I am not sure if you can have those 2
>>versions of parsers in the same VM space (I doubt it...), so I was
>>thinking of renaming org.apache.xerces to org.apache.xerces144 in the
>>xerces-xmlc source files and packaging one xmlc.jar that included it
>>all.....
>>
>>Am I nuts? :)

>hmmm..... I'm not sure how that would be done since there are some thing
>that were modified in Xerces that were needed as a requirement of XMLC-2.1
>to work.

That was exactly my point: XMLC has (and requires) its own version of xerces1.44, and I was wondering if it would be better for me to temporarily change the xerces source code inside the xmlc tree to use a different package name (i.e. org.apache.xerces144). That would force xmlc to import and instantiate org.apache.xerces144.DOMParser(), which would not cause any problems in case you need to use the xerces 2 apis along with 1.44.

(I am not suggesting to apply any of these chamges to the source base, I am just using this as an expedient to allow both parsers to coexist while waiting for the xerces 2 port. The need to use xerces 2 comes from both our developers and indirectly from our need of using other libraries requiring xerces2 in the same VM space....)

Sounds like a lot of trouble, but if that is what you need, then so be it.

>One thing that might work, in relation with Tomcat-4.1.xx, is to leave
>Xerces-2.x.x in $CATALINA_HOME/common/endorsed and put
>xerces-1.4.4-xmlc-2.1.jar in $CATALINA_HOME/shared/lib.  That way, the main
>parser that will be used is Xerces-2, but the fact that the 1.4.4 parser is
>also available means that some of the packages that XMLC uses which only
>exist in Xerces-1.4.4 and not in Xerces-2 will still be there for XMLC to
>utilize while not forcing Xerces-1.4.4 on your other apps that require
>Xerces-2.

This unfortunately would not apply, since we're planning to use JBoss with jetty as our http server/servlet container....(I know we could probably do a similar set of things on jboss/jetty, but testing whether all the other libraries we plan to use would work on top of the patched xerces1.44 jar would be quite some work....)

Yes, probably, however, there is nothing particularly wrong with Xerces-1.4.4's xml parsing.  It provides the same standard packages as Xerces-2.  It is just that Xerces-1.4.4 was getting unwieldy to continue development on and they wanted to have a clean-room version that they could optimize and such.  If an app sticks with the standard xml parsing libraries and doesn't use Xerces extensions, then either parser should work.  Heck, you should be able to use Crimson. However, if your packages do you xerces extensions (like xmlc-2.1 does) then you will marry yourself to a particular version of Xerces.  Hopefully future releases of XMLC can get away from that dependency.

>That said, most apps, if they just use the standard XML parser api's,
>should be compatible with either Xerces-1.4.4 or Xerces-2.  XMLC has a
>dependency on Xerces-1.4.4 primarily because it uses Xerces extensions in
>1.4.4 which weren't carried over to Xerces-2.  So, you might want to do a
>quick test and see if my suggestion above works for your app.  If it does,
>then forget about all the renaming stuff as you would end up having to
>remap the XMLC source to look at the renamed Xerces-1.4.4 packages in order
>to make that approach work.

>Let us know how things go.

Well, after almost a day of hack^H^H^H^H work (and BTW, you should check out the refactoring capabilities of IBM's eclipse IDE...), I think I managed to get a single xmlc.jar file that contains the xmlc classes, the GNU regexp classes (these were not really needed, since there were no xmlc-specific changes from their distribution) and both xerces1.44-xmlc and jtidy (oops, I just thought of this: was jtidy also patched from the standard distribution release? If not, then I did some jtidy package renaming work for nothing....)

I think there were some minor fixes to JTidy.  You should be able to query CVS to get the mod's done to the original.   Not sure of the actual command to use.  Maybe Richard Kunze can help out here?

Again, I think this is just a hack, but it might get our dev. team somewhere while we wait for the xerces2 port (now that I dug into the code, I can see why it would take some time..). My next plan is to run all the XMLC unit tests and see if this behaves as expected. (I already managed to compile and test some simple html/java files....).

Nice!

One more question: is there any code that would allow xmlc recompilation on the fly for jetty? I noticed there was some code which was specific to enhydra and tomcat, but nothing about jetty...

Recompilation was turned off by default because it was app specific.  You can enable it if you build it from scratch and include the enhydra libraries.  Of course, it would still be for enhydra recompilation.  Richard is working on a generic reloading feature which should be out in the next release if it isn't already in CVS.

Sounds like your effort will bear fruits for you.  Just sounds like a lot of trouble to go to.  Hopefully we'll have a release with Xerces-2.x.x support sometime soon!

Enrico.

xmlc-javac-tests.txt
Description: xmlc-javac-tests.txt

xmlc-jikes-tests.txt
Description: xmlc-jikes-tests.txt