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

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....)

>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....)

>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....)

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....).

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...

Enrico.

<<winmail.dat>>