jdic
  1. jdic
  2. JDIC-342

JdicManager throws exception if not loaded with URLClassLoader

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      342

      Description

      org.jdesktop.jdic.init.JdicManager.initShareNative() casts the class loader for
      the class to a URLClassLoader, and throws a JdicInitException if it was not
      loaded with a URLClassLoader. Our application has a custom class loader that is
      not a URLClassLoader, and loads its classes through a different mechanism.
      Throwing an exception in that case may not be the right thing to do. In
      addition, the code to add the binary path to the java.library.path is also
      skipped, even though it may be necessary. I suggest putting the cast inside the
      inner try/catch block where it is actually referenced as a URLClassLoader. I
      also suggest considering some kind of hook for class loaders that do not derive
      from URLClassLoader.

        Activity

        Hide
        michael_shan added a comment -

        Hi,
        With the build of 20060308, this issue should be fixed. Please have a try.

        Show
        michael_shan added a comment - Hi, With the build of 20060308, this issue should be fixed. Please have a try.
        Hide
        michael_shan added a comment -

        Background:

        JDIC's cross platform version, it tends to choice platform related
        jdic_stub.jar automatically.Thus users can only import jdic.jar without caring
        about different os. But the auto adding/loading of jdic_stub.jar is some
        difficult to realize.

        Analysis of this cr:
        In our former code, we supposed that the classloader of JDIC should be instance
        of URLClassLoader, but this has been failed when deploying JDIC as a plugin of
        NetBeans, which doesn't extend URLClassLoader.

        The latest fix of dynamically setting java.class.path property will not
        work,since after JVM starting, it will not care the change of this property.

        Current way to fix:

        • If classes are loaded by instance of URLClassLoader, use before way of using
          method "addURL" to change loading path dynamically and this will work well
        • For classes are not loaded by instance of URLClassLoader, user have to add
          jdic_stub.jar to classpath manually

        Final way to fix:
        1. Remove JDIC cross platform verion.Since if user have to jdic_stub.jar to
        classpath manully, it's not necessary to provide this version anymore.
        2. Develop JDIC ClassLoader to load classes in jdic_stub.jar.

        I prefer fix 1,since fix 2 will make the architecture of JDIC bad. Fix 1 is
        acceptable, as few softwares will provide a version of all platforms,for e.g .,
        Java.

        Michael

        Show
        michael_shan added a comment - Background: JDIC's cross platform version, it tends to choice platform related jdic_stub.jar automatically.Thus users can only import jdic.jar without caring about different os. But the auto adding/loading of jdic_stub.jar is some difficult to realize. Analysis of this cr: In our former code, we supposed that the classloader of JDIC should be instance of URLClassLoader, but this has been failed when deploying JDIC as a plugin of NetBeans, which doesn't extend URLClassLoader. The latest fix of dynamically setting java.class.path property will not work,since after JVM starting, it will not care the change of this property. Current way to fix: If classes are loaded by instance of URLClassLoader, use before way of using method "addURL" to change loading path dynamically and this will work well For classes are not loaded by instance of URLClassLoader, user have to add jdic_stub.jar to classpath manually Final way to fix: 1. Remove JDIC cross platform verion.Since if user have to jdic_stub.jar to classpath manully, it's not necessary to provide this version anymore. 2. Develop JDIC ClassLoader to load classes in jdic_stub.jar. I prefer fix 1,since fix 2 will make the architecture of JDIC bad. Fix 1 is acceptable, as few softwares will provide a version of all platforms,for e.g ., Java. Michael
        Hide
        michael_shan added a comment -

        Change to browser type.

        Show
        michael_shan added a comment - Change to browser type.
        Hide
        michael_shan added a comment -

        Hi Michael,
        unfortunately I was not able to add a comment to the issue, don’t know why
        (attachment was possible).
        We would love to use jdic within eclipse on different platforms (no
        URLClassLoader),therefore I had another suggestion to solve the platform
        dependency stuff:
        Why don’t you just use a Factory that creates the ServiceManagerStub dependent
        on the operating system?
        The following steps would be necessary:
        1)Refactor all internal ServiceManagerStub classes within the os specific
        packages into concrete ones, e.g. WinServiceManagerStub, MacSerrviceManagerStub, …
        2)Add a factory into ServiceManager.getService() that uses the concrete stub (as
        an interface of course). The factory could load the class without concrete
        dependencies by reflection (similar to what you’ve done within
        JdicManager.dealCrossPlatformVersion())
        3)Remove that UrlLoader Code completely

        Seems to be a tiny patch (most work has to be done in 1).
        For a user of the jar, all he has to do is just adding the main jars plus all os
        dependent jars. Only those would be loaded at runtime that are really created by
        the factory.

        Regards
        Darius

        Show
        michael_shan added a comment - Hi Michael, unfortunately I was not able to add a comment to the issue, don’t know why (attachment was possible). We would love to use jdic within eclipse on different platforms (no URLClassLoader),therefore I had another suggestion to solve the platform dependency stuff: Why don’t you just use a Factory that creates the ServiceManagerStub dependent on the operating system? The following steps would be necessary: 1)Refactor all internal ServiceManagerStub classes within the os specific packages into concrete ones, e.g. WinServiceManagerStub, MacSerrviceManagerStub, … 2)Add a factory into ServiceManager.getService() that uses the concrete stub (as an interface of course). The factory could load the class without concrete dependencies by reflection (similar to what you’ve done within JdicManager.dealCrossPlatformVersion()) 3)Remove that UrlLoader Code completely Seems to be a tiny patch (most work has to be done in 1). For a user of the jar, all he has to do is just adding the main jars plus all os dependent jars. Only those would be loaded at runtime that are really created by the factory. Regards Darius
        Hide
        michael_shan added a comment -

        Hi Darius,

        Thank you for your suggestion.I prefer this idea and it's worth to be
        investigated. A future affection of this is that,if it works well I think JDIC
        needs provide only one build,the cross platform version . Would you like put
        your hands dirty on this issue? We really need more contributors' help on JDIC.

        thanks,
        Michael

        Show
        michael_shan added a comment - Hi Darius, Thank you for your suggestion.I prefer this idea and it's worth to be investigated. A future affection of this is that,if it works well I think JDIC needs provide only one build,the cross platform version . Would you like put your hands dirty on this issue? We really need more contributors' help on JDIC. thanks, Michael

          People

          • Assignee:
            michael_shan
            Reporter:
            pjgust
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: