Skip to Content
author's profile photo Former Member
0
Former Member

inqmyxml.jar exclusion

Posted on Dec 14, 2004 at 04:54 PM 19 Views

Hello,

for some special reason (maybe every reason in special....) I want to use my own XMLPARSER API. So I want to get rid of the build-in-xmlinqmy.

The inqmy in not in the Sharingreference!

But for some reason it is load anyway. So how can I use my own XML-jar in the lib folder??

Your answer would be highly appreciated.

Walter

Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • Best Answer
    author's profile photo Former Member
    Former Member
    Posted on Dec 14, 2004 at 05:09 PM
    2

    Hello Walter,

    Unless I'm missing something it should be pretty simple. For example, I'm currently working on something needing the Jakarta-RegExp library. All I had to do to use the library was to put it in the dist/PORTAL-INF/lib folder, and reference this .jar in the project build path. The same thing should work for using an XML parser API.

    Add a comment
    10|10000 characters needed characters exceeded

    • Detlev Beutner Former Member
      Dec 23, 2004 at 02:37 PM

      Hi Dagfinn (and Walter),

      I came in here to give some Christmas presents 😊

      OK, Dagfinn's solution seems to be quite well working for Walter's needs. Some points to him!

      So, if we are that deep in technical discussion, I would like to round off this one:

      All this stuff on the one hand is quite technical, on the other hand life gets much more easy if at least one understands the basics. Much more I also don't do. So for example I mixed up system and bootstrap classloader in my last post (sorry!). Nevertheless, I also wasn't aware of the possibility of passing null, which is totally different from passing nothing. Seems to be very, very helpful to keep this in mind, thanks Dagfinn!

      For your question about loading java.lang.String, Dagfinn: <i>This</i> is done by the bootstrap classloader. It may be irritating that in your example

      classLoader.getParent()

      returns <i>null</i>, but the explanation comes here:

      ClassLoader.getParent() APIDoc: "Returns the parent class loader for delegation. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class loader's parent is the bootstrap class loader."

      To cut a long story short, let's come to the Christmas presents 😊

      - http://www.javaworld.com/javaqa/2003-06/01-qa-0606-load_p.html

      - http://www.javaworld.com/javaworld/jw-03-2000/jw-03-classload_p.html

      - http://www.panix.com/~mito/articles/articles/classloader/j-classloader-ltr.pdf

      I hesitated about the last source, because I have heard that there are different mistakes in it, on a glance I just saw one big one: "The new model is a delegation model, which means that if your ClassLoader can't find a class, it asks its parent ClassLoader to do it."

      NO! The opposite is the case, as written in the first: "every classloader (except for the primordial classloader that bootstraps the entire JVM) has a single parent. When asked to load a class, every compliant classloader is expected to delegate loading to its parent first and attempt to define the class only if the parent fails."

      This should be enough stuff for boring winter days...

      Best regards

      Detlev

    Comment on This Answer

Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.