To prevent spam users, you can only post on this forum after registration, which is by invitation. If you want to post on the forum, please send me a mail (h DOT m DOT w DOT verbeek AT tue DOT nl) and I'll send you an invitation in return for an account.

Exception for jdk.internal.loader.ClassLoaders$AppClassLoader with "ProM with UItopia (workshop)"

I have been following the instructions of

  1) https://svn.win.tue.nl/trac/prom/wiki/setup/HowToBecomeAProMDeveloper
  2) https://svn.win.tue.nl/trac/prom/wiki/setup/CheckingOutPromUsingSubclipse
  3) https://svn.win.tue.nl/trac/prom/wiki/setup/RunningProM

In the third URL, when I attempt to run "ProM with UITopia" I receive an exception as follows:

------------------------
Exception in thread "main" java.lang.ClassCastException: class jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader and java.net.URLClassLoader are in module java.base of loader 'bootstrap')
    at org.processmining.framework.boot.Boot.boot(Boot.java:369)
    at org.processmining.contexts.uitopia.UI.main(UI.java:153)
------------------------

I am running Java version 12.0.2, and a web search suggests that the exception would occur with any Java version after 9.xx.

Does anyone have a fix for this issue that will enable the ProM UITopia code to work with Java 12.xx ?

Thanks
Rick Hull


Answers

  • Hi Rick,

    Yes, please add the following snippet:
    -Djava.system.class.loader=org.processmining.framework.util.ProMClassLoader
    to the VM arguments of ProM.

    As from Java 9, the default class loader is not a URLClassLoader anymore. ProM uses the URLClassLoader to be able to change the classpath 'on-the-fly', which is required when loading the packages. The ProMClassLoader extends the URLClassLoader and should be used as default class loader when using Java 9 or newer.

    Kind regards,
    Eric.

  • Hi - thank you for that comment.  This has enabled me to get the system installed in my local Eclipse, and to launch the UITopia from there.  Excellent.

    However, when I attempt to load a sample .xes file I get another exception, shown below.  I am using a file that uploads successfully into UITopia when I use a copy of the ProM code that I downloaded directly from the "ProM 6.9 with 64-bit JRE8 and bundle app" selection under "MAC" at http://www.promtools.org/doku.php.  I have a description of the file contents below (it is a minor variant of the repairExample.xes from the ProM tutorial).

    Is there a known fix for this issue?  If not, do you have any suggestions?  Many thanks
    Rick

    =====================
    The exception I am getting

    error messages from UITopia itself:

    "Error with import of [Ljava.io.File;@732e37d8 java.lang.reflect.invocationTargetException

    and

    "Exception happened: java.lang.reflect.InvocationTargetException"

    -------------
    the exception from Eclipse:

    --------------------------------------------------------------
    Start plug-in Open XES Log File (Naive)
    -------- The following exception was logged by the framework:
             The exception was probalby handled properly.
    java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at java.desktop/javax.swing.SwingWorker.get(SwingWorker.java:613)
        at org.processmining.framework.plugin.ProMFuture.get(ProMFuture.java:119)
        at org.processmining.framework.plugin.impl.PluginExecutionResultImpl.synchronize(PluginExecutionResultImpl.java:106)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager.importResourceNotInEDT(ProMResourceManager.java:585)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager.access$200(ProMResourceManager.java:58)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager$10.run(ProMResourceManager.java:554)
        at java.base/java.lang.Thread.run(Thread.java:835)
    Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.processmining.framework.plugin.impl.PluginDescriptorImpl.execute(PluginDescriptorImpl.java:331)
        at org.processmining.framework.plugin.impl.AbstractPluginDescriptor$1.doInBackground(AbstractPluginDescriptor.java:154)
        at org.processmining.framework.plugin.ProMFuture$1.doInBackground(ProMFuture.java:56)
        at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        ... 1 more
    Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
        at org.deckfour.xes.util.XsDateTimeConversion.parseXsDateTime(XsDateTimeConversion.java:96)
        at org.deckfour.xes.util.XsDateTimeConversionJava7.parseXsDateTime(XsDateTimeConversionJava7.java:129)
        at org.deckfour.xes.in.XesXmlParser$XesXmlHandler.startElement(XesXmlParser.java:292)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:510)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:183)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1377)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2710)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
        at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
        at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
        at java.xml/javax.xml.parsers.SAXParser.parse(SAXParser.java:197)
        at org.deckfour.xes.in.XesXmlParser.parse(XesXmlParser.java:175)
        at org.processmining.plugins.log.OpenLogFilePlugin.importFromStream(OpenLogFilePlugin.java:69)
        at org.processmining.plugins.log.OpenNaiveLogFilePlugin.importFromStream(OpenNaiveLogFilePlugin.java:17)
        at org.processmining.framework.abstractplugins.AbstractImportPlugin.importFile(AbstractImportPlugin.java:92)
        ... 13 more

    ============================

    The file I am using is a minor variant on the file repairExample.xes from the tutorial at  http://www.promtools.org/doku.php?id=tutorial:introduction#running_example, but I had to make a couple of modifications to get it to execute successfully on the UITopia that I downloaded directly from http://www.promtools.org/doku.php .  Here is the diff between the original repairExample.xes and my edited version.

    rick% diff repairExample.xes repairExample-edit.xes
    8c8
    < <log xes.version="1.0" xes.features="nested-attributes" openxes.version="1.0RC7" xmlns="http://www.xes-standard.org/">
    ---
    > <log xes.version="1.0" xes.features="" openxes.version="1.0RC7" xmlns="http://www.xes-standard.org/">
    23,24c23
    <     <classifier name="Resource" keys="org:resource"/>
    <     <classifier name="Event Name AND Resource" keys="concept:name org:resource"/>
    ---
    >     <classifier name="Event Name AND Resource" keys="concept:name"/>










  • Hi Rick,

    Yes, you're right, I forgot about that: Java 9 and later come without JAXB support. This explains the fact that javax/xml/bind/DatatypeConverter cannot be found, which is the root cause of the problem.

    Please install the JAXB package using the ProM Package Manager. This adds JAXB support to the ProM landscape, and solves this problem.

    Kind regards,
    Eric.



  • Hi - thank you for this guidance.  I have installed JAXB as per your suggestion.  I also restarted by Eclipse just for good measure.

    I still get an exception when I load my file repairExample-edit.xes into the UITopia.  The exception is slightly different than before.  For one thing, with regards to messages directly from UITopia, I get only one, which reads

    "Error with import of [Lvama.io.FIle;@3379abdb: java.lang.reflect.InvocationTargetException".

    (Similar to one of the 2 messages from UITopia previously)

    From Eclipse I get the same exception message, except that there are 4 or 5 additional lines at the bottom that were not there previously.  I am attaching the full exception message. 

    It still seems to be complaining mainly about the DatatypeConverter, but now perhaps a little deeper into things -- in connection with javax.xml.bind.DatatypeConverter rather than javax/xml/bind/DatatypeConverter

    Do you have any suggestions?

    Many thanks
    Rick

    ==================

    Start plug-in Open XES Log File (Naive)
    -------- The following exception was logged by the framework:
             The exception was probalby handled properly.
    java.util.concurrent.ExecutionException: java.lang.reflect.InvocationTargetException
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
        at java.desktop/javax.swing.SwingWorker.get(SwingWorker.java:613)
        at org.processmining.framework.plugin.ProMFuture.get(ProMFuture.java:119)
        at org.processmining.framework.plugin.impl.PluginExecutionResultImpl.synchronize(PluginExecutionResultImpl.java:106)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager.importResourceNotInEDT(ProMResourceManager.java:585)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager.access$200(ProMResourceManager.java:58)
        at org.processmining.contexts.uitopia.hub.ProMResourceManager$10.run(ProMResourceManager.java:554)
        at java.base/java.lang.Thread.run(Thread.java:835)
    Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at org.processmining.framework.plugin.impl.PluginDescriptorImpl.execute(PluginDescriptorImpl.java:331)
        at org.processmining.framework.plugin.impl.AbstractPluginDescriptor$1.doInBackground(AbstractPluginDescriptor.java:154)
        at org.processmining.framework.plugin.ProMFuture$1.doInBackground(ProMFuture.java:56)
        at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        ... 1 more
    Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
        at org.deckfour.xes.util.XsDateTimeConversion.parseXsDateTime(XsDateTimeConversion.java:96)
        at org.deckfour.xes.util.XsDateTimeConversionJava7.parseXsDateTime(XsDateTimeConversionJava7.java:129)
        at org.deckfour.xes.in.XesXmlParser$XesXmlHandler.startElement(XesXmlParser.java:292)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:510)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:183)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1377)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2710)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
        at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:534)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:888)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:824)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:141)
        at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1216)
        at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:635)
        at java.xml/com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl.parse(SAXParserImpl.java:324)
        at java.xml/javax.xml.parsers.SAXParser.parse(SAXParser.java:197)
        at org.deckfour.xes.in.XesXmlParser.parse(XesXmlParser.java:175)
        at org.processmining.plugins.log.OpenLogFilePlugin.importFromStream(OpenLogFilePlugin.java:69)
        at org.processmining.plugins.log.OpenNaiveLogFilePlugin.importFromStream(OpenNaiveLogFilePlugin.java:17)
        at org.processmining.framework.abstractplugins.AbstractImportPlugin.importFile(AbstractImportPlugin.java:92)
        ... 13 more
    Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 33 more
    --------------------------------------------------------------



  • oh - actually, UITopia did give the second error message "Exception happened: java.lang.reflect.InvocationTargetException" afterall - it was hidden behind some other windows.  Thanks

  • Hi Rick,

    Odd. These classes are contained in the jaxb-api-2.4.0-b180830.0359.jar, which is part of the JAXB package (version 6.9.6). So they should really be there.

    Can you send me a transcript of the console when starting ProM? ProM should write al kinds of diagnostic messages in that console, perhaps there is something there that may help. For example, it should show that the abovementioned jar file was added to the classpath.

    Kind regards,
    Eric.

  • Hi - thanks for your continuing help on this.  I have attached a word doc with the console log -- so that you have the red highlights.

    Indeed, it does look like there is some conflict between my setting of  << value = "org.processmining.framework.util.ProMClassLoader" >> and then the use of archived non-system classes. 

    Perhaps a new issue relating to java 12.xx ?

    Thank you so much
    Rick

  • Hi Rick,

    The message on the class loader is a warning only, so it seems. If I understand this correctly, because we're using our own system class loader, some 'archived non-system classes' (that are use to speed up to loading process) cannot be used. As a result, these classes will just have to be loaded in the usual way, which takes a bit more time. However, this should not block anything later on.

    The JAXB libraries are added to the class path, as your document includes the following line (on page 3):
      adding to classpath:
    file:/Users/rick/.ProM/packages/jaxb-6.9.6/lib/jaxb-api-2.4.0-b180830.0359.jar

    As a result, the class loader should be able to find the classes it is seemingly unable to find. I do not really understand... Possible explanations I can think of:

    1. Your local copy of the jaxb-api-*.jar file is corrupted (unlikely, I'd say).
    2. The class that refers to the JAXB class files was loaded by a different class loader still (can this be?).
    I will investigate the issue further next week when I'm back in the office. Given the warning on the class loader, you must be using OpenJDK 12, right? I will check with OpenJDK 12.

    In the mean time, it might just be better to use a slightly older JRE (version 8 would be ideal) for running ProM. As far as I know, you can just create a local copy of this JRE in the ProM folder, and change the shell scrip0ts (or batch files) to start using hits JRE instead of the default one. As a result other apps need not be bothered by the old JRE.

    Kind regards,
    Eric.






  • Hi Rick,

    I guess my suggestion for using a JRE8 would not really help, as you're running ProM from Eclipse. Apologies, I forgot about that. I guess you need a JDK8 for this and make it available in Eclipse...

    Kind regards,
    Eric.
  • Hi Rick,

    For me, installing the JAXB package solves the problem when using Java 12 (either Oracle's or OpenJDK). Before having installed it, I get the same error message as you, after having installed it, the log is imported correctly.

    As a result, unfortunately, I cannot reproduce the problem...

    One thing you can try is to copy the jaxb-api-*.jar file into the lib folder of your ProM project, and add this copy to the build path. This should make sure the classes are there. It's a hack, but If 'it can't go the way it should, then it should go the way it can'.

    Kind regards,
    Eric.



  • Hi Eric - this last "hack" of copying the jaxb-api-*.jar file into my lib folder has done the trick!  Thank you again for all of your help. I really appreciate it.

    (FYI, actually I am now running on JDK 13).

    Thanks again
    Rick
  • Hi Rick,

    Okay, thanks. Good to know that it is now working for you.

    I guess this does support my fear that another class loader is used to load the class. By copying it into the lib folder, it will be part of the class path that is initially provided to the VM. The ProMClassLoader allows this class path to be extended on-the-fly, but these extensions will not be known to other class loaders.

    Kind regards,
    Eric.
Sign In or Register to comment.