September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4616) Layer for core security-realms and management layer update

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-4616?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-4616: ---------------------------------- Fix Version/s: 10.0.0.Beta4 > Layer for core security-realms and management layer update > ---------------------------------------------------------- > > Key: WFCORE-4616 > URL: https://issues.jboss.org/browse/WFCORE-4616 > Project: WildFly Core > Issue Type: Enhancement > Components: Build System > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > Fix For: 10.0.0.Beta4 > > > Such layer would be helpful to extend existing layers with ability to be secured using core security realms. In addition, the management layer should make use of it. secure-management being already secured using elytron. > So we should: > - define core-security-realms layer > - define legacy-management layer secured with security-realms -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3566) DMN:Detailed interactions for creating and managing DRDs

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3566?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3566: -------------------------------------- Sprint: 2019 Week 38-40 > DMN:Detailed interactions for creating and managing DRDs > -------------------------------------------------------- > > Key: DROOLS-3566 > URL: https://issues.jboss.org/browse/DROOLS-3566 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Elizabeth Clayton > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: contextual-menu.png > > > Canvas node actions related to grouping and assigning to DRDs. > As a user I want to easily select and group nodes on the canvas so that I can add them to a DRD or to create a new DRD. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK

by Ivan Straka (Jira)

[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ] Ivan Straka edited comment on WFLY-11218 at 9/3/19 10:44 AM: ------------------------------------------------------------- [~tomekadamski] test passes after using the property in mvn command. Thanks. was (Author: istraka): [~tomekadamski] test passes after using the property in mvn command. There is no need to add it for server. Thanks. > IIOP call does not work with transaction started on client side when run on IBM JDK > ----------------------------------------------------------------------------------- > > Key: WFLY-11218 > URL: https://issues.jboss.org/browse/WFLY-11218 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 14.0.0.Final, 15.0.0.Beta1 > Environment: IBM JDK 8 > Reporter: Ivan Straka > Assignee: Tomasz Adamski > Priority: Blocker > Labels: blocker-WF18 > > Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8. > Scenario (using CORBA): > # start transaction > # lookup > # IIOP call > # EJB perform a basic operation and return (no failure is expected) > IIOP call fails with following exception: > {code:java} > java.lang.NullPointerException: null > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394) > at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253) > at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139) > at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91) > at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408) > at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274) > at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132) > at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324) > at javax.naming.InitialContext.init(InitialContext.java:255) > at javax.naming.InitialContext.<init>(InitialContext.java:227) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126) > {code} > When transaction is not started on client side, IIOP call works smoothly. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11218) IIOP call does not work with transaction started on client side when run on IBM JDK

by Ivan Straka (Jira)

[ https://issues.jboss.org/browse/WFLY-11218?page=com.atlassian.jira.plugin... ] Ivan Straka commented on WFLY-11218: ------------------------------------ [~tomekadamski] test passes after using the property in mvn command. There is no need to add it for server. Thanks. > IIOP call does not work with transaction started on client side when run on IBM JDK > ----------------------------------------------------------------------------------- > > Key: WFLY-11218 > URL: https://issues.jboss.org/browse/WFLY-11218 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 14.0.0.Final, 15.0.0.Beta1 > Environment: IBM JDK 8 > Reporter: Ivan Straka > Assignee: Tomasz Adamski > Priority: Blocker > Labels: blocker-WF18 > > Issue is valid only for IBM JDK 8...scenario works on oracle jdk 8 and 11 and openjdk 8. > Scenario (using CORBA): > # start transaction > # lookup > # IIOP call > # EJB perform a basic operation and return (no failure is expected) > IIOP call fails with following exception: > {code:java} > java.lang.NullPointerException: null > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sentFullMessage(CorbaMessageMediatorImpl.java:429) > at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.sendCancelRequestIfFinalFragmentNotSent(CorbaMessageMediatorImpl.java:394) > at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.endRequest(CorbaClientRequestDispatcherImpl.java:895) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.releaseReply(CorbaClientDelegateImpl.java:167) > at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:253) > at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:139) > at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:91) > at com.sun.jndi.cosnaming.CNCtx.setOrbAndRootContext(CNCtx.java:408) > at com.sun.jndi.cosnaming.CNCtx.initOrbAndRootContext(CNCtx.java:274) > at com.sun.jndi.cosnaming.CNCtx.<init>(CNCtx.java:132) > at com.sun.jndi.cosnaming.CNCtxFactory.getInitialContext(CNCtxFactory.java:61) > at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:695) > at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:324) > at javax.naming.InitialContext.init(InitialContext.java:255) > at javax.naming.InitialContext.<init>(InitialContext.java:227) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:93) > at org.jboss.as.test.jbossts.client.utils.TxUtil.lookupIIOP(TxUtil.java:103) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.lookupCrashBeanOverIIOP(JMSCrashRecoveryTestCase.java:164) > at org.jboss.as.test.jbossts.crashrec.test.JMSCrashRecoveryTestCase.callCrashTest(JMSCrashRecoveryTestCase.java:126) > {code} > When transaction is not started on client side, IIOP call works smoothly. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1869) Upgrade jboss-modules to 1.9.1.Final

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1869?page=com.atlassian.jira.plugin.s... ] Farah Juma edited comment on ELY-1869 at 9/3/19 10:12 AM: ---------------------------------------------------------- This upgrade was incorporated in ELY-1870. was (Author: fjuma): This fix was incorporated in ELY-1870. > Upgrade jboss-modules to 1.9.1.Final > ------------------------------------ > > Key: ELY-1869 > URL: https://issues.jboss.org/browse/ELY-1869 > Project: WildFly Elytron > Issue Type: Component Upgrade > Reporter: Diana Vilkolakova > Priority: Major > Fix For: 1.10.0.Final > > > Upgrade jboss-modules to match the version in WildFly Core. There is no specific problem occuring now, but might be good to bring the version up to date and run tests with newer version. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1869) Upgrade jboss-modules to 1.9.1.Final

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1869?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1869. ----------------------------- Fix Version/s: 1.10.0.Final Resolution: Duplicate Issue This fix was incorporated in ELY-1870. > Upgrade jboss-modules to 1.9.1.Final > ------------------------------------ > > Key: ELY-1869 > URL: https://issues.jboss.org/browse/ELY-1869 > Project: WildFly Elytron > Issue Type: Component Upgrade > Reporter: Diana Vilkolakova > Priority: Major > Fix For: 1.10.0.Final > > > Upgrade jboss-modules to match the version in WildFly Core. There is no specific problem occuring now, but might be good to bring the version up to date and run tests with newer version. -- 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 * Singleton election policy and 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 > 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 > * Singleton election policy and 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 * 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 > * Singleton election policy and listener -- 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: public class MyCommand implements Command<Void, Void> { public Void execute(Void context) throws Exception { Thread.currentThread().getClassLoader().loadClass(this.getClass().getName()); } } 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 > 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)

Paul Ferraro created WFLY-12477: ----------------------------------- Summary: 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 -- 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