September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12498) wildfly-clustering-web-* deps missing provided scope in galleon-pack pom.xml

by Jean Francois Denise (Jira)

Jean Francois Denise created WFLY-12498: ------------------------------------------- Summary: wildfly-clustering-web-* deps missing provided scope in galleon-pack pom.xml Key: WFLY-12498 URL: https://issues.jboss.org/browse/WFLY-12498 Project: WildFly Issue Type: Task Components: Build System Reporter: Jean Francois Denise Assignee: Jean Francois Denise -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4604) Intermittently failing RemotingSubsystemTestCase.testEndpointConfigurationViaSubsystemRoot

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFCORE-4604?page=com.atlassian.jira.plugi... ] Richard Opalka reassigned WFCORE-4604: -------------------------------------- Assignee: Richard Opalka (was: Flavia Rainone) > Intermittently failing RemotingSubsystemTestCase.testEndpointConfigurationViaSubsystemRoot > ------------------------------------------------------------------------------------------ > > Key: WFCORE-4604 > URL: https://issues.jboss.org/browse/WFCORE-4604 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Jeff Mesnil > Assignee: Richard Opalka > Priority: Major > > RemotingSubsystemTestCase.testEndpointConfigurationViaSubsystemRoot success rate is 95% (https://ci.wildfly.org/project.html?projectId=WildFlyCore&testNameId=4458...) -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3652) DMN popover - Enter to apply

by Sarah Rambacher (Jira)

[ https://issues.jboss.org/browse/DROOLS-3652?page=com.atlassian.jira.plugi... ] Sarah Rambacher commented on DROOLS-3652: ----------------------------------------- ESC should also be implemented to exit the popover. > DMN popover - Enter to apply > ----------------------------- > > Key: DROOLS-3652 > URL: https://issues.jboss.org/browse/DROOLS-3652 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Michael Anstis > Priority: Major > Labels: UX, drools-tools > Attachments: Screen Shot 2019-02-13 at 1.20.35 PM.png > > > When the user changes the field value (name in this example), it would be nice if hitting ENTER would apply the name, and take the focus highlight off. The other field is being applied dynamically, so the assumption is that this one is as well. > !Screen Shot 2019-02-13 at 1.20.35 PM.png|thumbnail! > p.s. this is the pop-over that needs to be updated to support Expression instead of Name. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6008) CommandDispatcher commands execute using wrong TCCL

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-6008?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6008: ------------------------------- Description: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } {noformat} currently throws a ClassNotFoundException. A command executed with the command dispatcher should be able to load application classes using the TCCL. In fact, the following application callbacks from the clustering API all use the wrong TCCL: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener was: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } {noformat} currently throws a ClassNotFoundException. A command executed with the command dispatcher should be able to load application classes using the TCCL. In fact, the following application callbacks from the clustering API all use the wrong TCCL: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener * Singleton election policy and listener > CommandDispatcher commands execute using wrong TCCL > --------------------------------------------------- > > Key: WFLY-6008 > URL: https://issues.jboss.org/browse/WFLY-6008 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.CR5 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A command containing the following code: > {noformat} > public class MyCommand implements Command<Void, Void> { > public Void execute(Void context) throws Exception { > Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); > } > } > {noformat} > currently throws a ClassNotFoundException. > A command executed with the command dispatcher should be able to load application classes using the TCCL. > In fact, the following application callbacks from the clustering API all use the wrong TCCL: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12477) CommandDispatcher commands cannot read application jndi namespace

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12477?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12477: -------------------------------- Description: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { new InitialContext().lookup("java:comp/env/existing-resource"); } } {noformat} currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command. A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace. In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener was: A command containing the following code: {noformat} public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { new InitialContext().lookup("java:comp/env/existing-resource"); } } {noformat} currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command. A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace. In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace: * CommandDispatcher command execution * CommandDispatcherFactory cluster membership listener * Cache topology membership listener * Registry listener * ServiceProviderRegistry listener * Singleton election policy and listener > CommandDispatcher commands cannot read application jndi namespace > ----------------------------------------------------------------- > > Key: WFLY-12477 > URL: https://issues.jboss.org/browse/WFLY-12477 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 17.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > A command containing the following code: > {noformat} > public class MyCommand implements Command<Void, Void> { > public Void execute(Void context) throws Exception { > new InitialContext().lookup("java:comp/env/existing-resource"); > } > } > {noformat} > currently throws a NameNotFoundException, even though the same JNDI lookup succeeds on the caller that invoked the command. > A command executed with the command dispatcher should be able to perform JNDI lookup from the local application namespace. > In fact, the following application callbacks from the clustering API are unable to read from the application's JNDI namespace: > * CommandDispatcher command execution > * CommandDispatcherFactory cluster membership listener > * Cache topology membership listener > * Registry listener > * ServiceProviderRegistry listener -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4505) Change Alpine with UBI image in Dockerfiles

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4505: ------------------------------------------ Summary: Change Alpine with UBI image in Dockerfiles Key: DROOLS-4505 URL: https://issues.jboss.org/browse/DROOLS-4505 Project: Drools Issue Type: Task Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4647) Upgrade WildFly Elytron to 1.10.1.Final

by Farah Juma (Jira)

Farah Juma created WFCORE-4647: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.10.1.Final Key: WFCORE-4647 URL: https://issues.jboss.org/browse/WFCORE-4647 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12304) Upgrade Apache Artemis from 2.9.0 to 2.10.0

by Clebert Suconic (Jira)

[ https://issues.jboss.org/browse/WFLY-12304?page=com.atlassian.jira.plugin... ] Clebert Suconic commented on WFLY-12304: ---------------------------------------- A Quick fix would be to add a Chain handler on the pipeline that would convert FileRegion into a Regular NettyBuf I am not sure how we could do a proper fix here. it's up to [~flavia.rainone] > Upgrade Apache Artemis from 2.9.0 to 2.10.0 > ------------------------------------------- > > Key: WFLY-12304 > URL: https://issues.jboss.org/browse/WFLY-12304 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Martin Stefanko > Assignee: Emmanuel Hugonnet > Priority: Blocker > Labels: blocker-WF18, downstream_dependency > > Upgrade Apache Artemis from 2.9.0.Final to 2.10.0.Final. > Due to HA issue with Apache Artemis 2.10.0 this may not be the final version upgrade -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1875) Release WildFly Elytron 1.10.1.Final

by Farah Juma (Jira)

Farah Juma created ELY-1875: ------------------------------- Summary: Release WildFly Elytron 1.10.1.Final Key: ELY-1875 URL: https://issues.jboss.org/browse/ELY-1875 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.10.1.CR1 -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1873) JaccDelegatingPolicy should allow non JACC modifications to pass through.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1873?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1873. ----------------------------- Resolution: Done > JaccDelegatingPolicy should allow non JACC modifications to pass through. > ------------------------------------------------------------------------- > > Key: ELY-1873 > URL: https://issues.jboss.org/browse/ELY-1873 > Project: WildFly Elytron > Issue Type: Bug > Components: EE > Affects Versions: 1.10.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.10.1.CR1 > > > Errors such as the following can be seen within the application server: - > {noformat} > Caused by: java.lang.SecurityException: ELY03018: Cannot add permissions to a read-only permission collection > at org.wildfly.security.authz.jacc.JaccDelegatingPolicy$1.add(JaccDelegatingPolicy.java:127) [wildfly-elytron-jacc-1.10.0.CR6.jar:1.10.0.CR6] > at sun.rmi.server.LoaderHandler.getLoaderAccessControlContext(LoaderHandler.java:1005) [rt.jar:1.8.0_222] > at sun.rmi.server.LoaderHandler.lookupLoader(LoaderHandler.java:881) [rt.jar:1.8.0_222] > at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:404) [rt.jar:1.8.0_222] > at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186) [rt.jar:1.8.0_222] > at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637) [rt.jar:1.8.0_222] > at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:219) [rt.jar:1.8.0_222] > at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:152) [rt.jar:1.8.0_222] > at com.sun.corba.se.impl.util.JDKBridge.loadClassM(JDKBridge.java:189) [rt.jar:1.8.0_222] > at com.sun.corba.se.impl.util.JDKBridge.loadClass(JDKBridge.java:89) [rt.jar:1.8.0_222] > at com.sun.corba.se.impl.javax.rmi.CORBA.Util.loadClass(Util.java:605) [rt.jar:1.8.0_222] > at javax.rmi.CORBA.Util.loadClass(Util.java:259) [rt.jar:1.8.0_222] > at com.sun.corba.se.impl.presentation.rmi.StubFactoryFactoryDynamicBase.createStubFactory(StubFactoryFactoryDynamicBase.java:64) [rt.jar:1.8.0_222] > at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.getStubFactoryImpl(DelegatingStubFactoryFactory.java:76) > at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.access$000(DelegatingStubFactoryFactory.java:41) > at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:58) > at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory$1.run(DelegatingStubFactoryFactory.java:55) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_222] > at org.wildfly.iiop.openjdk.rmi.DelegatingStubFactoryFactory.createStubFactory(DelegatingStubFactoryFactory.java:55) > at com.sun.corba.se.impl.util.Utility.loadStub(Utility.java:780) [rt.jar:1.8.0_222] > ... 11 more > {noformat} > In this scenario the permission was RuntimePermission("java.lang.RuntimePermission" "createClassLoader") so should be related to the ProtectionDomain of the class loader and not the JACC permission collection. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 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 September 2019