[JBoss JIRA] (WFLY-5425) http-listener requires 'https' socket-binding, part 2
by Vsevolod Golovanov (JIRA)
Vsevolod Golovanov created WFLY-5425:
----------------------------------------
Summary: http-listener requires 'https' socket-binding, part 2
Key: WFLY-5425
URL: https://issues.jboss.org/browse/WFLY-5425
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.2.0.Final
Reporter: Vsevolod Golovanov
Assignee: Stuart Douglas
Continuing WFLY-2836.
Is there a way to override {{http-listener}}'s {{redirect-socket}} attribute default value ("https") to be null?
{quote}This is just default value, looking at the downside of not having default value for redirect-socket would be that people would not configure it, which would result in problems when having apps that require secure transport.{quote}
Our app doesn't require secure transport.
{code}redirect-socket=""{code}
results in
{noformat}
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[956,166]
Message: "JBAS014704: '' is an invalid value for parameter redirect-socket. Values must have a minimum length of 1 characters"
{noformat}
This:
{code}redirect-socket="null"{code}
treats it literally:
{noformat}
]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.undertow.listener.someapp-http-listener is missing [jboss.binding.null]"]}
{noformat}
So we're forced to have a https socket-binding. Which is not a "just define some binding" problem. It's a "negotiate with customers&sysadmins/document it/provide options to configure it" problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-931) Drools 4.0.7
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-931?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-931:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Drools 4.0.7
> ------------
>
> Key: DROOLS-931
> URL: https://issues.jboss.org/browse/DROOLS-931
> Project: Drools
> Issue Type: Bug
> Environment: WAS 6.1(JDK 1.5) & WAS 8.5.5(JDK 1.7)
> Reporter: raj S
> Assignee: Mario Fusco
>
> We have around 10,000+ rules running on a legacy system which is using jdk 1.5. those rules doesn't have salience set for all the rules , but have been tested to work fine with older jdk.
> Now are trying to upgrade the system to later version of JDK, rules execution order seems to be difference ,because they don't have salience set. in the process we have identified that few rules were having coding issues and corrected them.
> Issue: is there a way to grantee the same execution order between the jdk 1.5 & JDK 1.7. we haven't updated the drools version just the JDK. can you please give us some insight in to the natural order of rules execution in drools engine so we can put in a fix outside the engine to ensure the same order. any help is appreciated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-931) Drools 4.0.7
by raj S (JIRA)
raj S created DROOLS-931:
----------------------------
Summary: Drools 4.0.7
Key: DROOLS-931
URL: https://issues.jboss.org/browse/DROOLS-931
Project: Drools
Issue Type: Bug
Environment: WAS 6.1(JDK 1.5) & WAS 8.5.5(JDK 1.7)
Reporter: raj S
Assignee: Mark Proctor
We have around 10,000+ rules running on a legacy system which is using jdk 1.5. those rules doesn't have salience set for all the rules , but have been tested to work fine with older jdk.
Now are trying to upgrade the system to later version of JDK, rules execution order seems to be difference ,because they don't have salience set. in the process we have identified that few rules were having coding issues and corrected them.
Issue: is there a way to grantee the same execution order between the jdk 1.5 & JDK 1.7. we haven't updated the drools version just the JDK. can you please give us some insight in to the natural order of rules execution in drools engine so we can put in a fix outside the engine to ensure the same order. any help is appreciated.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-1019) History browsing in CLI (using the up arrow) works strangely
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugi... ]
Ladislav Thon updated WFCORE-1019:
----------------------------------
Description:
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}
OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
was:
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}
OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
> Key: WFCORE-1019
> URL: https://issues.jboss.org/browse/WFCORE-1019
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.CR1, 2.0.0.CR5
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 / WildFly Core 2.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-1019) History browsing in CLI (using the up arrow) works strangely
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugi... ]
Ladislav Thon updated WFCORE-1019:
----------------------------------
Description:
I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
{code}
rm ~/.jboss-cli-history # let's start with clean slate
./wildfly-10.0.0.Beta2/bin/standalone.sh
# the following is in second console
./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}
OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
was:
I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:
{code}
rm ~/.jboss-cli-history # let's start with clean slate
./jboss-eap-7.0/bin/standalone.sh
# the following is in second console
./jboss-eap-7.0/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}
OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
> Key: WFCORE-1019
> URL: https://issues.jboss.org/browse/WFCORE-1019
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.CR1, 2.0.0.CR5
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in WildFly 10.0.0.CR1 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./wildfly-10.0.0.Beta2/bin/standalone.sh
> # the following is in second console
> ./wildfly-10.0.0.Beta2/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with WildFly 10.0.0.CR1 or CR2 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-1019) History browsing in CLI (using the up arrow) works strangely
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1019?page=com.atlassian.jira.plugi... ]
Ladislav Thon updated WFCORE-1019:
----------------------------------
Affects Version/s: 2.0.0.CR5
2.0.0.CR1
> History browsing in CLI (using the up arrow) works strangely
> ------------------------------------------------------------
>
> Key: WFCORE-1019
> URL: https://issues.jboss.org/browse/WFCORE-1019
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.0.CR1, 2.0.0.CR5
> Reporter: Ladislav Thon
> Assignee: Alexey Loubyansky
>
> I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:
> {code}
> rm ~/.jboss-cli-history # let's start with clean slate
> ./jboss-eap-7.0/bin/standalone.sh
> # the following is in second console
> ./jboss-eap-7.0/bin/jboss-cli.sh -c
> :read-resource
> :whoami
> [up arrow shows :whoami, so press Enter to run it]
> [and repeat, up arrow shows :whoami]
> {code}
> OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (WFCORE-1019) History browsing in CLI (using the up arrow) works strangely
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-1019:
-------------------------------------
Summary: History browsing in CLI (using the up arrow) works strangely
Key: WFCORE-1019
URL: https://issues.jboss.org/browse/WFCORE-1019
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Ladislav Thon
Assignee: Alexey Loubyansky
I tend to rely on history browsing in the CLI a lot, but it got broken in EAP 7.0.0.DR10 (I'd guess that the cause is the AESH upgrade). Let's see:
{code}
rm ~/.jboss-cli-history # let's start with clean slate
./jboss-eap-7.0/bin/standalone.sh
# the following is in second console
./jboss-eap-7.0/bin/jboss-cli.sh -c
:read-resource
:whoami
[up arrow shows :whoami, so press Enter to run it]
[and repeat, up arrow shows :whoami]
{code}
OK, that's expected. Repeat the process with EAP 7.0.0.DR10 and you'll find out that the second \[up arrow\] shows {{:read-resource}}. This is IMHO highly wrong and it confused me _a lot_ when I first encoutered this bad behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-929) kie-server POST fails with No resource method found for POST, return 405 with Allow header
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-929?page=com.atlassian.jira.plugin... ]
Edson Tirelli closed DROOLS-929.
--------------------------------
Resolution: Rejected
If this is still a problem, feel free to reopen this ticket.
> kie-server POST fails with No resource method found for POST, return 405 with Allow header
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-929
> URL: https://issues.jboss.org/browse/DROOLS-929
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Stefano Picozzi
> Assignee: Edson Tirelli
> Priority: Blocker
>
> Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:
> ...
> 01:45:48,333 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
> 01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 01:45:48,355 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
> 01:46:42,788 WARN [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
> 01:46:43,310 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:46,462 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
> 01:46:46,699 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:47,010 INFO [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 01:47:12,411 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 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.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [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.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [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:1145) [rt.jar:1.7.0_85]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-929) kie-server POST fails with No resource method found for POST, return 405 with Allow header
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-929?page=com.atlassian.jira.plugin... ]
Edson Tirelli commented on DROOLS-929:
--------------------------------------
Stefano, we had to change the REST URI for the post slightly in order to support other containers (WLS).
The POST URI is:
server/containers/instances/{id}
Instead of the old:
server/containers/{id}
We are updating the docs to reflect this.
> kie-server POST fails with No resource method found for POST, return 405 with Allow header
> ------------------------------------------------------------------------------------------
>
> Key: DROOLS-929
> URL: https://issues.jboss.org/browse/DROOLS-929
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Stefano Picozzi
> Assignee: Edson Tirelli
> Priority: Blocker
>
> Testing the kie-server 6.3.0.FINAL build. I did this by pulling down the jboss/kie-server-showcase docker image and replacing the deployments directory with the kie-server.war for the 6.3.0.FINAL release. My tests showed that the REST API works for GET request for inspecting the decision server, works for PUT requests for creating a container but fails when trying to POST facts against the container. Error returned is as per wildfly log fragment below:
> ...
> 01:45:48,333 INFO [org.jboss.as.server] (ServerService Thread Pool -- 31) JBAS018559: Deployed "kie-server.war" (runtime-name : "kie-server.war")
> 01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
> 01:45:48,354 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
> 01:45:48,355 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 11713ms - Started 407 of 458 services (105 services are lazy, passive or on-demand)
> 01:46:42,788 WARN [org.kie.scanner.embedder.MavenSettings] (default task-4) Environment variable M2_HOME is not set
> 01:46:43,310 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:46,462 INFO [org.drools.compiler.kie.builder.impl.KieRepositoryImpl] (default task-4) KieModule was added: ZipKieModule[releaseId=com.redhat.demos:weightwatchers:1.0,file=/opt/jboss/.m2/repository/com/redhat/demos/weightwatchers/1.0/weightwatchers-1.0.jar]
> 01:46:46,699 INFO [org.kie.scanner.embedder.MavenEmbedderUtils] (default task-4) Not in OSGi: using plexus based maven parser
> 01:46:47,010 INFO [org.kie.server.services.impl.KieServerImpl] (default task-4) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 01:47:12,411 WARN [org.jboss.resteasy.core.ExceptionHandler] (default task-6) failed to execute: javax.ws.rs.NotAllowedException: No resource method found for POST, return 405 with Allow header
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:375) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:444) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:234) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:171) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 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.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [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.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [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:1145) [rt.jar:1.7.0_85]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_85]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_85]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months
[JBoss JIRA] (DROOLS-930) ClassCastException after segment split during incremental compilation
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-930?page=com.atlassian.jira.plugin... ]
Mario Fusco closed DROOLS-930.
------------------------------
Fix Version/s: 6.4.x
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/acd6d0fb1
> ClassCastException after segment split during incremental compilation
> ---------------------------------------------------------------------
>
> Key: DROOLS-930
> URL: https://issues.jboss.org/browse/DROOLS-930
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> A segment split during an incremental compilation as in the following test case
> {code}
> @Test
> public void testSegmentSplitOnIncrementalCompilation() throws Exception {
> String drl =
> "import " + Person.class.getCanonicalName() + "\n" +
> "rule R1 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R1\");\n" +
> "end\n" +
> "rule R2 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R2\");\n" +
> "end\n" +
> "rule R3 when\n" +
> " $s : String()" +
> " Person( name != $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R3\");\n" +
> "end\n";
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
> KieModule km = createAndDeployJar(ks, releaseId1);
> KieContainer kc = ks.newKieContainer(km.getReleaseId());
> KieSession ksession = kc.newKieSession();
> kc.updateToVersion(releaseId1);
> ksession.insert(new Person("John", 26));
> ksession.insert( "John" );
> ksession.fireAllRules();
> ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
> km = createAndDeployJar(ks, releaseId2, drl);
> kc.updateToVersion(releaseId2);
> ksession.fireAllRules();
> }
> {code}
> may cause the following ClassCastException during the subsequent network evaluation
> {code}
> java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
> 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:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 9 months