[jboss-jira] [JBoss JIRA] (WFLY-12476) Improve user experience of global directory
Tomas Terem (Jira)
issues at jboss.org
Tue Sep 3 06:46:02 EDT 2019
[ https://issues.jboss.org/browse/WFLY-12476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tomas Terem updated WFLY-12476:
-------------------------------
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.
was:
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.
> 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:
> 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.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
More information about the jboss-jira
mailing list