Re[4]: Xerces 1 use in XMLC

Hello Enrico,

To tell you the truth, I've never run the XMLC unit tests before.
This is a question that you'll have to wait for Richard Kunze to
answer.

Jake

Tuesday, October 22, 2002, 9:22:50 AM, you wrote:

EB> Jacob,
EB> I was trying to run the unit tests, but I encountered some problems. The
EB> plan was to run the unit tests on a freshly-checked-out version of xmlc
EB> first, and then rerun them with my modifications to see if there were
EB> any failures....
EB> Unfortunately, some unit tests seem to fail on the stock xmlc itself
EB> (haven't gotten to the tests with my changes yet). 
EB> I am using redhat linux with j2sdk1.4.1, ant 1.5.1. I tried to run the
EB> tests with and without jikes1.17, and I get different results. Could
EB> anybody look at the output and tell me what might be wrong? I am
EB> attaching 2 files (one for the javac test and the other for jikes)....
 
EB> Thanks,
EB> Enrico.

EB>         -----Original Message-----
EB>         From: Jacob Kjome [mailto:hoju@xxxxxxxx] 
EB>         Sent: Tuesday, October 22, 2002 8:04 AM
EB>         To: xmlc@xxxxxxxxxxx
EB>         Subject: RE: Re[2]: Xmlc: Xerces 1 use in XMLC
        
        
EB>         See comments inline below....
        
EB>         At 09:01 PM 10/21/2002 -0500, you wrote:
        

EB>                 Jacob,
                
EB>                 >>We are thinking of using barracuda as a presentation
EB> framework, along
EB>                 >>with using axis as our wsdl/web services toolkit. It
EB> seems like the
EB>                 >>coexistence of xerces1 (needed by XMLC/barracuda) and
EB> xerces2 (needed by
EB>                 >>axis) is going to create problems. I am not sure if
EB> you can have those 2
EB>                 >>versions of parsers in the same VM space (I doubt
EB> it...), so I was
EB>                 >>thinking of renaming org.apache.xerces to
EB> org.apache.xerces144 in the
EB>                 >>xerces-xmlc source files and packaging one xmlc.jar
EB> that included it
EB>                 >>all.....
EB>                 >>
EB>                 >>Am I nuts? :)
                
EB>                 >hmmm..... I'm not sure how that would be done since
EB> there are some thing 
EB>                 >that were modified in Xerces that were needed as a
EB> requirement of XMLC-2.1 
EB>                 >to work.
                
EB>                 That was exactly my point: XMLC has (and requires) its
EB> own version of xerces1.44, and I was wondering if it would be better for
EB> me to temporarily change the xerces source code inside the xmlc tree to
EB> use a different package name (i.e. org.apache.xerces144). That would
EB> force xmlc to import and instantiate org.apache.xerces144.DOMParser(),
EB> which would not cause any problems in case you need to use the xerces 2
EB> apis along with 1.44.
                
EB>                 (I am not suggesting to apply any of these chamges to
EB> the source base, I am just using this as an expedient to allow both
EB> parsers to coexist while waiting for the xerces 2 port. The need to use
EB> xerces 2 comes from both our developers and indirectly from our need of
EB> using other libraries requiring xerces2 in the same VM space....)
                


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

EB>                 >One thing that might work, in relation with
EB> Tomcat-4.1.xx, is to leave 
EB>                 >Xerces-2.x.x in $CATALINA_HOME/common/endorsed and put 
EB>                 >xerces-1.4.4-xmlc-2.1.jar in $CATALINA_HOME/shared/lib.
EB> That way, the main 
EB>                 >parser that will be used is Xerces-2, but the fact that
EB> the 1.4.4 parser is 
EB>                 >also available means that some of the packages that
EB> XMLC uses which only 
EB>                 >exist in Xerces-1.4.4 and not in Xerces-2 will still be
EB> there for XMLC to 
EB>                 >utilize while not forcing Xerces-1.4.4 on your other
EB> apps that require 
EB>                 >Xerces-2.
                
EB>                 This unfortunately would not apply, since we're planning
EB> to use JBoss with jetty as our http server/servlet container....(I know
EB> we could probably do a similar set of things on jboss/jetty, but testing
EB> whether all the other libraries we plan to use would work on top of the
EB> patched xerces1.44 jar would be quite some work....)
                


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

EB>                 >That said, most apps, if they just use the standard XML
EB> parser api's, 
EB>                 >should be compatible with either Xerces-1.4.4 or
EB> Xerces-2.  XMLC has a 
EB>                 >dependency on Xerces-1.4.4 primarily because it uses
EB> Xerces extensions in 
EB>                 >1.4.4 which weren't carried over to Xerces-2.  So, you
EB> might want to do a 
EB>                 >quick test and see if my suggestion above works for
EB> your app.  If it does, 
EB>                 >then forget about all the renaming stuff as you would
EB> end up having to 
EB>                 >remap the XMLC source to look at the renamed
EB> Xerces-1.4.4 packages in order 
EB>                 >to make that approach work.
                
EB>                 >Let us know how things go.
                
EB>                 Well, after almost a day of hack^H^H^H^H work (and BTW,
EB> you should check out the refactoring capabilities of IBM's eclipse
EB> IDE...), I think I managed to get a single xmlc.jar file that contains
EB> the xmlc classes, the GNU regexp classes (these were not really needed,
EB> since there were no xmlc-specific changes from their distribution) and
EB> both xerces1.44-xmlc and jtidy (oops, I just thought of this: was jtidy
EB> also patched from the standard distribution release? If not, then I did
EB> some jtidy package renaming work for nothing....)
                


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

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


EB>         Nice!
        
        
        

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


EB>         Recompilation was turned off by default because it was app
EB> specific.  You can enable it if you build it from scratch and include
EB> the enhydra libraries.  Of course, it would still be for enhydra
EB> recompilation.  Richard is working on a generic reloading feature which
EB> should be out in the next release if it isn't already in CVS.
        
EB>         Sounds like your effort will bear fruits for you.  Just sounds
EB> like a lot of trouble to go to.  Hopefully we'll have a release with
EB> Xerces-2.x.x support sometime soon!
        
        

EB>                 Enrico.
                
                
                
                
                
                




-- 
Best regards,
 Jacob                            mailto:hoju@xxxxxxxx