Hi Tom,

Thank you for your comments. I'm agree with what you said but the catching of UnsatisfiedLinkError as it is, is not sufficient. See below.


Apart these technicals problems, I was mostly pointing out two questions:

1) about the loading code of libxmlj in GNU JAXP
2) about the usability of GNU JAXP or to rephrase I'm looking for enabling the use of XML/DOM in classpath with or without libxmlj. The use of libxmlj is absolutely not mandatory for me, but according to question 1), it seems that the code that loads libxmlj breaks the DOMImplementation class loading process. (see below)

Considering that, I am mainly interested in my question 2, as I have don't succeeded in building any shared library of libxmlj.
So:
=> building classpath from sources do not give me any xmlj.dll file needed for my usage (I'm using classpath on a windows mobile environment). If someone have already built the shared library xmlj.dll (or either xmlj.so file), I would kindly appreciate these infos :-)

=> If not, I am wondering if I am the first trying to use XML or XML/DOM in classpath :-) ?


Regards,
Hervé

===========================
More comments about the code that loads the native library.
When executing I got the stacktrace below.
To be concise:

a) IMO, the UnsatisfiedLinkError catch block is not at the right place. It is currently in gnu.xml.dom ImplementationSource class (as Tom said) which is a client class. It should rather be directly in the class that calls System.load() (gnu.xml.libxmlj.util.XMJ) something like

 public static void init ()
  {
    if (!initialised)
      {
        try{//this try shoud be added
        System.loadLibrary ("xmlj");
        }
        catch()//should be here, surrounding directly the system.load
        .....
  }

Consequently, the UnsatisfiedLinkError is thrown at the level of XML class, not at ImplementationSource one, as Tom rightly noticed.

b) Morover, another problem is that, the success/failure of libxmlj loading is not considered. There should be a flag to indicate that either native loading has succeeded or not. Otherwise, there would be some ExceptionInInitializerError (as in the stacktrace), as some others class may rely on libxmlj.

To sum ump, AFAIU, try/catch should surround "System.loadLibrary ("xmlj")" and depending on the success/failure of the loading process, a flag should be updated an used by all others client class, so that they can adapt their behavior with/without xmlj.


==============================
StackTrace follows:

in main client: before web service call
Exception in thread "Thread-1" java.lang.ExceptionInInitializerError
   at org.apache.axis.configuration.FileProvider.configureEngine
(FileProvider.java:179)

   at org.apache.axis.AxisEngine.init (AxisEngine.java:172)
   at org.apache.axis.AxisEngine.<init> (AxisEngine.java:156)
   at org.apache.axis.client.AxisClient.<init> (AxisClient.java:52)
   at org.apache.axis.client.Service.getAxisClient (Service.java:104)
   at org.apache.axis.client.Service.<init> (Service.java:113)
   at
_10._1._168._192.axis1.services.MyServerValidate.MyServerValidateServiceLocator.<init>
(Unknown source)
   at MyClientValidate.sayHello (Unknown source)
   at MyClientValidate.main (Unknown source)
   at java.lang.reflect.Method.invokeNative (Native Method)
   at java.lang.reflect.Method.invoke (Method.java:329)
   at java.lang.VMMainThread$1.run (VMMainThread.java)
   at java.lang.VMThread.run (VMThread.java:120)
Caused by: java.lang.ExceptionInInitializerError
   at java.lang.VMClassLoader.loadClass (Native Method)
   at java.lang.ClassLoader.loadClass (ClassLoader.java:329)
   at java.lang.ClassLoader$1.loadClass (ClassLoader.java:1110)
   at java.lang.ClassLoader.loadClass (ClassLoader.java:294)
   at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance
(DOMImplementationRegistry.java:140)
   at gnu.xml.dom.DomDocumentBuilderFactory.<init>
(DomDocumentBuilderFactory.java:69)
   at java.lang.reflect.Constructor.constructNative (Native Method)
   at java.lang.reflect.Constructor.newInstance (Constructor.java:242)
   at java.lang.Class.newInstance (Class.java:1136)
   at javax.xml.parsers.DocumentBuilderFactory.newInstance
(DocumentBuilderFactory.java:104)
   at org.apache.axis.utils.XMLUtils.getDOMFactory (XMLUtils.java:221)
   at org.apache.axis.utils.XMLUtils.<clinit> (XMLUtils.java)
   at org.apache.axis.utils.XMLUtils.<clinit> (XMLUtils.java)
   at org.apache.axis.configuration.FileProvider.configureEngine
(FileProvider.java:179)
   ...12 more
Caused by: java.lang.ExceptionInInitializerError
   at java.lang.VMClass.forName (Native Method)
   at java.lang.Class.forName (Class.java:161)
   at gnu.xml.dom.ImplementationSource.<clinit> (ImplementationSource.java)
   at gnu.xml.dom.ImplementationSource.<clinit> (ImplementationSource.java)
   at java.lang.VMClassLoader.loadClass (Native Method)
   ...25 more
Caused by: java.lang.UnsatisfiedLinkError: Native library `xmlj' not
found (as file `xmlj') in gnu.classpath.boot.library.path and
java.library.path
   at java.lang.Runtime.loadLibrary (Runtime.java:763)
   at java.lang.System.loadLibrary (System.java:529)
   at gnu.xml.libxmlj.util.XMLJ.init (XMLJ.java:92)
   at gnu.xml.libxmlj.dom.GnomeDocumentBuilder.<clinit>
(GnomeDocumentBuilder.java)
   at gnu.xml.libxmlj.dom.GnomeDocumentBuilder.<clinit>
(GnomeDocumentBuilder.java)
   at java.lang.VMClass.forName (Native Method)
   ...29 more
JVM exit.







Tom Tromey a écrit :
"Herve" == Herve Chang <[EMAIL PROTECTED]> writes:

Herve> So, as I want to use DOM/XML in classpath, I'd like to have your
Herve> comments/feedbacks about:

Herve> - Is the use of libxmlj mandatory? (according to my comments below,
Herve>   seems to be yes)

I don't think it is.  See below.

Herve> AFAIU, The DOM Boostrapping fallback class
Herve> gnu.xml.dom.ImplementationSource loads
Herve> gnu.xml.libxmlj.dom.GnomeDocumentBuilder which contains the
Herve> following static code:

Note the code in ImplementationSource:

    try
      {
        Class t = Class.forName("gnu.xml.libxmlj.dom.GnomeDocumentBuilder");
        acc.add(t.newInstance());
      }
    catch (Exception e)
      {
// libxmlj not available }
    catch (UnsatisfiedLinkError e)
      {
        // libxmlj not available
      }

In particular catching UnsatisfiedLinkError should guarantee that if
libxmlj is not found, then we can still proceed.

This definitely isn't ideal (IMO) but it seems like it ought to work
ok.

Tom

Reply via email to