May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8432) Support socket-binding attribute "client-mapping" in messaging subsystem

by Bartosz Spyrko-Śmietanko (JIRA)

[ https://issues.jboss.org/browse/WFLY-8432?page=com.atlassian.jira.plugin.... ] Bartosz Spyrko-Śmietanko commented on WFLY-8432: ------------------------------------------------ Since ActiveMQ client currently isn't capable of picking a connection based on client's network, https://github.com/wildfly/wildfly/pull/10082 uses the first mapping available for the socket binding. source-network attribute and any further client mappings are ignored. > Support socket-binding attribute "client-mapping" in messaging subsystem > ------------------------------------------------------------------------ > > Key: WFLY-8432 > URL: https://issues.jboss.org/browse/WFLY-8432 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Jörg Bäsner > Assignee: Bartosz Spyrko-Śmietanko > > The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <http-connector>. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Jason Greene edited comment on WFCORE-2805 at 5/19/17 11:06 AM: ---------------------------------------------------------------- Theres a few more cases that need investigation: 1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535 2) Deployments can bundle their own version of a JAXP transformer impl (xalan, saxon, etc) - Three deployments A, B, and C . A and B bundle different implies, and C does not. Verify the expected impl is chosen correctly 3) Modules obtain a different JAXP impl via a dependency. - Create a custom module for a special JAXP transformer impl (xalan, saxon, etc) - Add a dependency on a module which defines a service - Verify the service gets the correct JAXP transformer impl 4) Investigate how we carry over the ability to set a container wide default JAXP impl - Currently a user can replace the transformer with any version they choose. We have special JAXP redirection facilities to ensure that any JAXP impl which they may choose becomes the new container default. This was necessary in the past because of limitation in the JAXP search logic, which relied on hierarchical searching, and if a cl search failed would fall back to the wrong hard coded class names, as opposed to a META-INF/services search against the JVM. was (Author: jason.greene): Theres a few more cases that need investigation: 1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535 2) Deployments can bundle their own version of a JAXP transformer impl (xalan, saxon, etc) - Three deployments A, B, and C . A and B bundle different implies, and C does not. Verify the expected impl is chosen correctly 3) Modules obtain a different JAXP impl via a dependency. - Create a custom module for a special JAXP transformer impl (xalan, saxon, etc) - Add a dependency on a module which defines a service - Verify the service gets the correct JAXP transformer impl 4) Investigate how we carry over the ability to set a container wide default JAXP impl - Currently a user can replace the transformer with any version they choose. We have special JAXP redirection facilities to ensure that any JAXP impl which they may choose becomes the new container default. This was necessary in the past because of limitation in the JAXP search logic, which relied on hierarchical searching, and if a cl search failed would fall back to the wrong hard coded class names, as opposed to a META-INF/services search against the JVM. > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2805) Use Xalan from JRE rather than our own fork

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2805?page=com.atlassian.jira.plugi... ] Jason Greene commented on WFCORE-2805: -------------------------------------- Theres a few more cases that need investigation: 1) Translet class loading is modular compatible - see https://issues.apache.org/jira/browse/XALANJ-2535 2) Deployments can bundle their own version of a JAXP transformer impl (xalan, saxon, etc) - Three deployments A, B, and C . A and B bundle different implies, and C does not. Verify the expected impl is chosen correctly 3) Modules obtain a different JAXP impl via a dependency. - Create a custom module for a special JAXP transformer impl (xalan, saxon, etc) - Add a dependency on a module which defines a service - Verify the service gets the correct JAXP transformer impl 4) Investigate how we carry over the ability to set a container wide default JAXP impl - Currently a user can replace the transformer with any version they choose. We have special JAXP redirection facilities to ensure that any JAXP impl which they may choose becomes the new container default. This was necessary in the past because of limitation in the JAXP search logic, which relied on hierarchical searching, and if a cl search failed would fall back to the wrong hard coded class names, as opposed to a META-INF/services search against the JVM. > Use Xalan from JRE rather than our own fork > ------------------------------------------- > > Key: WFCORE-2805 > URL: https://issues.jboss.org/browse/WFCORE-2805 > Project: WildFly Core > Issue Type: Task > Reporter: Peter Palaga > Assignee: Peter Palaga > > As proposed by [~wolfc] we want to check if we can get rid of maintaining our own fork of Xalan. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-100) Topology enhancements

by Hayk Hovsepyan (JIRA)

Hayk Hovsepyan created HAWKULARQE-100: ----------------------------------------- Summary: Topology enhancements Key: HAWKULARQE-100 URL: https://issues.jboss.org/browse/HAWKULARQE-100 Project: Hawkular QE Issue Type: Task Reporter: Hayk Hovsepyan Assignee: Michael Foley Priority: Minor Idea from May 2017 F2F meetings, topology is going to be enhanced to show more information and have more functionality. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8811) IronJacamar to 1.4.5 from 1.4.4

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8811?page=com.atlassian.jira.plugin.... ] Stefano Maestri reopened WFLY-8811: ----------------------------------- > IronJacamar to 1.4.5 from 1.4.4 > ------------------------------- > > Key: WFLY-8811 > URL: https://issues.jboss.org/browse/WFLY-8811 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Labels: KK-DR18 > > This is needed to adjust the SPI needed for the Elytron integration for the three JCA subsystems -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1569) Enrich DMN InputData node type information

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1569: -------------------------------------- Summary: Enrich DMN InputData node type information Key: DROOLS-1569 URL: https://issues.jboss.org/browse/DROOLS-1569 Project: Drools Issue Type: Enhancement Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Enrich DMN InputData node type information; for API consumption of evaluation of a Model, the end-user should know for each "input" the corresponding type information. Missing: * base DMN Type which may be derived in another DMN Type * allowed values information -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8811) IronJacamar to 1.4.5 from 1.4.4

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/WFLY-8811?page=com.atlassian.jira.plugin.... ] Stefano Maestri moved JBEAP-10734 to WFLY-8811: ----------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8811 (was: JBEAP-10734) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JCA (was: JCA) Target Release: (was: 7.1.0.GA) > IronJacamar to 1.4.5 from 1.4.4 > ------------------------------- > > Key: WFLY-8811 > URL: https://issues.jboss.org/browse/WFLY-8811 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Labels: KK-DR18 > > This is needed to adjust the SPI needed for the Elytron integration for the three JCA subsystems -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1350) Distributed statisics number varies among nodes (distributed workmanager

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1350?page=com.atlassian.jira.plugin... ] Stefano Maestri resolved JBJCA-1350. ------------------------------------ Resolution: Done > Distributed statisics number varies among nodes (distributed workmanager > ------------------------------------------------------------------------ > > Key: JBJCA-1350 > URL: https://issues.jboss.org/browse/JBJCA-1350 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.4.4 > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Fix For: 1.4.5 > > > Reproducing test in https://github.com/LittleJohnII/wildfly/tree/eap7-495 > {noformat} > # build WFLY first > cd testsuite/integration/basic > mvn clean test -Dtest='Dwm*TestCase' -Djboss.server.config.file.name=standalone-ha.xml -DtrimStackTrace=false -Darquillian.launch=distributed-group > {noformat} > All the cases contain checks for distributed statistics and in some cases, these show unexpected numbers (usually, at least one test method fails for each case). For example, scheduling two work instances would produce distributed stats =2 for node1 and =3 for node 2. > I already mentioned this to [~maeste], so this is mainly a tracker. > This is a minor hamper to test writing for EAP7-495, but doesn't block it (not severe enough) - if this isn't resolved before I create a PR for tests, I'll have to comment out the distributed statistics checks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2844) Move javax.json module to WildFly Core

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2844?page=com.atlassian.jira.plugi... ] Ken Wills reassigned WFCORE-2844: --------------------------------- Assignee: Ken Wills > Move javax.json module to WildFly Core > -------------------------------------- > > Key: WFCORE-2844 > URL: https://issues.jboss.org/browse/WFCORE-2844 > Project: WildFly Core > Issue Type: Task > Components: Modules > Reporter: Darran Lofthouse > Assignee: Ken Wills > Priority: Critical > Fix For: 3.0.0.Beta23 > > > The Elytron subsystem has been moved to WildFly Core, the Elytron audit logger makes use of JSON so this module is required (Currently marked as optional). > Once available the module dependency from the org.wildfly.security.elytron-private module should also not be marked as optional. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8810) org.jboss.as.clustering.controller.AttributeParsers.COLLECTION is redundant

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-8810: ---------------------------------- Summary: org.jboss.as.clustering.controller.AttributeParsers.COLLECTION is redundant Key: WFLY-8810 URL: https://issues.jboss.org/browse/WFLY-8810 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro org.jboss.as.clustering.controller.AttributeParsers.COLLECTION is currently used for 2 types of attributes: * Lists * Maps The list version is unnecessary, as the default parser for the associated attribute definition parses these value correctly. The only exception is to support aliases in version 1.0 of the XSD. The map version is very hacky, as it makes an assumption that the map value is available from the element text of the xml reader. We should use a separate parser for this type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 May 2017