[jboss-jira] [JBoss JIRA] (WFLY-12476) Improve user experience of global directory

Improve user experience of global directory ------------------------------------------- Key: WFLY-12476 URL: https://issues.jboss.org/browse/WFLY-12476 Project: WildFly Issue Type: Feature Request Components: Class Loading Reporter: Tomas Terem Assignee: Yeray Borges Priority: Minor 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.