October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4597) Updates to Properties panel interaction and labeling

by Kyle Walker (Jira)

[ https://issues.jboss.org/browse/DROOLS-4597?page=com.atlassian.jira.plugi... ] Kyle Walker reassigned DROOLS-4597: ----------------------------------- Assignee: Michael Anstis (was: Eder Ignatowicz) > Updates to Properties panel interaction and labeling > ---------------------------------------------------- > > Key: DROOLS-4597 > URL: https://issues.jboss.org/browse/DROOLS-4597 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Kyle Walker > Assignee: Michael Anstis > Priority: Critical > Labels: Stunner > > Some changes required to make the property panel more easily found: > 1. Open the Properties panel by default when opening Stunner > 2. Change the name of the panel to "Properties" > 3. Change the tooltip text for the Properties panel to reflect the changes and add an action word: "Open Properties panel" > See Marvel here: https://marvelapp.com/j6e2ij4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2386) Support for encryption ciphers that require an initialization vector

by Bela Ban (Jira)

[ https://issues.jboss.org/browse/JGRP-2386?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2386: -------------------------------- Sorry for the late response, I'm just back from PTO, will look at this hopefully this week (am in BOS for the next 2 weeks)... > Support for encryption ciphers that require an initialization vector > -------------------------------------------------------------------- > > Key: JGRP-2386 > URL: https://issues.jboss.org/browse/JGRP-2386 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.5, 3.6.19 > Reporter: Nick Sawadsky > Assignee: Bela Ban > Priority: Minor > > By default, Encrypt sets sym_algorithm to "AES". As a result, the default cipher mode is used, which is ECB. ECB encrypts a given plaintext block to the same ciphertext every time, which can allow attackers to see [patterns in messages being exchanged|https://crypto.stackexchange.com/questions/20941/why-shouldnt-i...]. > Modes like CBC, that use a random initialization vector (IV) avoid this problem (assuming a different IV is used for each message). > It would be good to modify Encrypt to support ciphers that require an IV, such as AES/CBC/PKCS5Padding. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4696) Bump the Elytron subsystem version

by Farah Juma (Jira)

Farah Juma created WFCORE-4696: ---------------------------------- Summary: Bump the Elytron subsystem version Key: WFCORE-4696 URL: https://issues.jboss.org/browse/WFCORE-4696 Project: WildFly Core Issue Type: Task Components: Security Reporter: Farah Juma Assignee: Farah Juma Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12625) WildFly 19 release graphic

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12625?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12625: ----------------------------------------- Part of resolving this should be cloning it to WF 20. ;) > WildFly 19 release graphic > -------------------------- > > Key: WFLY-12625 > URL: https://issues.jboss.org/browse/WFLY-12625 > Project: WildFly > Issue Type: Task > Components: Documentation > Reporter: Brian Stansberry > Assignee: James Perkins > Priority: Blocker > Fix For: 19.0.0.Beta1 > > > Get a graphic for wildfly.org for the 19 release. > I put this as a Blocker for the beta, but it really blocks the Final. But might as well get it done in advance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12625) WildFly 19 release graphic

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12625: --------------------------------------- Summary: WildFly 19 release graphic Key: WFLY-12625 URL: https://issues.jboss.org/browse/WFLY-12625 Project: WildFly Issue Type: Task Components: Documentation Reporter: Brian Stansberry Assignee: James Perkins Fix For: 19.0.0.Beta1 Get a graphic for wildfly.org for the 19 release. I put this as a Blocker for the beta, but it really blocks the Final. But might as well get it done in advance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12567) Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12567?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12567: ------------------------------------ Fix Version/s: 19.0.0.Beta1 (was: 18.0.0.Final) This does not block 18.0.0.Final but as it's a downstream_dependency we need to be sure it does get in once the artifact is available. So I changed the Fix Version. > Upgrade PicketLink from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009 > -------------------------------------------------------------------------- > > Key: WFLY-12567 > URL: https://issues.jboss.org/browse/WFLY-12567 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ivo Studensky > Assignee: Ilia Vassilev > Priority: Blocker > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > > Branch: https://github.com/jbossas/redhat-picketlink/tree/2.5.5.SP -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12568) Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009-jbossorg-1

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12568?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12568: ------------------------------------ Summary: Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009-jbossorg-1 (was: Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009) > Upgrade PicketLink bindings from 2.5.5.SP12-redhat-00006 to 2.5.5.SP12-redhat-00009-jbossorg-1 > ---------------------------------------------------------------------------------------------- > > Key: WFLY-12568 > URL: https://issues.jboss.org/browse/WFLY-12568 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ivo Studensky > Assignee: Ilia Vassilev > Priority: Blocker > Labels: downstream_dependency > Fix For: 18.0.0.Final > > > Branch: https://github.com/jbossas/redhat-picketlink-bindings/tree/2.5.5.SP -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12613: ----------------------------------------- The only CI WildFly does with IBM JDK is JDK 8, so the fact it's not executed on IBM JDK11 doesn't bother me. So I think it's fine. > Exclude IBM J9 JVM from Byteman-based test cases > ------------------------------------------------ > > Key: WFLY-12613 > URL: https://issues.jboss.org/browse/WFLY-12613 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 18.0.0.Final > > > The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case. > There is a problem with running Byteman-based test cases against the IBM J9 Java runtime: > {noformat} > [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR! > java.lang.RuntimeException: Could not install byteman agent > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102 > at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66) > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91) > ... 28 more > {noformat} > > {noformat} > [nrla@localhost wildfly-git-repo]$ java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR2_20151019_2144_B272764 > JIT - tr.r14.java_20151006_102517.04 > GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS > J9CL - 20151019_272764) > JCL - 20151022_01 based on Oracle jdk8u65-b17 > {noformat} > Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12613) Exclude IBM J9 JVM from Byteman-based test cases

by Richard Achmatowicz (Jira)

[ https://issues.jboss.org/browse/WFLY-12613?page=com.atlassian.jira.plugin... ] Richard Achmatowicz edited comment on WFLY-12613 at 10/1/19 2:09 PM: --------------------------------------------------------------------- There is a bit of a problem here in getting the exclusion to work with the combination of two conditions above. Firstly, AFAICT, maven profiles don't permit using multiple activation conditions, so I can't easily set up a profile to exclude the test. Secondly, I can't use the condition: {noformat} Assume.assumeFalse(System.getProperty("java.version").startsWith("1.8") && System.getProperty("java.vendor").startsWith("IBM")); {noformat} within the test itself, as the agent gets loaded (and the exception gets raised) before the test executes. I can confirm this. Thirdly, Arquillian does not support the use of Assume in a @BeforeClass or @AfterClass method, which would be where I would want to call it. In other words, the issue https://issues.jboss.org/browse/WFLY-7741 still holds ( I tried it ...) Please let me know if I am missing an obvious way to get around this. What I can do is require that the test not execute against any IBM JVM, by setting up a profile to exclude that particular execution (ts.surefire.clustering.all-ejb-byteman). This would not affect the OpenJ9 test executions as they have a different Java vendor. [~brian.stansberry] [~luck3y] WDYT? was (Author: rachmato): There is a bit of a problem here in getting the exclusion to work with the combination of two conditions above. Firstly, AFAICT, maven profiles don't permit using multiple activation conditions, so I can't easily set up a profile to exclude the test. Secondly, I can't use the condition: {noformat} Assume.assumeFalse(System.getProperty("java.version").startsWith("1.8") && System.getProperty("java.vendor").startsWith("IBM")); {noformat} within the test itself, as the agent gets loaded (and the exception gets raised) before the test executes. I can confirm this. Thirdly, Arquillian does not support the use of Assume in a @BeforeClass or @AfterClass method, which would be where I would want to call it. In other words, the issue https://issues.jboss.org/browse/WFLY-7741 still holds ( I tried it ...) Please let me know if I am missing an obvious way to get around this. What I can do is require that the test not execute against any IBM JVM, by setting up a profile to exclude that particular execution (ts.surefire.clustering.all-ejb-byteman). This would not affect the OpenJ9 test executions as they have a different Java vendor. > Exclude IBM J9 JVM from Byteman-based test cases > ------------------------------------------------ > > Key: WFLY-12613 > URL: https://issues.jboss.org/browse/WFLY-12613 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Fix For: 18.0.0.Final > > > The test case org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase uses Byteman to check a condition for validating whether the test passes or fails. The component arquillian-extension-byteman is used to allow the use of Byteman annotations within the Arquillian test case. > There is a problem with running Byteman-based test cases against the IBM J9 Java runtime: > {noformat} > [ERROR] org.jboss.as.test.clustering.cluster.ejb.remote.byteman.LastNodeToLeaveRemoteEJBTestCase Time elapsed: 1.202 s <<< ERROR! > java.lang.RuntimeException: Could not install byteman agent > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:507) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:71) > at org.jboss.arquillian.junit.AdaptorManager.initializeAdaptor(AdaptorManager.java:23) > at org.jboss.arquillian.junit.AdaptorManagerWithNotifier.initializeAdaptor(AdaptorManagerWithNotifier.java:19) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:109) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) > Caused by: com.sun.tools.attach.AgentInitializationException: ATTACH_ERR AgentInitializationException102 > at ibm.tools.attach.J9VirtualMachine.loadAgent(J9VirtualMachine.java:66) > at org.jboss.arquillian.extension.byteman.impl.client.AgentInstaller.install(AgentInstaller.java:91) > ... 28 more > {noformat} > > {noformat} > [nrla@localhost wildfly-git-repo]$ java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR2_20151019_2144_B272764 > JIT - tr.r14.java_20151006_102517.04 > GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS > J9CL - 20151019_272764) > JCL - 20151022_01 based on Oracle jdk8u65-b17 > {noformat} > Until this JVM bug can be fixed, we need to exclude executions of this test against the IBM J9 JVM. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-221) jps can't see server process in Openshift

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-221?page=com.atlassian.jira.plugin.... ] Jean Francois Denise resolved WFWIP-221. ---------------------------------------- Resolution: Done > jps can't see server process in Openshift > ----------------------------------------- > > Key: WFWIP-221 > URL: https://issues.jboss.org/browse/WFWIP-221 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > > This is somewhat curious issue. > When pod of app image is deployed (server is started) and switch to terminal in Openshift GUI, doing `jps -l` does nothing although I can see in logs that server is up and I can find java process in /proc/*/cmdline (image has no `ps` utility). > This happens only in Openshift environment and it is a regression to what was working with latest published CD image. > Funnily, when I try to run the image in docker and start the server by /opt/eap/bin/openshift-launch.sh, then jps can see the java process. > {code:java} > # this works fine > docker run -it docker-registry.upshift.redhat.com/kwills/eap-cd-openshift-rhel8:18.0-EAP... sh > sh-4.4$ /opt/eap/bin/openshift-launch.sh & > sh-4.4$ jps -l > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019