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