[JBoss JIRA] (DROOLS-5252) [DMN Designer] Copy of a imported node shouldn't have a prefix
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5252?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5252:
--------------------------------
Description:
This issue is related to two features of DMN editor.
- Copy and paste diagram node
- Nodes of imported model
If user imported another DMN model into his DMN model, he can use imported nodes in his diagram. They can be easily distinguished by prefix of the imported model. The issue is if we copy and paste such imported node. Created copy shouldn't have the prefix of the original node.
was:In the attached video is shown an different behavior of original and coped BKM node with PMML invocation inside. I attached also the project to easy follow steps from video.
> [DMN Designer] Copy of a imported node shouldn't have a prefix
> --------------------------------------------------------------
>
> Key: DROOLS-5252
> URL: https://issues.redhat.com/browse/DROOLS-5252
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.37.0.Final
> Reporter: Jozef Marko
> Assignee: Valentino Pellegrino
> Priority: Minor
> Labels: drools-tools
> Attachments: imported-node-copy.webm
>
>
> This issue is related to two features of DMN editor.
> - Copy and paste diagram node
> - Nodes of imported model
> If user imported another DMN model into his DMN model, he can use imported nodes in his diagram. They can be easily distinguished by prefix of the imported model. The issue is if we copy and paste such imported node. Created copy shouldn't have the prefix of the original node.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5252) [DMN Designer] Copy of a imported node shouldn't have a prefix
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5252?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5252:
--------------------------------
Attachment: imported-node-copy.webm
> [DMN Designer] Copy of a imported node shouldn't have a prefix
> --------------------------------------------------------------
>
> Key: DROOLS-5252
> URL: https://issues.redhat.com/browse/DROOLS-5252
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.37.0.Final
> Reporter: Jozef Marko
> Assignee: Valentino Pellegrino
> Priority: Minor
> Labels: drools-tools
> Attachments: imported-node-copy.webm
>
>
> This issue is related to two features of DMN editor.
> - Copy and paste diagram node
> - Nodes of imported model
> If user imported another DMN model into his DMN model, he can use imported nodes in his diagram. They can be easily distinguished by prefix of the imported model. The issue is if we copy and paste such imported node. Created copy shouldn't have the prefix of the original node.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5252) [DMN Designer] Copy of a imported node shouldn't have a prefix
by Jozef Marko (Jira)
Jozef Marko created DROOLS-5252:
-----------------------------------
Summary: [DMN Designer] Copy of a imported node shouldn't have a prefix
Key: DROOLS-5252
URL: https://issues.redhat.com/browse/DROOLS-5252
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.37.0.Final
Reporter: Jozef Marko
Assignee: Valentino Pellegrino
In the attached video is shown an different behavior of original and coped BKM node with PMML invocation inside. I attached also the project to easy follow steps from video.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13314) Metrics smallrye contains duplicated help lines
by Parul Sharma (Jira)
[ https://issues.redhat.com/browse/WFLY-13314?page=com.atlassian.jira.plugi... ]
Parul Sharma commented on WFLY-13314:
-------------------------------------
Hi [~jmesnil] are you working on this issue?
Thanks,
Parul Sharma
> Metrics smallrye contains duplicated help lines
> -----------------------------------------------
>
> Key: WFLY-13314
> URL: https://issues.redhat.com/browse/WFLY-13314
> Project: WildFly
> Issue Type: Bug
> Components: MP Metrics
> Affects Versions: 18.0.1.Final
> Reporter: Matthias Depuydt
> Assignee: Jeff Mesnil
> Priority: Critical
>
> The metrics endpoint on which the wildfly microprofile-metrics-smallrye:2.0 subsystem exposes all metrics can't be scraped with prometheus.
> Both the base_gc_time_total & base_gc_total metrics have their help line duplicated which causes prometheus to throw the following error:
> Could not build time series for component wildfly: text format parsing error in line 34: second HELP line for metric name "base_gc_total"
> I have confirmed this is the case for wildfly 18.0.1
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13392) WFSM000001: Permission check failed ... FilePermission when Security Manager enabled and Web App tries to forward to jsp
by Lin Gao (Jira)
[ https://issues.redhat.com/browse/WFLY-13392?page=com.atlassian.jira.plugi... ]
Lin Gao moved JBEAP-19279 to WFLY-13392:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13392 (was: JBEAP-19279)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (Undertow)
(was: Web (Undertow))
Affects Version/s: (was: 7.2.8.GA)
Fix Version/s: (was: 7.3.2.GA)
> WFSM000001: Permission check failed ... FilePermission when Security Manager enabled and Web App tries to forward to jsp
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13392
> URL: https://issues.redhat.com/browse/WFLY-13392
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Major
> Labels: downstream_dependency
>
> When the security manager is enabled and a Servlet tries to use the RequestDispatcher to forward to a jsp, it fails silently even when the security manager permission for the VFS directory is granted.
> It looks like it may be running under the wrong security context when the security manager is invoked.
> {code}
> 2020-04-16 14:46:55,390 DEBUG [io.undertow.request] (default task-1) Invalid path forward.jsp: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/home/jboss/jboss-eap-7.2/standalone/tmp" "read")" in code source "(vfs:/content/JBEAP-19256.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.JBEAP-19256.war" from Service Module Loader")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:307)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:204)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:372)
> at sun.nio.fs.UnixPath.checkRead(UnixPath.java:795)
> at sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:49)
> at sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
> at java.nio.file.Files.readAttributes(Files.java:1737)
> at java.nio.file.Files.isSymbolicLink(Files.java:2153)
> at io.undertow.server.handlers.resource.PathResourceManager.getSymlinkBase(PathResourceManager.java:309)
> at io.undertow.server.handlers.resource.PathResourceManager.getResource(PathResourceManager.java:218)
> at org.wildfly.extension.undertow.deployment.ServletResourceManager.getResource(ServletResourceManager.java:74)
> at io.undertow.server.handlers.resource.CachingResourceManager.getResource(CachingResourceManager.java:114)
> at io.undertow.server.handlers.resource.CachingResourceManager.getResource(CachingResourceManager.java:32)
> at io.undertow.servlet.handlers.ServletPathMatches.getServletHandlerByPath(ServletPathMatches.java:96)
> at io.undertow.servlet.spec.RequestDispatcherImpl.<init>(RequestDispatcherImpl.java:74)
> at io.undertow.servlet.spec.ServletContextImpl.getRequestDispatcher(ServletContextImpl.java:334)
> at com.redhat.examples.servlet.Servlet.doPost(Servlet.java:51)
> at com.redhat.examples.servlet.Servlet.doGet(Servlet.java:40)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:105)
> at java.security.AccessController.doPrivileged(Native Method)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:102)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> 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)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-12779) Incorporate MicroProfile Config in RESTEasy
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFLY-12779?page=com.atlassian.jira.plugi... ]
Ronald Sigal updated WFLY-12779:
--------------------------------
Description:
Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources:
* servlet init-params (ordinal 60)
* filter init-params (ordinal 50)
* servlet context-params (ordinal 40)
In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x.
-In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".- \[Ignore that.\]
was:
Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources:
* servlet init-params (ordinal 60)
* filter init-params (ordinal 50)
* servlet context-params (ordinal 40)
In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x.
In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".
> Incorporate MicroProfile Config in RESTEasy
> -------------------------------------------
>
> Key: WFLY-12779
> URL: https://issues.redhat.com/browse/WFLY-12779
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Ronald Sigal
> Assignee: Ronald Sigal
> Priority: Major
>
> Currently, RESTEasy 3.x (targeted to Wildfly) uses servlet context-params to obtain configuration information. In RESTEasy 4.x, we have updated configuration to access all standard MicroProfile Config sources. Also, we have added three additional ConfigSources:
> * servlet init-params (ordinal 60)
> * filter init-params (ordinal 50)
> * servlet context-params (ordinal 40)
> In this feature request, we propose to port the relevant changes from RESTEasy 4.x to RESTEasy 3.x.
> -In RESTEasy 4.x, all parameters, both RESTEasy parameters and application parameters, are available from all ConfigSources to both RESTEasy and application code. In RESTEasy 3.x, we propose to add a RESTEasy parameter, "resteasy.config.resteasy.parameters.only", which, when set to "true", will limit the three RESTEasy ConfigSources to returning RESTEasy parameters only. It will default to "true".- \[Ignore that.\]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13391) getContextClassLoader is null in Managed thread factory
by Dheeraj Joshi (Jira)
[ https://issues.redhat.com/browse/WFLY-13391?page=com.atlassian.jira.plugi... ]
Dheeraj Joshi updated WFLY-13391:
---------------------------------
Description:
We are using managed-thread-factory and Threads belong to this do not have context class loader associated with it
{code:java}
<managed-thread-factories>
<managed-thread-factory name="FlowWorkManagerThreadFactory" jndi-name="java:jboss/ee/concurrency/factory/FlowWorkManagerThreadFactory" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service
name="InteractiveWorkflowWorkManagerExecutorService"
jndi-name="java:jboss/ee/concurrency/executor/FLOW_MANAGEDEXECUTOR"
core-threads="${threadpool.interactiveWorkflow.minthread}"
max-threads="${threadpool.interactiveWorkflow.maxthread}" keepalive-time="5000"
queue-length="${threadpool.interactiveWorkflow.queuesize}"
thread-factory="FlowWorkManagerThreadFactory"
hung-task-threshold="600000" />
</managed-executor-services>
{code}
classLoader variable in below code
{code:java}
final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
{code}
evaluates as null when called inside managed thread.
Same code works fine with {{Wildfly 16}} and {{Wildfly 17.0.1}}
In 16 and 17.0.1 The class loader is from Service module loader.
Server logs with {{org.jboss.as.ee}} in {{TRACE}} level for {{Wildfly 16, 17.0.1 and 18}} are attached.
was:
We are using managed-thread-factory and Threads belong to this do not have context class loader associated with it
{code:java}
<managed-thread-factories>
<managed-thread-factory name="FlowWorkManagerThreadFactory" jndi-name="java:jboss/ee/concurrency/factory/FlowWorkManagerThreadFactory" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service
name="InteractiveWorkflowWorkManagerExecutorService"
jndi-name="java:jboss/ee/concurrency/executor/FLOW_MANAGEDEXECUTOR"
core-threads="${threadpool.interactiveWorkflow.minthread}"
max-threads="${threadpool.interactiveWorkflow.maxthread}" keepalive-time="5000"
queue-length="${threadpool.interactiveWorkflow.queuesize}"
thread-factory="FlowWorkManagerThreadFactory"
hung-task-threshold="600000" />
</managed-executor-services>
{code}
classLoade variable in below code
{code:java}
final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
{code}
evaluates as null when called inside managed thread.
Same code works fine with {{Wildfly 16}} and {{Wildfly 17.0.1}}
In 16 and 17.0.1 The class loader is from Service module loader.
Server logs with {{org.jboss.as.ee}} in {{TRACE}} level for {{Wildfly 16, 17.0.1 and 18}} are attached.
> getContextClassLoader is null in Managed thread factory
> -------------------------------------------------------
>
> Key: WFLY-13391
> URL: https://issues.redhat.com/browse/WFLY-13391
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Dheeraj Joshi
> Assignee: Eduardo Martins
> Priority: Major
> Attachments: WildFly-16-server.log, WildFly-17-server.log, WildFly-18-server.log
>
>
> We are using managed-thread-factory and Threads belong to this do not have context class loader associated with it
> {code:java}
> <managed-thread-factories>
> <managed-thread-factory name="FlowWorkManagerThreadFactory" jndi-name="java:jboss/ee/concurrency/factory/FlowWorkManagerThreadFactory" context-service="default"/>
> </managed-thread-factories>
> <managed-executor-services>
> <managed-executor-service
> name="InteractiveWorkflowWorkManagerExecutorService"
> jndi-name="java:jboss/ee/concurrency/executor/FLOW_MANAGEDEXECUTOR"
> core-threads="${threadpool.interactiveWorkflow.minthread}"
> max-threads="${threadpool.interactiveWorkflow.maxthread}" keepalive-time="5000"
> queue-length="${threadpool.interactiveWorkflow.queuesize}"
> thread-factory="FlowWorkManagerThreadFactory"
> hung-task-threshold="600000" />
> </managed-executor-services>
> {code}
> classLoader variable in below code
> {code:java}
> final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
> {code}
> evaluates as null when called inside managed thread.
> Same code works fine with {{Wildfly 16}} and {{Wildfly 17.0.1}}
> In 16 and 17.0.1 The class loader is from Service module loader.
> Server logs with {{org.jboss.as.ee}} in {{TRACE}} level for {{Wildfly 16, 17.0.1 and 18}} are attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13391) getContextClassLoader is null in Managed thread factory
by Dheeraj Joshi (Jira)
[ https://issues.redhat.com/browse/WFLY-13391?page=com.atlassian.jira.plugi... ]
Dheeraj Joshi updated WFLY-13391:
---------------------------------
Workaround Description:
In our code where we are getting class loader, Rather than using context class loader we are trying to get the current objects class loader and setting it to current threads class loader and in finally block resetting the class loader to original value.
{code:java}
try {
final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
}
clazz = Class.forName(className, true, classLoader);
} catch (final Exception e) {
throw new JbpmClassNotFoundException("couldn't load class " + className, e);
} finally {
Thread.currentThread().setContextClassLoader(classLoader);
}
{code}
We don't know the consequence of this work around to our application.
was:
In our code where we are getting class loader, Rather than using context class loader we are trying to get the current objects class loader and setting it to current threads class loader and in finally block resetting the class loader to original value.
{code:java}
try {
final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
if (classLoader == null) {
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader());
}
clazz = Class.forName(className, true, classLoader);
} catch (final Exception e) {
throw new JbpmClassNotFoundException("couldn't load class " + className, e);
} finally {
Thread.currentThread().setContextClassLoader(classLoader);
}
{code}
We don't know the consequence of this work around to our application.
> getContextClassLoader is null in Managed thread factory
> -------------------------------------------------------
>
> Key: WFLY-13391
> URL: https://issues.redhat.com/browse/WFLY-13391
> Project: WildFly
> Issue Type: Bug
> Components: Concurrency Utilities
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Dheeraj Joshi
> Assignee: Eduardo Martins
> Priority: Major
> Attachments: WildFly-16-server.log, WildFly-17-server.log, WildFly-18-server.log
>
>
> We are using managed-thread-factory and Threads belong to this do not have context class loader associated with it
> {code:java}
> <managed-thread-factories>
> <managed-thread-factory name="FlowWorkManagerThreadFactory" jndi-name="java:jboss/ee/concurrency/factory/FlowWorkManagerThreadFactory" context-service="default"/>
> </managed-thread-factories>
> <managed-executor-services>
> <managed-executor-service
> name="InteractiveWorkflowWorkManagerExecutorService"
> jndi-name="java:jboss/ee/concurrency/executor/FLOW_MANAGEDEXECUTOR"
> core-threads="${threadpool.interactiveWorkflow.minthread}"
> max-threads="${threadpool.interactiveWorkflow.maxthread}" keepalive-time="5000"
> queue-length="${threadpool.interactiveWorkflow.queuesize}"
> thread-factory="FlowWorkManagerThreadFactory"
> hung-task-threshold="600000" />
> </managed-executor-services>
> {code}
> classLoader variable in below code
> {code:java}
> final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
> {code}
> evaluates as null when called inside managed thread.
> Same code works fine with {{Wildfly 16}} and {{Wildfly 17.0.1}}
> In 16 and 17.0.1 The class loader is from Service module loader.
> Server logs with {{org.jboss.as.ee}} in {{TRACE}} level for {{Wildfly 16, 17.0.1 and 18}} are attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13391) getContextClassLoader is null in Managed thread factory
by Dheeraj Joshi (Jira)
Dheeraj Joshi created WFLY-13391:
------------------------------------
Summary: getContextClassLoader is null in Managed thread factory
Key: WFLY-13391
URL: https://issues.redhat.com/browse/WFLY-13391
Project: WildFly
Issue Type: Bug
Components: Concurrency Utilities
Affects Versions: 19.0.0.Final, 18.0.1.Final
Reporter: Dheeraj Joshi
Assignee: Eduardo Martins
Attachments: WildFly-16-server.log, WildFly-17-server.log, WildFly-18-server.log
We are using managed-thread-factory and Threads belong to this do not have context class loader associated with it
{code:java}
<managed-thread-factories>
<managed-thread-factory name="FlowWorkManagerThreadFactory" jndi-name="java:jboss/ee/concurrency/factory/FlowWorkManagerThreadFactory" context-service="default"/>
</managed-thread-factories>
<managed-executor-services>
<managed-executor-service
name="InteractiveWorkflowWorkManagerExecutorService"
jndi-name="java:jboss/ee/concurrency/executor/FLOW_MANAGEDEXECUTOR"
core-threads="${threadpool.interactiveWorkflow.minthread}"
max-threads="${threadpool.interactiveWorkflow.maxthread}" keepalive-time="5000"
queue-length="${threadpool.interactiveWorkflow.queuesize}"
thread-factory="FlowWorkManagerThreadFactory"
hung-task-threshold="600000" />
</managed-executor-services>
{code}
classLoade variable in below code
{code:java}
final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
{code}
evaluates as null when called inside managed thread.
Same code works fine with {{Wildfly 16}} and {{Wildfly 17.0.1}}
In 16 and 17.0.1 The class loader is from Service module loader.
Server logs with {{org.jboss.as.ee}} in {{TRACE}} level for {{Wildfly 16, 17.0.1 and 18}} are attached.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months