[JBoss JIRA] (JGRP-2499) Switch vom ant&ivy to maven
by Bela Ban (Jira)
Bela Ban created JGRP-2499:
------------------------------
Summary: Switch vom ant&ivy to maven
Key: JGRP-2499
URL: https://issues.redhat.com/browse/JGRP-2499
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.1
The release process is already using maven. To be done:
* Use mvn/surefire for unit tests. This doesn't currently work
* Change directory structure to be maven-compatible
This will allow us to for example consume jgroups-netty as a dependency
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JBAS-5199) Exception in server.log during startup
by Amol Dongare (Jira)
[ https://issues.redhat.com/browse/JBAS-5199?page=com.atlassian.jira.plugin... ]
Amol Dongare updated JBAS-5199:
-------------------------------
Attachment: (was: boot.log)
> Exception in server.log during startup
> --------------------------------------
>
> Key: JBAS-5199
> URL: https://issues.redhat.com/browse/JBAS-5199
> Project: Application Server 3 4 5 and 6
> Issue Type: Bug
> Affects Versions: JBossAS-5.0.0.Beta3
> Environment: windows xp; jboss 5.0.0Beta3
> Reporter: Scott Dickerson
> Priority: Major
>
> 2008-02-01 11:28:19,685 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Failed to update pkgs for cl=org.jboss.mx.loading.UnifiedClassLoader3@473fc2{ url=vfsfile:/C:/JavaTools/jboss-5.0.0.Beta3/server/test/deploy/http-invoker.sar/ ,addedOrder=20}
> java.io.FileNotFoundException: C:\JavaTools\jboss-5.0.0.Beta3\server\test\deploy\http-invoker.sar\invoker.war\WEB-INF\classes (Access is denied)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:106)
> at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:105)
> at java.net.URL.openStream(URL.java:1007)
> ....
> (see attached server.log)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (JGRP-2498) Move dependent projects to 5.0
by Bela Ban (Jira)
Bela Ban created JGRP-2498:
------------------------------
Summary: Move dependent projects to 5.0
Key: JGRP-2498
URL: https://issues.redhat.com/browse/JGRP-2498
Project: JGroups
Issue Type: Task
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0.2
Move projects that consume JGroups (e.g. in jgroups-extras) to 5.0. The {{master}} branch would use 5.0, and the newly created (old) branch 4.x
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5576) Unable to further edit scesim header cell when editing mode previously canceled with Esc
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5576?page=com.atlassian.jira.plug... ]
Jozef Marko reassigned DROOLS-5576:
-----------------------------------
Assignee: Jozef Marko (was: Daniele Zonca)
> Unable to further edit scesim header cell when editing mode previously canceled with Esc
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-5576
> URL: https://issues.redhat.com/browse/DROOLS-5576
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.42.0.Final
> Reporter: Jan Stastny
> Assignee: Jozef Marko
> Priority: Major
>
> In Rule based Test Scenario an alias in Given/Expect facts for either instance or property can be introduced (i.e. in header cells) and override the default instance/property names.
> The header cell can be opened in editing mode by either double-clicking on it or arrow key navigation and pressing Enter.
> When the editing mode is opened the changes can be either confirmed (by pressing Enter or Tab) or canceled (by pressing Esc).
> When the editing mode is canceled using Esc, any consecutive attempt to edit that exact cell is not successful - the editing mode for the cell can't be opened neither by clicking nor pressing any keys.
> For others (not yet hit by the issue) the editing mode opens fine up to the moment described above.
> The issue is not present in ordinary cells (the lines for actual test scenario definitions below the header cells of the grid.)
> The only workaround is to close and open the editor anew.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (DROOLS-5576) Unable to further edit scesim header cell when editing mode previously canceled with Esc
by Jan Stastny (Jira)
Jan Stastny created DROOLS-5576:
-----------------------------------
Summary: Unable to further edit scesim header cell when editing mode previously canceled with Esc
Key: DROOLS-5576
URL: https://issues.redhat.com/browse/DROOLS-5576
Project: Drools
Issue Type: Bug
Components: Scenario Simulation and Testing
Affects Versions: 7.42.0.Final
Reporter: Jan Stastny
Assignee: Daniele Zonca
In Rule based Test Scenario an alias in Given/Expect facts for either instance or property can be introduced (i.e. in header cells) and override the default instance/property names.
The header cell can be opened in editing mode by either double-clicking on it or arrow key navigation and pressing Enter.
When the editing mode is opened the changes can be either confirmed (by pressing Enter or Tab) or canceled (by pressing Esc).
When the editing mode is canceled using Esc, any consecutive attempt to edit that exact cell is not successful - the editing mode for the cell can't be opened neither by clicking nor pressing any keys.
For others (not yet hit by the issue) the editing mode opens fine up to the moment described above.
The issue is not present in ordinary cells (the lines for actual test scenario definitions below the header cells of the grid.)
The only workaround is to close and open the editor anew.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFLY-13763) WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4
by Jim Ma (Jira)
[ https://issues.redhat.com/browse/WFLY-13763?page=com.atlassian.jira.plugi... ]
Jim Ma commented on WFLY-13763:
-------------------------------
We have to change some code to support saaj 1.4 like in cxf : [https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/helpers/DOMUtils.java#L92-L98]
[https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/c...]
It's likely this should be changed in santuario-java to support saaj1.4 .
> WS-Sec Regression with WFLY18+ following upgrade to SAAJ 1.4
> ------------------------------------------------------------
>
> Key: WFLY-13763
> URL: https://issues.redhat.com/browse/WFLY-13763
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Brian Stansberry
> Assignee: Jim Ma
> Priority: Major
>
> This was reported by Andreas Weise at https://groups.google.com/g/wildfly/c/B4Gk4ljbrqE:
> After upgrading to WFY20 we are facing a regression regarding WS-Security that was introduced with Upgrade of com.sun.xml.messaging.saaj:saaj-impl in https://issues.redhat.com/browse/WFLY-12442 with WFLY18. When downgrading com.sun.xml.messaging.saaj:saaj-impl to 1.3.x the regression is fixed also in WFLY18+. We did not locate the root cause in saaj-impl 1.4+.
> The Bug was spotted within our signing algorithm used for our SOAP Web Services (which uses javax.xml.crypto.dsig Packages).
> The Bug can be reproduced easily via https://github.com/weand/wildfly-xml-sig-reproducer, which contains the most basic reproducer code of our scenario:
> Reproducer contains a Web Service implementation which uses XML Signature and more specifically the enveloped-signature transform algorithm (https://www.w3.org/TR/xmldsig-core1/#sec-EnvelopedSignature). This standard transform algorithm basically removes the whole Signature element from the digest calculation. And thats not stable since WFLY18 as the Signature element is not removed anymore! The repo also contains an arquillian test testing the SOAP webservice response using rest-assured.
> Run good scenario: Test on WFLY17
> 1) mvn clean install -Pwfly17
> 2) Test passes
> 3) see proper 'Pre-digested input' as DEBUG output of org.apache.jcp Logger (here I pretty formatted the XML):
> {code}
> 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input:
> 17:58:04,494 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body">
> <ns1:echoResponse
> xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/">
> <return>hello test</return>
> </ns1:echoResponse>
> </soap:Body>
> 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body
> 17:58:04,495 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed
> {code}
> Run failing scenario: Test on WFLY18+
> 1) mvn clean install (which defaults to 20.0.1.Final)
> 2) Test fails
> {code}
> [ERROR] testService(com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT) Time elapsed: 0.874 s <<< FAILURE!
> java.lang.AssertionError:
> Expected: Expected text value '0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=' but was 'A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=' - comparing <DigestValue ...>0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1] to <DigestValue ...>A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue> at /Envelope[1]/Body[1]/Signature[1]/SignedInfo[1]/Reference[1]/DigestValue[1]/text()[1]:
> <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">0FCBFaURtUN+0kxupRbO3pp93rPY+9d1bf7ffAw77lQ=</DigestValue>
> but: result was:
> <DigestValue xmlns="http://www.w3.org/2000/09/xmldsig#">A+XljxuKgY2Va+YDk/Ho66i/+JQLeA9QoTH8kap7Zdk=</DigestValue>
> at com.github.weand.wildfly.xml.sig.reproducer.test.XmlSignatureIT.testService(XmlSignatureIT.java:71)
> {code}
> 3) see invalid 'Pre-digested input' as DEBUG output of org.apache.jcp Logger:
> {code}
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) Pre-digested input:
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.DigesterOutputStream] (default task-1) <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" ID="Body">
> <ns1:echoResponse
> xmlns:ns1="http://reproducer.sig.xml.wildfly.weand.github.com/">
> <return>hello test</return>
> </ns1:echoResponse>
> <Signature
> xmlns="http://www.w3.org/2000/09/xmldsig#">
> <SignedInfo>
> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="#Body">
> <Transforms>
> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform>
> </Transforms>
> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue></DigestValue>
> </Reference>
> </SignedInfo>
> <SignatureValue></SignatureValue>
> </Signature>
> </soap:Body>
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference object uri = #Body
> 18:03:42,888 DEBUG [org.apache.jcp.xml.dsig.internal.dom.DOMReference] (default task-1) Reference digesting completed
> {code}
> Again the digest with enveloped-signature transform algorithm works properly when downgrading saaj-impl to 1.3.x in WFLY18+.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months
[JBoss JIRA] (WFCORE-5088) User is able to specify credential-reference with only store name
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5088?page=com.atlassian.jira.plug... ]
Farah Juma moved WFLY-13756 to WFCORE-5088:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5088 (was: WFLY-13756)
Component/s: Security
(was: Security)
Affects Version/s: (was: 20.0.0.Final)
(was: 20.0.1.Final)
> User is able to specify credential-reference with only store name
> -----------------------------------------------------------------
>
> Key: WFCORE-5088
> URL: https://issues.redhat.com/browse/WFCORE-5088
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jan Stourac
> Assignee: Farah Juma
> Priority: Major
>
> It is possible to create a {{credential-reference}} to the credential store just with the name of credential store in question - without specifying {{alias}} (or {{clear-text}} in case of automatic addition of new record into the credential store, see doc [16.4.2. Automatic Updates of Credential Stores|https://docs.wildfly.org/20/WildFly_Elytron_Security.html#referenc...]). Actual configuration error is revealed when server is reloaded with following error message in server log (note that I can see this error in case of 'key-store' example but not in case of 'imap' example - see Reproduction steps for this issue):
> {code}
> 22:03:26,791 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("key-store" => "exampleKS")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.exampleKS" => "WFLYELY00004: Unable to start the service.
> Caused by: java.io.IOException: WFLYELY00910: Password cannot be resolved for key-store '/tmp/cred/wildfly-20.0.1.Final/standalone/configuration/example.keystore'"}}
> {code}
> This misconfiguration is not possible to do in {{Wildfly 19.1.0.Final}} as you are requested to specify {{alias}} attribute too.
> I suspect that change in behavior has been introduced thanks to this new feature https://issues.redhat.com/browse/WFLY-12218 (see the doc referenced above).
> Correct behavior is to require credential store name and:
> # 'alias'
> # or 'alias' and 'clear-text'
> # or 'clear-text' (alias will be generated automatically in this case)
> as described in the referenced documentation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 11 months