]
Tomas Terem reassigned WFLY-12476:
----------------------------------
Assignee: Yeray Borges (was: Richard Opalka)
Improve user experience of global directory
-------------------------------------------
Key: WFLY-12476
URL:
https://issues.jboss.org/browse/WFLY-12476
Project: WildFly
Issue Type: Task
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:
If some class throws an exception, is user informed which jar contains this class?
Currently, no. This could be implemented.
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.
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.
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}])
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.
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.