[JBoss JIRA] (WFCORE-1742) Allow registering a custom handler for management interface
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1742?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1742:
------------------------------------------
[~jmesnil] fyi as we are talking about a management related subsystem in the context of the process state listener RFE.
> Allow registering a custom handler for management interface
> -----------------------------------------------------------
>
> Key: WFCORE-1742
> URL: https://issues.jboss.org/browse/WFCORE-1742
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Sebastian Łaskawiec
>
> When building [HealthCheck API for Infisnispan|https://github.com/infinispan/infinispan/pull/4499] we noticed there is no way to register a custom endpoint on Management REST interface. Without it, calling the API requires using HTTP POST method (since it includes runtime parameters) and the URL is very long (and not intuitive for our users):
> {noformat}
> curl --digest -L -D - "http://localhost:9990/management/subsystem/datagrid-infinispan/cache-cont..." --header "Content-Type: application/json" -u ispnadmin:ispnadmin
> HTTP/1.1 401 Unauthorized
> Connection: keep-alive
> WWW-Authenticate: Digest realm="ManagementRealm",domain="/management",nonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",opaque="00000000000000000000000000000000",algorithm=MD5,qop="auth"
> Content-Length: 77
> Content-Type: text/html
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> HTTP/1.1 200 OK
> Connection: keep-alive
> Authentication-Info: nextnonce="AuZzFxz7uC4NMTQ3MDgyNTU1NTQ3OCfIJBHXVpPHPBdzGUy7Qts=",qop="auth",rspauth="b518c3170e627bd732055c382ce5d970",cnonce="NGViOWM0NDY5OGJmNjY0MjcyOWE4NDkyZDU3YzNhYjY=",nc=00000001
> Content-Type: application/json; charset=utf-8
> Content-Length: 1927
> Date: Wed, 10 Aug 2016 10:39:15 GMT
> {
> "cache-health" : "GREEN",
> "cluster-health" : ["test"],
> "cluster-name" : "clustered",
> "free-memory" : 96778,
> "log-tail" : [
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-5) DGENDPT10001: HotRodServer listening on 127.0.0.1:11222",
> "2016-08-10 11:54:14,706 INFO [org.infinispan.server.endpoint] (MSC service thread 1-1) DGENDPT10001: MemcachedServer listening on 127.0.0.1:11211",
> "2016-08-10 11:54:14,785 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___protobuf_metadata cache from clustered container",
> "2016-08-10 11:54:14,800 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-6) DGISPN0001: Started ___script_cache cache from clustered container",
> "2016-08-10 11:54:15,159 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0001: Started ___hotRodTopologyCache cache from clustered container",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.rest.NettyRestServer] (MSC service thread 1-6) ISPN012003: REST server starting, listening on 127.0.0.1:8080",
> "2016-08-10 11:54:15,210 INFO [org.infinispan.server.endpoint] (MSC service thread 1-6) DGENDPT10002: REST mapped to /rest",
> "2016-08-10 11:54:15,306 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990",
> "2016-08-10 11:54:15,307 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: Infinispan Server 9.0.0-SNAPSHOT (WildFly Core 2.2.0.CR9) started in 8681ms - Started 196 of 237 services (121 services are lazy, passive or on-demand)"
> ],
> "number-of-cpus" : 8,
> "number-of-nodes" : 1,
> "total-memory" : 235520
> }%
> {noformat}
> It would be very convenient to allow exposing such endpoints with optional authorization and using custom URLs (e.g. something like http://localhost:9990/health).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7062) Infinispan query NPE on caches created by EmbeddedCacheManager
by Pavol Loffay (JIRA)
[ https://issues.jboss.org/browse/WFLY-7062?page=com.atlassian.jira.plugin.... ]
Pavol Loffay updated WFLY-7062:
-------------------------------
Description:
Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
Application source code: https://github.com/pavolloffay/infinispan-wildfly10
Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
{code:java}
15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
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.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
... 42 more
{code}
was:
Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
Application source code: https://github.com/pavolloffay/infinispan-wildfly10
Error for infinispan 8.2.0.Final in Wildfly 10.0.0.Final:
> Infinispan query NPE on caches created by EmbeddedCacheManager
> --------------------------------------------------------------
>
> Key: WFLY-7062
> URL: https://issues.jboss.org/browse/WFLY-7062
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Environment: Fedora 24
> openjdk version "1.8.0_102"
> OpenJDK Runtime Environment (build 1.8.0_102-b14)
> OpenJDK 64-Bit Server VM (build 25.102-b14, mixed mode)
> Reporter: Pavol Loffay
> Assignee: Jason Greene
> Priority: Blocker
>
> Null pointer exception in DelegatingQuery.java:42 when using infinispan-query in cache managed by EmbeddedCacheManager injected from Wildfly 10.1.0.Final.
> Query executed on cache created from DefaultCacheManager defaultCacheManager = new DefaultCacheManager(); works fine.
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> When cache is created from EmbeddedCacheManager injected from Wildfly 10.1.0.Final it throws following exception:
> https://github.com/pavolloffay/infinispan-wildfly10/blob/master/src/main/...
> Note that similar NPE exception is thrown for Wildfly 10.0.0.Final (infinispan 8.2.0.Final).
> Application source code: https://github.com/pavolloffay/infinispan-wildfly10
> Exception when updated to 8.2.4.Final and deployed to Wildfly 10.1.0.Final
> {code:java}
> 15:51:14,692 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /stringContainer: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
> at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
> at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
> at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 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.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 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 io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:42)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:49)
> at sk.loffay.cache.StringCacheContainer.query(StringCacheContainer.java:53)
> at sk.loffay.rest.ContainerHandler.getContainer(ContainerHandler.java:43)
> at sk.loffay.rest.ContainerHandler$Proxy$_$$_WeldClientProxy.getContainer(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
> ... 42 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1768:
------------------------------------------
In addition to that one we actually have a couple more packages that are _private not listed.
> elytron module.xml, invalid package name in exclude
> ---------------------------------------------------
>
> Key: WFCORE-1768
> URL: https://issues.jboss.org/browse/WFCORE-1768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1768) elytron module.xml, invalid package name in exclude
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1768?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1768:
-------------------------------------
Summary: elytron module.xml, invalid package name in exclude (was: elytron module.xml, unnecessary exclude)
> elytron module.xml, invalid package name in exclude
> ---------------------------------------------------
>
> Key: WFCORE-1768
> URL: https://issues.jboss.org/browse/WFCORE-1768
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> in {noformat}./jboss-eap-7.1/modules/system/layers/base/org/wildfly/security/elytron/main/module.xml {noformat}
> there is {noformat} <exclude path="org/wildfly/wildfly/security/manager/_private"/>{noformat}, which is probably unnecessary.
> {noformat}
> <module xmlns="urn:jboss:module:1.3" name="org.wildfly.security.elytron">
> <exports>
> <exclude path="org/wildfly/security/_private"/>
> <exclude path="org/wildfly/wildfly/security/manager/_private"/>
> </exports>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node
by Fabian Meyer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ]
Fabian Meyer commented on DROOLS-844:
-------------------------------------
The reproducer I sent you last time (mail from 17.07.15) creates the NPE for 6.4.0.final and the latest 7.0.0-SNAPSHOT.
> Crash when node is deleted from query node
> ------------------------------------------
>
> Key: DROOLS-844
> URL: https://issues.jboss.org/browse/DROOLS-844
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final, 7.0.0.Beta1
> Reporter: Fabian Meyer
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.4.0.Beta1
>
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (DROOLS-844) Crash when node is deleted from query node
by Fabian Meyer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-844?page=com.atlassian.jira.plugin... ]
Fabian Meyer updated DROOLS-844:
--------------------------------
Affects Version/s: 7.0.0.Beta1
6.4.0.Final
(was: 6.3.0.Beta2)
> Crash when node is deleted from query node
> ------------------------------------------
>
> Key: DROOLS-844
> URL: https://issues.jboss.org/browse/DROOLS-844
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final, 7.0.0.Beta1
> Reporter: Fabian Meyer
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.4.0.Beta1
>
>
> When a left delete is performed on a PhreakQueryNode, the fact handle of the left tuple might be null, resulting in a NullPointerException.
> Exception in thread "Thread-6" java.lang.NullPointerException
> at org.drools.core.phreak.PhreakQueryNode.doLeftDeletes(PhreakQueryNode.java:176)
> at org.drools.core.phreak.PhreakQueryNode.doNode(PhreakQueryNode.java:46)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalQueryNode(RuleNetworkEvaluator.java:460)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:360)
> at org.drools.core.phreak.RuleNetworkEvaluator.doRiaNode(RuleNetworkEvaluator.java:598)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:524)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:336)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:973)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:1251)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1353)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1331)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFCORE-1556:
-------------------------------------
I'm hoping I'm not hijacking this issue but I have an use case in the messaging-activemq subsystem that would benefit from this improvement.
A discovery-group resource can either have a socket-binding attribute or jgroups-channel / jgroups-stack attributes.
If socket-binding attribute is set, jgroups-channel and jgroups-stack are not valid
if socket-binding attribute is not set, JGroups resources will be used *but* jgroups-channel and jgroups-stack can still be undefined (i.e. use default channel and stack from jgroups subsystem).
As an example, a discovery-group without any attributes must be valid and will use the default channel and stack from JGroups.
What would be the flags on the ADs?
socket-binding: required, alternative=jgroups-channel
jgroups-channel: optional, alternative=socket-binding
jgroups-stack: optional, alternative=socket-binding
> Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1556
> URL: https://issues.jboss.org/browse/WFCORE-1556
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
> The read-resource-description output for an attribute doesn't show "required" at all.
> After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
> The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
> And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
> nillable = !required || alternatives != null
> Right now, nillable is implemented as
> nillable = !required
> There are a number of problems I see with AttributeDefinition:
> 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
> 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
> 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
> 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
> I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
> Next would be to fix 3), by changing how AD validates.
> Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
> Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months