[JBoss JIRA] (WFCORE-282) Wildcard operations that span multiple processes
by Emanuel Muckenhuber (JIRA)
[ https://issues.jboss.org/browse/WFCORE-282?page=com.atlassian.jira.plugin... ]
Emanuel Muckenhuber moved WFLY-723 to WFCORE-282:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-282 (was: WFLY-723)
Issue Type: Task (was: Feature Request)
Component/s: Domain Management
(was: Domain Management)
Fix Version/s: 1.0.0.Beta1
(was: Awaiting Volunteers)
> Wildcard operations that span multiple processes
> ------------------------------------------------
>
> Key: WFCORE-282
> URL: https://issues.jboss.org/browse/WFCORE-282
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Labels: as7-ignored
> Fix For: 1.0.0.Beta1
>
>
> Handle host=* and host=y,server=* type operations.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFCORE-281) Unable to check result "undefined" in cli
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-281?page=com.atlassian.jira.plugin... ]
Alexey Loubyansky moved WFLY-4118 to WFCORE-281:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-281 (was: WFLY-4118)
Affects Version/s: 1.0.0.Alpha13
(was: 9.0.0.Alpha1)
Component/s: CLI
(was: CLI)
Fix Version/s: (was: 9.0.0.Beta1)
> Unable to check result "undefined" in cli
> -----------------------------------------
>
> Key: WFCORE-281
> URL: https://issues.jboss.org/browse/WFCORE-281
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 1.0.0.Alpha13
> Reporter: Joe Wertz
> Assignee: Joe Wertz
> Priority: Minor
>
> if-else constructs in the CLI can't compare against undefined attribute results.
> Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Summary: Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config (was: Dynamic update with KieContainer.updateToVersion() not working in STREAM mode)
> Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Gabor Auth (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Gabor Auth commented on WFLY-3718:
----------------------------------
Another stacktrace from WildFly 8.2.0.Final:
{code}
==> /home/wildfly/wildfly-8.2.0.Final/domain/servers/server-two/log/server.log <==
2014-11-26 13:46:29,668 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /frontend/index.jsp: java.lang.NullPointerException
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163)
at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:718) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
{code}
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 8.2.0.Final
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
by Sande Gilda (JIRA)
[ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.... ]
Sande Gilda commented on WFLY-4125:
-----------------------------------
Can it be configured to log the exception message, but suppress the stacktrace?
> javax.ejb.NoSuchEJBException should not print a stacktrace on the server console
> ---------------------------------------------------------------------------------
>
> Key: WFLY-4125
> URL: https://issues.jboss.org/browse/WFLY-4125
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Sande Gilda
> Assignee: David Lloyd
>
> See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293
> The shopping-cart quickstart has a note in the README file that states:
> Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available.
> However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868)
> I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it.
> See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983
> David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log?
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-242:
------------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from ASSIGNED to POST
> the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-242
> URL: https://issues.jboss.org/browse/WFCORE-242
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Jay Kumar SenSharma
> Assignee: Emmanuel Hugonnet
> Priority: Minor
>
> - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error:
> {code}
> [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months