[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana commented on WFLY-11442:
---------------------------------------------
Yes, your right. it is a bit tricky and with some subtleties. I should have discussed the methodology with Ranabir before moving on with this issue and advise about this. We didn't talked about it.
The process I follow is a bit complex, though. I use [https://docs.oracle.com/javase/9/tools/jdeps.htm|jdeps] to find out code dependencies together with a custom Java application that gives me a report based on module names, it is an orientative report, still manual process is needed to verify the uses. I'm not sure if it makes sense to make it available and count on it to find out dependencies, if so, I have to work on it to make it a bit more useful.
The resources root of the affected JBoss module must be reviewed to find out any class loading by using a String or other mechanism, service loader patterns should be also reviewed. In general they should have been covered by the previous step, because a class loading would require at minimum an interface, and if that interface exists, it will be found by jdeps. The implementations could be in a different module. Even though, I think we have to look for those patterns. A general knowledge of the module is also necessary, the component lead should know these details, but sometimes they are so hide that the removal is difficult to perform, even more when the component is big. This step usually is done at PR review.
Having say that, if we are not 100% sure the dependency is no longer used or we do not have a strong reason to remove it with a benefit, the best option is to not remove it.
> Remove unused dependencies from org.jboss.as.ejb3
> -------------------------------------------------
>
> Key: WFLY-11442
> URL: https://issues.redhat.com/browse/WFLY-11442
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Yeray Borges Santana
> Assignee: Ranabir Chakraborty
> Priority: Major
>
> Initial analisys checking only first level dependencies from the resource exposed by {{org.jboss.as.ejb3}} shows that these dependencies are being unused:
> * org.jboss.jts
> * org.wildfly.security.elytron-web.undertow-server
> * org.jboss.as.weld
> * org.wildfly.clustering.marshalling.spi
> * org.wildfly.clustering.marshalling.api
> * org.wildfly.client.config
> * org.hibernate
> The task here is verify that they are not used by any other machanism besides of being a first level dependency.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-4900) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4900?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-13320 to WFCORE-4900:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-4900 (was: WFLY-13320)
Component/s: Security
(was: Security)
Affects Version/s: (was: 19.0.0.Final)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFCORE-4900
> URL: https://issues.redhat.com/browse/WFCORE-4900
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-4900) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4900?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-4900:
------------------------------------------
[~tterem] What is the purpose of this Jira issue? From the comments the component upgrade has already been applied to WildFly Core so the upstream work is complete.
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFCORE-4900
> URL: https://issues.redhat.com/browse/WFCORE-4900
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13320:
------------------------------------
Component/s: Security
(was: Web (Undertow))
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Flavia Rainone
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13320) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13320?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFLY-13320:
---------------------------------------
Assignee: Farah Juma (was: Flavia Rainone)
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFLY-13320
> URL: https://issues.redhat.com/browse/WFLY-13320
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> Priority: Critical
> Labels: regression
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-5180) Kie-scanner update container API doesn't refresh container with latest jar after new year
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5180?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5180.
---------------------------------
Resolution: Cannot Reproduce
I tried to reproduce this issue in all possible ways (playing with the system clock) but couldn't.
> Kie-scanner update container API doesn't refresh container with latest jar after new year
> -----------------------------------------------------------------------------------------
>
> Key: DROOLS-5180
> URL: https://issues.redhat.com/browse/DROOLS-5180
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.18.0.Final
> Reporter: Minal Bhalodi
> Assignee: Mario Fusco
> Priority: Critical
>
> We are using kie-server as a stand alone application. we use kie scanner to update kie container when there is a new DRL file in our .m2 folder.
> we don't have scanner polling but we use Scanner update container API to update kie container.
> Every year when date changes after new year, we are facing issue where kie scanner is not able to update container with latest jar in m2 with new year date.
> When we check the container version it shows latest with new year date but internally kie is still using old jar.
> We fixed this issue with create container API instead update container.
> kie-server-spring-boot-starter-drools :7.18.0.Final
> Please let me know if this issue is already fixed or discussed before or if you need more details.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation instead of modifying the system module
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-13322:
-----------------------------------
Summary: Ability to configure JSF Implementation instead of modifying the system module
Key: WFLY-13322
URL: https://issues.redhat.com/browse/WFLY-13322
Project: WildFly
Issue Type: Enhancement
Components: JSF
Reporter: Brad Maxwell
Assignee: Farah Juma
Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months