March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8262) Upgrade to jboss-el-api 1.0.9.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8262?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-8262: ------------------------------ Summary: Upgrade to jboss-el-api 1.0.9.Final (was: Upgrade to jboss-el-api 1.0.8.Final) > Upgrade to jboss-el-api 1.0.9.Final > ----------------------------------- > > Key: WFLY-8262 > URL: https://issues.jboss.org/browse/WFLY-8262 > Project: WildFly > Issue Type: Task > Components: Build System, EE > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Upgrade to 1.0.8. To include JBEE-174 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8262) Upgrade to jboss-el-api 1.0.9.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8262?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-8262: ------------------------------ Description: Upgrade to 1.0.9. To include JBEE-174 (was: Upgrade to 1.0.8. To include JBEE-174) > Upgrade to jboss-el-api 1.0.9.Final > ----------------------------------- > > Key: WFLY-8262 > URL: https://issues.jboss.org/browse/WFLY-8262 > Project: WildFly > Issue Type: Task > Components: Build System, EE > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Upgrade to 1.0.9. To include JBEE-174 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2348) Error while starting WildFly as service in domain mode using init scripts.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2348?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2348: ------------------------------------------ There is no downstream dependency here. These files are not used in EAP. There is no docs/contrib folder in the EAP distribution. > Error while starting WildFly as service in domain mode using init scripts. > -------------------------------------------------------------------------- > > Key: WFCORE-2348 > URL: https://issues.jboss.org/browse/WFCORE-2348 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta7 > Environment: Fedora, RHEL > Reporter: Radovan Stancel > Assignee: Radovan Stancel > Priority: Minor > Labels: downstream_dependency > Original Estimate: 4 hours > Time Spent: 3 hours > Remaining Estimate: 1 hour > > When starting WildFly as a service in domain mode using init scripts there appears in console.log error: > /usr/bin/dirname: unrecognized option '--domain-config=domain.xml' > Try '/usr/bin/dirname --help' for more information. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1356) Advance PseudoClock in KIE-Server/Decision Server

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1356?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-1356: ---------------------------------------- I suggest to have actually two commands for advance. The first one shall reflect existing API, this is a draft: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core... The second one shall "compare and change" similar to java AtomicNumber as this command might be helpful given a kie-server is a remote CEP, this is a draft: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core... I have a concern as the {{`GetSessionClockCommand`}} was also existing at the time I drafted the commands above^, yet I carried on trying to roll my own to just get the value out: https://github.com/tarilabs/drools/blob/patch-pseudoclockcmds/drools-core... I'm not sure why. > Advance PseudoClock in KIE-Server/Decision Server > ------------------------------------------------- > > Key: DROOLS-1356 > URL: https://issues.jboss.org/browse/DROOLS-1356 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.0.0.Beta2 > Environment: JBoss BRMS 6.4.0, macOS 10.11.1, Oracle Hotspot 1.8.0_101 > Reporter: Duncan Doyle > Assignee: Mario Fusco > > KIE-Server does not provide a command to advance the time of a pseudo-clock. This functionality is required (or at least, highly useful) when KIE-Server is used for CEP sessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-57) Use hawkular/hawkular-services images for LOTE

by viet nguyen (JIRA)

viet nguyen created HAWKULARQE-57: ------------------------------------- Summary: Use hawkular/hawkular-services images for LOTE Key: HAWKULARQE-57 URL: https://issues.jboss.org/browse/HAWKULARQE-57 Project: Hawkular QE Issue Type: Task Reporter: viet nguyen Assignee: mfoley user Priority: Minor Development has introduced a OpenShift pod for hawkular services. We should run livingontheedge.hawkular.org with this instead of our own https://github.com/Hawkular-QE/hawkular-services-docker -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugi... ] Brian Stansberry moved JBEAP-9300 to WFCORE-2360: ------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2360 (was: JBEAP-9300) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Domain Management (was: Domain Management) (was: User Experience) Affects Version/s: 3.0.0.Beta6 (was: 7.1.0.DR13) > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Beta6 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain@localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain@localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2360) Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2360?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2360: ------------------------------------- Affects Version/s: (was: 3.0.0.Beta6) > Misleading failure description upon attempt of /host=slave/server-config=x:remove() when server-config=x is still running > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2360 > URL: https://issues.jboss.org/browse/WFCORE-2360 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > When trying to remove a running {{server-config}} on slave host from {{host-master}} controller, the following message is produced in CLI: > {code}[domain@localhost:9990 /] /host=hc1/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"hc1" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYCTL0063: Composite operation was rolled back."}}, > "rolled-back" => true > } > {code} > This is not very informative. The error message from just removing running {{server-config}} managed by controller is different, and also much more informative: > {code}[domain@localhost:9990 /] /host=master/server-config=server-two:remove() > { > "outcome" => "failed", > "result" => {}, > "failure-description" => {"host-failure-descriptions" => {"master" => "WFLYHC0078: Server (server-two) still running"}}, > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1356) Advance PseudoClock in KIE-Server/Decision Server

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1356?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-1356: ----------------------------------- Assignee: Mario Fusco (was: Matteo Mortari) > Advance PseudoClock in KIE-Server/Decision Server > ------------------------------------------------- > > Key: DROOLS-1356 > URL: https://issues.jboss.org/browse/DROOLS-1356 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 7.0.0.Beta2 > Environment: JBoss BRMS 6.4.0, macOS 10.11.1, Oracle Hotspot 1.8.0_101 > Reporter: Duncan Doyle > Assignee: Mario Fusco > > KIE-Server does not provide a command to advance the time of a pseudo-clock. This functionality is required (or at least, highly useful) when KIE-Server is used for CEP sessions. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Radovan Netuka commented on SECURITY-921: ----------------------------------------- PR for 2.3.x: https://github.com/wildfly-security/jboss-negotiation/pull/35 > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC

by Radovan Netuka (JIRA)

[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ] Radovan Netuka updated SECURITY-921: ------------------------------------ Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/35 Affects Version/s: Negotiation_2_3_11_Final > SPNEGO authentication fails on Windows-KDC > ------------------------------------------ > > Key: SECURITY-921 > URL: https://issues.jboss.org/browse/SECURITY-921 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_3_0_0_CR1, Negotiation_2_3_11_Final > Environment: * > Reporter: Harald Krause > Assignee: Radovan Netuka > Labels: web_security > > Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list: > {code:java} > if (mechList.get(0).equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > } > else > { > boolean kerberosSupported = false; > ... > {code} > But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids): > * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5) > * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for) > * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx > * oid: 1.3.6.1.4.1.311.2.2.10 NTLM > So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid: > {code:java} > for (Oid oid : mechList) > { > if (oid.equals(kerberos)) > { > gssToken = negTokenInit.getMechToken(); > break; > } > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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