[JBoss JIRA] (WFLY-13266) Add wildfly-jndi.properties to load custom jndi properties without changing the global JVM properties
by Brad Maxwell (Jira)
Brad Maxwell created WFLY-13266:
-----------------------------------
Summary: Add wildfly-jndi.properties to load custom jndi properties without changing the global JVM properties
Key: WFLY-13266
URL: https://issues.redhat.com/browse/WFLY-13266
Project: WildFly
Issue Type: Feature Request
Components: Naming
Affects Versions: 19.0.0.Final
Reporter: Brad Maxwell
Assignee: Richard Opalka
Add wildfly-jndi.properties to load custom jndi properties without changing the global JVM properties
org.jboss.naming.remote.client.InitialContextFactory (Remote Naming) would look for jboss-naming-client.properties in the classpath of the client and load these properties into the InitialContext environment properties. This is useful as it isolates the configuration change to the particular classloader that creates the InitialContext. If a jndi.properties is in an application it will change the properties in the whole JVM which should not be done inside of an Application Server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13263) Cannot remove extension jwt-smallrye
by Szymon Klepacz (Jira)
[ https://issues.redhat.com/browse/WFLY-13263?page=com.atlassian.jira.plugi... ]
Szymon Klepacz closed WFLY-13263.
---------------------------------
Resolution: Cannot Reproduce
> Cannot remove extension jwt-smallrye
> ------------------------------------
>
> Key: WFLY-13263
> URL: https://issues.redhat.com/browse/WFLY-13263
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Affects Versions: 19.0.0.Final
> Reporter: Szymon Klepacz
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: Screenshot_22.png
>
>
> Cannot remove extension jwt-smallrye with Jboss-cli.
> Starting WilFly 19 with this extension result sin WARNINGS:
> 09:46:44,129 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0003: Processing weld deployment XXXX.ear
> 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> at java.lang.ClassLoader._jr$defineClass(ClassLoader.java:763)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:42016)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 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 org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:129)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:115)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> 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:1377)
> at java.lang.Thread.run(Thread.java:748)
> 09:46:44,392 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0007: Could not load portable extension class org.wildfly.security.mp.jwt.JWTCDIExtension: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> at java.lang.ClassLoader._jr$defineClass(ClassLoader.java:763)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:42016)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 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 org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:129)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:115)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> 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:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13263) Cannot remove extension jwt-smallrye
by Szymon Klepacz (Jira)
[ https://issues.redhat.com/browse/WFLY-13263?page=com.atlassian.jira.plugi... ]
Szymon Klepacz commented on WFLY-13263:
---------------------------------------
[~dlofthouse] Tested it again in a fresh environment and removing subsystem from Jboss CLI works fine. It didn't work as presented on the screen but I cannot reproduce it. Sorry!
> Cannot remove extension jwt-smallrye
> ------------------------------------
>
> Key: WFLY-13263
> URL: https://issues.redhat.com/browse/WFLY-13263
> Project: WildFly
> Issue Type: Bug
> Components: MP JWT
> Affects Versions: 19.0.0.Final
> Reporter: Szymon Klepacz
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: Screenshot_22.png
>
>
> Cannot remove extension jwt-smallrye with Jboss-cli.
> Starting WilFly 19 with this extension result sin WARNINGS:
> 09:46:44,129 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0003: Processing weld deployment XXXX.ear
> 09:46:44,391 WARN [org.jboss.modules.define] (MSC service thread 1-1) Failed to define class org.wildfly.security.mp.jwt.JWTCDIExtension in Module "deployment.XXXX.ear" from Service Module Loader: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> at java.lang.ClassLoader._jr$defineClass(ClassLoader.java:763)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:42016)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 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 org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:129)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:115)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> 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:1377)
> at java.lang.Thread.run(Thread.java:748)
> 09:46:44,392 WARN [org.jboss.weld.deployer] (MSC service thread 1-1) WFLYWELD0007: Could not load portable extension class org.wildfly.security.mp.jwt.JWTCDIExtension: java.lang.NoClassDefFoundError: Failed to link org/wildfly/security/mp/jwt/JWTCDIExtension (Module "deployment.XXX.ear" from Service Module Loader): io/smallrye/jwt/auth/cdi/SmallRyeJWTAuthCDIExtension
> at java.lang.ClassLoader.defineClass1(ClassLoader.java)
> at java.lang.ClassLoader._jr$defineClass(ClassLoader.java:763)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:42016)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:839)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:424)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
> at org.jboss.modules.Module.loadModuleClass(Module.java:731)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
> 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 org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:129)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:115)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:79)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558)
> 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:1377)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ]
Boris Unckel edited comment on WFCORE-482 at 3/21/20 5:42 AM:
--------------------------------------------------------------
Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!).
The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change.
We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency.
I understand that people want to utilize log4j2-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes] add-logging-api-dependencies and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies.
was (Author: xf01213):
Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!).
The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change.
We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency.
I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes] add-logging-api-dependencies and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.redhat.com/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ]
Boris Unckel commented on WFCORE-482:
-------------------------------------
Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!).
The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change.
We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency.
I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes|add-loggin...] and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.redhat.com/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by Boris Unckel (Jira)
[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ]
Boris Unckel edited comment on WFCORE-482 at 3/21/20 5:34 AM:
--------------------------------------------------------------
Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!).
The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change.
We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency.
I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes] add-logging-api-dependencies and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies.
was (Author: xf01213):
Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!).
The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change.
We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency.
I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes|add-loggin...] and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies.
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.redhat.com/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Major
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-10261) @Startup, @WebListener and (@Observes @Initialized(ApplicationScoped.class) are triggered before some components has started
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-10261?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFLY-10261.
-------------------------------------
Resolution: Out of Date
[~dbdbdb] If this is still an issue with WildFly 19, please re-open.
> @Startup, @WebListener and (@Observes @Initialized(ApplicationScoped.class) are triggered before some components has started
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10261
> URL: https://issues.redhat.com/browse/WFLY-10261
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 12.0.0.Final
> Reporter: Daniel Fb
> Assignee: Brian Stansberry
> Priority: Major
>
> We are migrating our applications from Wildfly 10 to Wildfly 12 and sometimes Wildfly 12 trigger {{@Startup (with @PostContruct)}} or {{@WebListener}} or {{(@Observes @Initialized(ApplicationScoped.class)}} before some components has started.
> Ex:
> - At these moments we can't inject remote EJBs (simple {{new InitialContext().lookup(jndi)}})
> - Sometimes these {{@Observes}} is fired with null parameter
> {code}
> public void observesContext(@Observes @Initialized(ApplicationScoped.class) ServletContext context){
> this.context = context;
> }
> {code}
> *These behavior olny occurs when the server is starting with the application deployed*.
> When the application is deployed after the server is up and running, all goes fine a work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13264) [19.0.x] Messages are being added to topic even if there are no subscribers
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13264?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13264:
------------------------------------
Fix Version/s: (was: 20.0.0.Beta1)
> [19.0.x] Messages are being added to topic even if there are no subscribers
> ----------------------------------------------------------------------------
>
> Key: WFLY-13264
> URL: https://issues.redhat.com/browse/WFLY-13264
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 19.0.0.Final
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Fix For: 19.0.1.Final
>
>
> After applying EAP 7.2 Update 7 , messages seem to be added to a topic even when there are no subscribers on the topic.
> When subscribers are attached to a topic they seem to consume messages from a topic but the messages is not removed from the underlying physical queue resulting in the destination growing indefinitely in size.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month