[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3
by Ranabir Chakraborty (Jira)
[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ]
Ranabir Chakraborty commented on WFLY-11442:
--------------------------------------------
Hello [~brian.stansberry] [~yersan], In the module.xml you just need to reference your jar file and any dependencies required. If you want the dependencies to be modules on their own then you need to explicitly declare them in your module.xml file.
I did a hit and trial with the listed dependencies. removed one and then build the module and wildlfy project. In this way, I removed the others also.
Then I run the smoke tests, by switching to the `testsuites` directory, fire the command: `mvn clean install -Dts.smoke .
When I saw everything got executed without any error then raised the PR.
> 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] (WFLY-13324) TCCL not set to application classloader when MBean Notification is invoked
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-13324?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi reassigned WFLY-13324:
-----------------------------------------
Assignee: Moulali Shikalwadi (was: Brian Stansberry)
> TCCL not set to application classloader when MBean Notification is invoked
> --------------------------------------------------------------------------
>
> Key: WFLY-13324
> URL: https://issues.redhat.com/browse/WFLY-13324
> Project: WildFly
> Issue Type: Bug
> Reporter: Moulali Shikalwadi
> Assignee: Moulali Shikalwadi
> Priority: Major
> Attachments: remote.jar
>
>
> TCCL not set to application classloader when MBean Notification is invoked
> If an application registers an MBean notification and it receives a notification, the Thread Context ClassLoader is not set to the application, this causes ClassNotFound exceptions on classes that are in the application's classpath.
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory org.wildfly.naming.client.WildFlyInitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at test.Client.getInitialContext(Client.java:66)
> at test.Client.invoke(Client.java:44)
> at test.Client.handleNotification(Client.java:117)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
> at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
> at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:337)
> at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:248)
> at javax.management.MBeanServerDelegate.sendNotification(MBeanServerDelegate.java:209)
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin$ResourceRegistrationNotificationHandler.handleNotification(ModelControllerMBeanServerPlugin.java:431)
> at org.jboss.as.controller.notification.NotificationSupports.fireNotifications(NotificationSupports.java:126)
> at org.jboss.as.controller.notification.NotificationSupports.access$000(NotificationSupports.java:47)
> at org.jboss.as.controller.notification.NotificationSupports$NonBlockingNotificationSupport$1.run(NotificationSupports.java:105)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
> ... 27 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13324) TCCL not set to application classloader when MBean Notification is invoked
by Moulali Shikalwadi (Jira)
[ https://issues.redhat.com/browse/WFLY-13324?page=com.atlassian.jira.plugi... ]
Moulali Shikalwadi updated WFLY-13324:
--------------------------------------
Description:
TCCL not set to application classloader when MBean Notification is invoked
If an application registers an MBean notification and it receives a notification, the Thread Context ClassLoader is not set to the application, this causes ClassNotFound exceptions on classes that are in the application's classpath.
javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory org.wildfly.naming.client.WildFlyInitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]]
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
at javax.naming.InitialContext.init(InitialContext.java:244)
at javax.naming.InitialContext.<init>(InitialContext.java:216)
at test.Client.getInitialContext(Client.java:66)
at test.Client.invoke(Client.java:44)
at test.Client.handleNotification(Client.java:117)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:337)
at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:248)
at javax.management.MBeanServerDelegate.sendNotification(MBeanServerDelegate.java:209)
at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin$ResourceRegistrationNotificationHandler.handleNotification(ModelControllerMBeanServerPlugin.java:431)
at org.jboss.as.controller.notification.NotificationSupports.fireNotifications(NotificationSupports.java:126)
at org.jboss.as.controller.notification.NotificationSupports.access$000(NotificationSupports.java:47)
at org.jboss.as.controller.notification.NotificationSupports$NonBlockingNotificationSupport$1.run(NotificationSupports.java:105)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
... 27 more
was:
TCCL not set to application classloader when MBean Notification is invoked
If an application registers an MBean notification and it receives a notification, the Thread Context ClassLoader is not set to the application, this causes ClassNotFound exceptions on classes that are in the application's classpath.
> TCCL not set to application classloader when MBean Notification is invoked
> --------------------------------------------------------------------------
>
> Key: WFLY-13324
> URL: https://issues.redhat.com/browse/WFLY-13324
> Project: WildFly
> Issue Type: Bug
> Reporter: Moulali Shikalwadi
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: remote.jar
>
>
> TCCL not set to application classloader when MBean Notification is invoked
> If an application registers an MBean notification and it receives a notification, the Thread Context ClassLoader is not set to the application, this causes ClassNotFound exceptions on classes that are in the application's classpath.
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory org.wildfly.naming.client.WildFlyInitialContextFactory from classloader ModuleClassLoader for Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at test.Client.getInitialContext(Client.java:66)
> at test.Client.invoke(Client.java:44)
> at test.Client.handleNotification(Client.java:117)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor$ListenerWrapper.handleNotification(DefaultMBeanServerInterceptor.java:1754)
> at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
> at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
> at javax.management.NotificationBroadcasterSupport$1.execute(NotificationBroadcasterSupport.java:337)
> at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:248)
> at javax.management.MBeanServerDelegate.sendNotification(MBeanServerDelegate.java:209)
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin$ResourceRegistrationNotificationHandler.handleNotification(ModelControllerMBeanServerPlugin.java:431)
> at org.jboss.as.controller.notification.NotificationSupports.fireNotifications(NotificationSupports.java:126)
> at org.jboss.as.controller.notification.NotificationSupports.access$000(NotificationSupports.java:47)
> at org.jboss.as.controller.notification.NotificationSupports$NonBlockingNotificationSupport$1.run(NotificationSupports.java:105)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.naming.client.WildFlyInitialContextFactory from [Module "org.jboss.as.server" version 6.0.21.Final-redhat-00001 from local module loader @dfd3711 (finder: local module finder @42d3bd8b (roots: /tmp/jboss-eap-7.2/modules,/tmp/jboss-eap-7.2/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
> ... 27 more
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13324) TCCL not set to application classloader when MBean Notification is invoked
by Moulali Shikalwadi (Jira)
Moulali Shikalwadi created WFLY-13324:
-----------------------------------------
Summary: TCCL not set to application classloader when MBean Notification is invoked
Key: WFLY-13324
URL: https://issues.redhat.com/browse/WFLY-13324
Project: WildFly
Issue Type: Bug
Reporter: Moulali Shikalwadi
Assignee: Brian Stansberry
Attachments: remote.jar
TCCL not set to application classloader when MBean Notification is invoked
If an application registers an MBean notification and it receives a notification, the Thread Context ClassLoader is not set to the application, this causes ClassNotFound exceptions on classes that are in the application's classpath.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-13297) Weld @Resource injection does not handle expressions in the annotation attributes
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13297?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13297:
------------------------------------
Description:
WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But this isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles some cases, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean.
You get a failure like this:
{code}
Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${the.expression}"
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236)
... 73 more
{code}
The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work.
was:
WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But thus isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean.
You get a failure like this:
{code}
Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${the.expression}"
at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236)
... 73 more
{code}
The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work.
> Weld @Resource injection does not handle expressions in the annotation attributes
> ---------------------------------------------------------------------------------
>
> Key: WFLY-13297
> URL: https://issues.redhat.com/browse/WFLY-13297
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 19.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> WFLY-1995 added support for expression resolution in the values of some attributes of some annotations, including @Resource. But this isn't applied to all handling of @Resource. ResourceInjectionAnnotationParsingProcessor handles some cases, which AFAICT means it's handled for EJBs (and perhaps other EE components) but it isn't handled in a simple CDI bean.
> You get a failure like this:
> {code}
> Caused by: javax.naming.NameNotFoundException: ${the.expression} -- service jboss.naming.context.java."${the.expression}"
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:237)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:236)
> ... 73 more
> {code}
> The PropertyReplacer obtained from the DeploymentUnit that is used by ResourceInjectionAnnotationParsingProcessor is also available to the weld subsystem code that creates WeldResourceInjectionServices so a possible fix is to pass it in and have WeldResourceInjectionServices use it. Manual testing shows that allows an app with such a bean to work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months