[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
[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
[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
[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
[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
[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
[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