You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Adrian Sutton <ad...@ephox.com> on 2004/06/18 03:38:44 UTC
Changing the Xerces package
Hi all,
We've developed an applet that makes heavy use of Xerces, including it's internal APIs, and would like to avoid problems of conflicting Xerces problems, particularly in the JRE, by moving Xerces to another package. We've previously done this with Xalan using a fairly naïve perl script successfully but it's a long drawn out process to work out exactly what needs to be replaced with what etc especially when updating the various properties files and reflection code etc. Ideally we would just change the package from org.apache.xerces to com.ephox.org.apache.xerces.
Has anyone done something like this with Xerces and be able to share wisdom, knowledge or better yet a script that we can use as a starting point?
I want to stress that we don't want to hide the fact we're using Xerces or not give credit to the wonderful Xerces developers, just make sure we get the Xerces we want with confidence. The JRE override mechanism isn't an option for automatically deployed applets unfortunately.
Regards,
Adrian Sutton.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Changing the Xerces package
Posted by Andy Clark <an...@cyberneko.net>.
Adrian Sutton wrote:
> Hi all, We've developed an applet that makes heavy use of Xerces,
> including it's internal APIs, and would like to avoid problems of
Others have already mentioned various refactoring tools so I
won't bother adding my two cents on that topic. However...
I am very interested in which internal APIs you are using in
Xerces. It's rare when we actually hear from people that have
used the internal APIs. So I would like to learn about your
experience. What worked? What didn't? What was useful? What
wasn't? etc.
Any information and insight you can provide would help us
continue providing functionality that not only works but is
what the "customer", like yourself, needs. :)
--
Andy Clark * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Changing the Xerces package
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2004-06-18 at 13:38, Adrian Sutton wrote:
> Hi all,
> We've developed an applet that makes heavy use of Xerces, including it's internal APIs, and would like to avoid problems of conflicting Xerces problems, particularly in the JRE, by moving Xerces to another package. We've previously done this with Xalan using a fairly naïve perl script successfully but it's a long drawn out process to work out exactly what needs to be replaced with what etc especially when updating the various properties files and reflection code etc. Ideally we would just change the package from org.apache.xerces to com.ephox.org.apache.xerces.
>
> Has anyone done something like this with Xerces and be able to share wisdom, knowledge or better yet a script that we can use as a starting point?
>
> I want to stress that we don't want to hide the fact we're using Xerces or not give credit to the wonderful Xerces developers, just make sure we get the Xerces we want with confidence. The JRE override mechanism isn't an option for automatically deployed applets unfortunately.
Well, someone from Sun should be able to give you advice on this. I see
that the Sun JDK for java 1.5 has the xml parser package
"com.sun.org.apache.xerces"...
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Changing the Xerces package
Posted by Dalibor Topic <ro...@kaffe.org>.
Hi George,
George Cristian Bina wrote:
> Hi,
>
>
>>Would it be possible to separate the applet into a delegating
>>classloader component, and the rest of the applet? Then the class loader
>>could take care of loading the xerces classes [1] exclusively for your
>>real applet loaded through it.
>>
>>Just wondering if that would be possible.
>
>
> Yes, something like this is possible, see also:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xerces-j-user@xml.apache
> .org&msgId=1697084
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xerces-j-user@xml.apache
> .org&msgNo=1062
>
> Although we use this for some years now I would like better a change of
> packages solution. I'm not sure that a refactory applied with an IDE
> (Eclipse was proposed earlier here) will solve the problem. There are
> properties and features that are passed around or exist as strings - if one
> wants to change these as well then maybe the rename package refactory option
> will not be enough.
Thanks a lot for your quick and very informative reply! I'm glad to hear
that the approach works in practice.
cheers,
dalibor topic
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Changing the Xerces package
Posted by George Cristian Bina <ge...@sync.ro>.
Hi,
> Would it be possible to separate the applet into a delegating
> classloader component, and the rest of the applet? Then the class loader
> could take care of loading the xerces classes [1] exclusively for your
> real applet loaded through it.
>
> Just wondering if that would be possible.
Yes, something like this is possible, see also:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xerces-j-user@xml.apache
.org&msgId=1697084
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xerces-j-user@xml.apache
.org&msgNo=1062
Although we use this for some years now I would like better a change of
packages solution. I'm not sure that a refactory applied with an IDE
(Eclipse was proposed earlier here) will solve the problem. There are
properties and features that are passed around or exist as strings - if one
wants to change these as well then maybe the rename package refactory option
will not be enough.
Best Regards,
George
-------------------------------------------------------
George Cristian Bina mailto:george@oxygenxml.com
<oXygen/> XML Editor & XSLT Editor/Debugger
http://www.oxygenxml.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: Changing the Xerces package
Posted by Dalibor Topic <ro...@kaffe.org>.
Adrian Sutton wrote:
> Hi all,
> We've developed an applet that makes heavy use of Xerces, including it's internal APIs, and would like to avoid problems of conflicting Xerces problems, particularly in the JRE, by moving Xerces to another package. We've previously done this with Xalan using a fairly naïve perl script successfully but it's a long drawn out process to work out exactly what needs to be replaced with what etc especially when updating the various properties files and reflection code etc. Ideally we would just change the package from org.apache.xerces to com.ephox.org.apache.xerces.
>
> Has anyone done something like this with Xerces and be able to share wisdom, knowledge or better yet a script that we can use as a starting point?
>
> I want to stress that we don't want to hide the fact we're using Xerces or not give credit to the wonderful Xerces developers, just make sure we get the Xerces we want with confidence. The JRE override mechanism isn't an option for automatically deployed applets unfortunately.
Hi Adrian,
this may be a stupid question, since I haven't had to solve a similar
problem myself yet. The question is:
Would it be possible to separate the applet into a delegating
classloader component, and the rest of the applet? Then the class loader
could take care of loading the xerces classes [1] exclusively for your
real applet loaded through it.
Just wondering if that would be possible.
cheers,
dalibor topic
[1] By braking the API requirement to look for the Xerces classes in its
parent class loader.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org