March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1461: ---------------------------------------- I'm also voting for close/reject this issue, as the second rule in the description has a different semantic than what intended by the reporter, I think. The second rule semantic means, check {{message}} is contained {{in}} the elements within the round parenthesis. Now the message property (String) is NOT contained in the set of elements contaning 1 element, the global {{$myGlobal}} which is in itself a list. In other words and pseudocode it's checking if: {code:java} "anton" ⊆ { ["anton", "giertli"] } {code} which is false. Please notice the set on the right (marked by the { } parenthesis) contains 1 element, the list represented by the [ ] parenthesis ---- This can be demonstrated also by changing the test for message to contain an arbitrary Object, as: !screenshot-1.png|thumbnail! which would realize the check {code:java} ["anton", "giertli"] ⊆ { ["anton", "giertli"] } {code} which is then true, and making {{testInOperator()}} pass. ---- Please notice only the *_first_* rule in the description is doing semantically what I expect is actually desired by the reporter which is: {code:java} "anton" ⊆ { "anton", "giertli" } {code} (you can notice now the set on the right marked by the { } parenthesis contains 2 elements) > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1461) In operator doesn't work with variable

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1461?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-1461: ----------------------------------- Attachment: screenshot-1.png > In operator doesn't work with variable > -------------------------------------- > > Key: DROOLS-1461 > URL: https://issues.jboss.org/browse/DROOLS-1461 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Anton Giertli > Assignee: Mario Fusco > Attachments: operators.zip, screenshot-1.png > > > This works just fine: > {code:java} > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( "anton","giertli") ) > then > System.out.println("LHS OK"); > end > {code} > But rule like this, won't fire: > {code:java} > global java.util.List $myGlobal; > rule "checkFirstName" > dialect "mvel" > when > Message( message in ( $myGlobal) ) > then > System.out.println("LHS OK"); > end > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2352) Migrate the WildFly Elytron subsystem to WildFly Core

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2352?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2352: ------------------------------------- Priority: Critical (was: Major) > Migrate the WildFly Elytron subsystem to WildFly Core > ----------------------------------------------------- > > Key: WFCORE-2352 > URL: https://issues.jboss.org/browse/WFCORE-2352 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta7 > > > This task is to move the subsystem to WildFly Core. This task is not to add the subsystem to any additional feature packs. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-55) CFME Tests: Adjust environment and smoke tests to JMAN4-111

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-55: ---------------------------------------- Summary: CFME Tests: Adjust environment and smoke tests to JMAN4-111 Key: HAWKULARQE-55 URL: https://issues.jboss.org/browse/HAWKULARQE-55 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Priority: Blocker Once [JMAN4-111|https://issues.jboss.org/browse/JMAN4-111] feature is done, EAP servers on Containers will become immutable, but our CFME Testing environment runs on Containers. * switch EAP7 Containers to VMs * and for container EAP7 make smoke tests -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2358) deployment-overlay link action help is not accurate

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2358: -------------------------------------------- Summary: deployment-overlay link action help is not accurate Key: WFCORE-2358 URL: https://issues.jboss.org/browse/WFCORE-2358 Project: WildFly Core Issue Type: Bug Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Priority: Minor Deployment can be created after being linked to the overlay. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-54) JDG integration into CFME

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-54: ---------------------------------------- Summary: JDG integration into CFME Key: HAWKULARQE-54 URL: https://issues.jboss.org/browse/HAWKULARQE-54 Project: Hawkular QE Issue Type: Task Environment: From Heiko's status email 02/02. Reporter: Hayk Hovsepyan Assignee: Hayk Hovsepyan Currently work is in progress for MiQ upstream. Further information about including in downstream later. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-8160: ----------------------------------- Could you provide file leak track with help of http://file-leak-detector.kohsuke.org/ This will provide you with list of stacktraces where the file leaks are occuring and please paste that back here. > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Priority: Blocker > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8160) Webservice response File Descriptor leak

by Jim Ma (JIRA)

[ https://issues.jboss.org/browse/WFLY-8160?page=com.atlassian.jira.plugin.... ] Jim Ma commented on WFLY-8160: ------------------------------ Hi [~maheshvizag], Can you please provide the other classes/test project that we can reproduce this issue locally ? What is your client code ? > Webservice response File Descriptor leak > ---------------------------------------- > > Key: WFLY-8160 > URL: https://issues.jboss.org/browse/WFLY-8160 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final > Environment: JDK: jdk1.8.0_121, jdk1.8.0_66 > WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final > OS: Red Hat Enterprise Linux Server release 7.1 (Maipo) > Hardware: 64 bit 4 core > Reporter: Mahesh Reddy > Assignee: Alessio Soldano > Priority: Blocker > Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt > > > We are getting File descriptor leak when wildfly responds to webservice call. > I think this happens if the webresvice response is huge complex structure, > I confirmed by adding the sleep just before the returning from the webservice method and checking lsof -p <pid>, And again checking it after client receives the response,. > I notice for each webservice call, 2 file descriptors are open and never closed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8285) Elytron, Can't access application secured with SPNEGO fallbacking to FORM

by Martin Choma (JIRA)

Martin Choma created WFLY-8285: ---------------------------------- Summary: Elytron, Can't access application secured with SPNEGO fallbacking to FORM Key: WFLY-8285 URL: https://issues.jboss.org/browse/WFLY-8285 Project: WildFly Issue Type: Bug Components: Security Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker When accessing application configured with SPNEGO + FORM fallback, then user get 404 on first http GET. {code} [mchoma@localhost ~]$ curl -v http://localhost.localdomain:8080/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/pr... * Hostname was NOT found in DNS cache * Trying 127.0.0.1... * Connected to localhost.localdomain (127.0.0.1) port 8080 (#0) > GET /be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/SimpleSecuredServlet HTTP/1.1 > User-Agent: curl/7.37.0 > Host: localhost.localdomain:8080 > Accept: */* > < HTTP/1.1 404 Not Found < Expires: 0 < Cache-Control: no-cache, no-store, must-revalidate < X-Powered-By: Undertow/1 < Set-Cookie: JSESSIONID=0O3kk4WJTVuH0XuWriO_d_M6HMCb83Ri7UZmtUU0.localhost; path=/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5 * Server JBoss-EAP/7 is not blacklisted < Server: JBoss-EAP/7 < Pragma: no-cache < Date: Fri, 03 Mar 2017 09:15:41 GMT < Connection: keep-alive < WWW-Authenticate: Negotiate < Content-Type: text/html;charset=UTF-8 < Content-Length: 149 < * Connection #0 to host localhost.localdomain left intact <html><head><title>Error</title></head><body>/be4459d3-1eb1-4aa9-a42a-e6a63c1d33c5/protected/http:/localhost.localdomain:8080/login.jsp</body></html>[mchoma@localhost ~]$ {code} Changing in web.xml {{<auth-method>SPNEGO,FORM</auth-method>}} to {{<auth-method>SPNEGO</auth-method>}} makes SPNEGO work again. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2357) RBAC: The two kinds of non-addressability

by Hynek Švábek (JIRA)

Hynek Švábek created WFCORE-2357: ------------------------------------ Summary: RBAC: The two kinds of non-addressability Key: WFCORE-2357 URL: https://issues.jboss.org/browse/WFCORE-2357 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.1.0.Final Reporter: Hynek Švábek Assignee: Brian Stansberry Ever since we introduced RBAC in WildFly / EAP, we had this shortcut in place that we were documenting in EAP Release Notes: bq. Some resources are non-addressable to server-group and host scoped roles in order to provide a simplified view of the management model to improve usability. This is distinct from resources that are non-addressable to protect sensitive data. I think that this shortcut is in place mainly because HAL can't cope with addressable but non-readable resources, but there might be other reasons. In any case, I figured I should finally file an upstream JIRA so that I don't have to bug Brian all the time if this has changed :-) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017