August 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4399) KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException

by Simon Dallaway (Jira)

[ https://issues.jboss.org/browse/DROOLS-4399?page=com.atlassian.jira.plugi... ] Simon Dallaway commented on DROOLS-4399: ---------------------------------------- Hi Maciej, I'm now wondering where I found the documentation for setting up the org.kie.server.persistence.ds etc. properties. Anyway, I have modified my setenv.bat to have -Dorg.kie.server.id=tomcat-kieserver -Dorg.kie.server.location=http://localhost:8081/kie-server/services/rest/server This fails with a null pointer in the JACCValve.wrapListeners method because the request context is null. There's also a warning for periodic recovery being unable to find a suitable JDBC driver and a severe Unable to create EntityManagerFactory as a result of NameNotFoundException: Name [jboss/TransactionManager]. I've attached the Catalina log file for reference. > KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException > ------------------------------------------------------------------------- > > Key: DROOLS-4399 > URL: https://issues.jboss.org/browse/DROOLS-4399 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.24.0.Final > Environment: Windows 8.1 x64 > Tomcat 9.0.16 > Reporter: Simon Dallaway > Assignee: Maciej Swiderski > Priority: Major > Attachments: catalina.2019-08-05.log, catalina.2019-08-06.log, catalina.2019-08-08.log, context.xml, libDir.txt, server.xml, setenv.bat, tomcat-users.xml, xa-recovery-properties.xml > > > Attempting to deploy KIE Server on Tomcat 9 fails with a ClassNotFoundException org.jboss.narayana.tomcat.jta.NarayanaJtaServletContextListener when trying to setup application listener -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4399) KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException

by Simon Dallaway (Jira)

[ https://issues.jboss.org/browse/DROOLS-4399?page=com.atlassian.jira.plugi... ] Simon Dallaway updated DROOLS-4399: ----------------------------------- Attachment: catalina.2019-08-08.log > KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException > ------------------------------------------------------------------------- > > Key: DROOLS-4399 > URL: https://issues.jboss.org/browse/DROOLS-4399 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.24.0.Final > Environment: Windows 8.1 x64 > Tomcat 9.0.16 > Reporter: Simon Dallaway > Assignee: Maciej Swiderski > Priority: Major > Attachments: catalina.2019-08-05.log, catalina.2019-08-06.log, catalina.2019-08-08.log, context.xml, libDir.txt, server.xml, setenv.bat, tomcat-users.xml, xa-recovery-properties.xml > > > Attempting to deploy KIE Server on Tomcat 9 fails with a ClassNotFoundException org.jboss.narayana.tomcat.jta.NarayanaJtaServletContextListener when trying to setup application listener -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12329) ManagedScheduledExecutorService should be only available after server is ready

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-12329?page=com.atlassian.jira.plugin... ] Eduardo Martins edited comment on WFLY-12329 at 8/7/19 5:47 PM: ---------------------------------------------------------------- [~nimo22] can you please attach a project I may use to reproduce the issue at startup? If I can confirm it than will certainly fix it. Wrt your question, those methods come from JDK's ExecutorService, which ManagedExecutorService extends, my guess is that being able to reuse ExecutorService was considered more important than not exposing lifecycle related methods that are forbidden to use... But just my guess, I was not in the spec team! was (Author: emmartins): [~nimo22] can you attach a project I may use to reproduce the issue at startup? Wrt your question, those methods come from JDK's ExecutorService, which ManagedExecutorService extends, my guess is that being able to reuse ExecutorService was considered more important than not exposing lifecycle related methods that are forbidden to use... But just my guess, I was not in the spec team! > ManagedScheduledExecutorService should be only available after server is ready > ------------------------------------------------------------------------------ > > Key: WFLY-12329 > URL: https://issues.jboss.org/browse/WFLY-12329 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 17.0.1.Final > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > I use a *ManagedScheduledExecutorService* to execute tasks periodically: > {code:java} > @Startup > @Singleton > public class TaskScheduler { > @Resource > ManagedScheduledExecutorService executorService; > @PostConstruct > public void init() { > executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS); > } > public void task() { > System.out.println("long running task:" + LocalTime.now()); > } > } > {code} > Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode: > {code:java} > 12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended > at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > {code} > I use _ManagedScheduledExecutorService_ instead of _ScheduledExecutorService_ in JEE because, *ManagedScheduledExecutorService* should be managed by JEE. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12329) ManagedScheduledExecutorService should be only available after server is ready

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-12329?page=com.atlassian.jira.plugin... ] Eduardo Martins commented on WFLY-12329: ---------------------------------------- [~nimo22] can you attach a project I may use to reproduce the issue at startup? Wrt your question, those methods come from JDK's ExecutorService, which ManagedExecutorService extends, my guess is that being able to reuse ExecutorService was considered more important than not exposing lifecycle related methods that are forbidden to use... But just my guess, I was not in the spec team! > ManagedScheduledExecutorService should be only available after server is ready > ------------------------------------------------------------------------------ > > Key: WFLY-12329 > URL: https://issues.jboss.org/browse/WFLY-12329 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 17.0.1.Final > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > I use a *ManagedScheduledExecutorService* to execute tasks periodically: > {code:java} > @Startup > @Singleton > public class TaskScheduler { > @Resource > ManagedScheduledExecutorService executorService; > @PostConstruct > public void init() { > executorService.scheduleAtFixedRate(this::task, 0, 5, TimeUnit.SECONDS); > } > public void task() { > System.out.println("long running task:" + LocalTime.now()); > } > } > {code} > Wildfly throws a few exceptions as long as server is not fully initiated and in "suspend"-mode: > {code:java} > 12:44:12,715 ERROR [org.jboss.as.ee] (EE-ManagedScheduledExecutorService-default-Thread-3) WFLYEE0110: Failed to run scheduled task: java.lang.IllegalStateException: WFLYEE0111: Cannot run scheduled task my.Task$$Lambda$1041/0x000000080240a040@5ee966ec as container is suspended > at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.concurrent.ControlPointUtils$ControlledScheduledRunnable.run(ControlPointUtils.java:164) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.access$201(ManagedScheduledThreadPoolExecutor.java:383) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.internal.ManagedScheduledThreadPoolExecutor$ManagedScheduledFutureTask.run(ManagedScheduledThreadPoolExecutor.java:534) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > {code} > I use _ManagedScheduledExecutorService_ instead of _ScheduledExecutorService_ in JEE because, *ManagedScheduledExecutorService* should be managed by JEE. Hence, the server should also manage and guarantee not to fire the executorService until the server is ready (and EJBs are available). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1819) The logout handler registration should be reworked

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/ELY-1819?page=com.atlassian.jira.plugin.s... ] Ashley Abdel-Sayed commented on ELY-1819: ----------------------------------------- [~dlofthouse] When taking a closer look at implementing this with the logout handler as a {{Consumer<HttpServerScopes>}} and the {{logoutHandlerConsumer}} as a {{Consumer<Consumer<HttpServerScopes>>}}, I can't see how the scope would be passed in as an argument to the logout handler. In {{setupProgramaticLogout}}, when I create the logout handler, as such; {code:java} Consumer<HttpServerScopes> logoutHandler = serverScope -> serverScope.getScope(Scope.SESSION).setAttachment(AUTHENTICATED_IDENTITY_KEY, null); {code} I don't see a way to specify the {{HttpServerScope}} argument without calling {{logoutHandler.accept(HttpServerScope);}} but we would only want to pass in the {{logoutHandler}} with the scope specified to {{logoutHandlerConsumer.accept(Consumer<HttpServerScopes>)}} not execute {{logoutHandler.accept(HttpServerScope);}} > The logout handler registration should be reworked > -------------------------------------------------- > > Key: ELY-1819 > URL: https://issues.jboss.org/browse/ELY-1819 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Major > Fix For: 1.9.2.CR1 > > > Presently the logout handler is just a Runnable, the problem with this is if it needs any state it means a lambda or an instance of a class tends to be needed to hold the state e.g. > {noformat} > private void setupProgramaticLogout(HttpScope sessionScope) { > logoutHandlerConsumer.accept(() -> { > sessionScope.setAttachment(AUTHENTICATED_IDENTITY_KEY, null); > }); > } > {noformat} > It would likely be better for the logout handler to be able to request the scope it needs so maybe pass in the 'org.wildfly.security.http.HttpServerScopes' at the very least. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1819) The logout handler registration should be reworked

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/ELY-1819?page=com.atlassian.jira.plugin.s... ] Ashley Abdel-Sayed commented on ELY-1819: ----------------------------------------- [~dlofthouse] When taking a closer look at implementing this with the logout handler as a Consumer<HttpServerScopes> and the logoutHandlerConsumer as a Consumer<Consumer<HttpServerScopes>>, I can't see how the scope would be passed in as an argument to the logout handler. When I create the logout handler, as such; `Consumer<HttpServerScopes> logoutHandler = serverScope -> serverScope.getScope(Scope.SESSION).setAttachment(AUTHENTICATED_IDENTITY_KEY, null);` I don't see a way to specify the serverScope without calling ```logoutHandler.accept(scope);``` but the logoutHandlerConsumer.accept() needs to take in a logoutHandler (previously runnable, now Consumer<HttpServerScope>. It doesn't seem like this implementation allows us to pass in the scope. > The logout handler registration should be reworked > -------------------------------------------------- > > Key: ELY-1819 > URL: https://issues.jboss.org/browse/ELY-1819 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Major > Fix For: 1.9.2.CR1 > > > Presently the logout handler is just a Runnable, the problem with this is if it needs any state it means a lambda or an instance of a class tends to be needed to hold the state e.g. > {noformat} > private void setupProgramaticLogout(HttpScope sessionScope) { > logoutHandlerConsumer.accept(() -> { > sessionScope.setAttachment(AUTHENTICATED_IDENTITY_KEY, null); > }); > } > {noformat} > It would likely be better for the logout handler to be able to request the scope it needs so maybe pass in the 'org.wildfly.security.http.HttpServerScopes' at the very least. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-1819) The logout handler registration should be reworked

by Ashley Abdel-Sayed (Jira)

[ https://issues.jboss.org/browse/ELY-1819?page=com.atlassian.jira.plugin.s... ] Ashley Abdel-Sayed updated ELY-1819: ------------------------------------ Comment: was deleted (was: [~dlofthouse] When taking a closer look at implementing this with the logout handler as a Consumer<HttpServerScopes> and the logoutHandlerConsumer as a Consumer<Consumer<HttpServerScopes>>, I can't see how the scope would be passed in as an argument to the logout handler. When I create the logout handler, as such; `Consumer<HttpServerScopes> logoutHandler = serverScope -> serverScope.getScope(Scope.SESSION).setAttachment(AUTHENTICATED_IDENTITY_KEY, null);` I don't see a way to specify the serverScope without calling ```logoutHandler.accept(scope);``` but the logoutHandlerConsumer.accept() needs to take in a logoutHandler (previously runnable, now Consumer<HttpServerScope>. It doesn't seem like this implementation allows us to pass in the scope. ) > The logout handler registration should be reworked > -------------------------------------------------- > > Key: ELY-1819 > URL: https://issues.jboss.org/browse/ELY-1819 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Major > Fix For: 1.9.2.CR1 > > > Presently the logout handler is just a Runnable, the problem with this is if it needs any state it means a lambda or an instance of a class tends to be needed to hold the state e.g. > {noformat} > private void setupProgramaticLogout(HttpScope sessionScope) { > logoutHandlerConsumer.accept(() -> { > sessionScope.setAttachment(AUTHENTICATED_IDENTITY_KEY, null); > }); > } > {noformat} > It would likely be better for the logout handler to be able to request the scope it needs so maybe pass in the 'org.wildfly.security.http.HttpServerScopes' at the very least. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4421) [DMN Designer] Search feature - Apply keyboard guide lines into the Search Component

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4421: --------------------------------------- Summary: [DMN Designer] Search feature - Apply keyboard guide lines into the Search Component Key: DROOLS-4421 URL: https://issues.jboss.org/browse/DROOLS-4421 Project: Drools Issue Type: Task Reporter: Guilherme Gomes Assignee: Guilherme Gomes Attachments: key-1.png, key-2.png Follow UX guide lines, to improve the UX from the shortcuts perspective. Check the whole presentation here: https://docs.google.com/presentation/d/1itceVe225mMtR55pqB-llpLNdU6kq4TBi...) Main points: !key-1.png|thumbnail! !key-2.png|thumbnail! -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4395) [DMN Designer] Validation fails for included models

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4395?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-4395: ------------------------------------ Sprint: 2019 Week 32-34 > [DMN Designer] Validation fails for included models > --------------------------------------------------- > > Key: DROOLS-4395 > URL: https://issues.jboss.org/browse/DROOLS-4395 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.25.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > Attachments: Screenshot from 2019-08-02 14-01-32.png, error.log > > > The attached screenshot shows an error coming from a dmn file that has a imported another dmn model. All dmn models with imported other models (dmn or pmml) throws an error during validation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4395) [DMN Designer] Validation fails for included models

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4395?page=com.atlassian.jira.plugi... ] Guilherme Gomes commented on DROOLS-4395: ----------------------------------------- Yes, [~tirelli] :-) > [DMN Designer] Validation fails for included models > --------------------------------------------------- > > Key: DROOLS-4395 > URL: https://issues.jboss.org/browse/DROOLS-4395 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.25.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > Attachments: Screenshot from 2019-08-02 14-01-32.png, error.log > > > The attached screenshot shows an error coming from a dmn file that has a imported another dmn model. All dmn models with imported other models (dmn or pmml) throws an error during validation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2019