Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-12476

Improve user experience of global directory

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Unresolved
    • Major
    • None
    • None
    • Class Loading
    • None

    Description

      Global directory was introduced in https://issues.jboss.org/browse/WFLY-1160. There are few user experience issues that are yet to be solved so I am creating this follow-up jira for them.

      Issues:
      1. If some class throws an exception, is user informed which jar contains this class?
      Currently, no. This could be implemented.

      2. What if global directory contains corrupted jar file? E.g. text file which was renamed to .jar
      Server logs contains information that zip file could not be opened. Cli only prints out that deployment is missing dependencies.
      This could be improved.

      3. What if global directory contains one correct jar and one corrupted jar? Application only needs that correct jar to work.
      Crash during deployment. Cli says that deployment is missing dependencies.
      This could be improved.

      4. Can user specify dependencies for their libraries? For example to use MP or Hibernate API?
      No.
      It would be good if something like this was possible:
      /subsystem=ee/global-directory=my-common-libs:add(path=lib, relative-to=jboss.home.dir, dependencies=[

      {name=org.hibernate.something,export=true,import=false}

      ])

      5. What should happen if jar contains class that has same name and package as some java ee class?
      Tried with custom javax.ws.rs.client.Client:
      org.jboss.resteasy.spi.UnhandledException: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/ws/rs/client/Client"
      This could be improved - at least warning during deployment could be shown.

      6. Global directory has following hierarchy:
      a/a.1.jar
      ---- A.class
      b/a.2.jar
      ---- A.class
      ---- B.class
      Class B uses A's feature that is only available in a.2.jar version of A.class.
      Fail during runtime when class B tries to access new feature of class A.
      Same as above - at least warning during deployment could be shown.

      Attachments

        Issue Links

          Activity

            People

              yborgess1@redhat.com Yeray Borges Santana
              tterem@redhat.com Tomas Terem (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: