November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2026) source-port is wrongly offsetted when configured to 0, i.e. ephemeral port; results in "Permission denied (Bind failed)"

by Radoslav Husar (JIRA)

Radoslav Husar created WFCORE-2026: -------------------------------------- Summary: source-port is wrongly offsetted when configured to 0, i.e. ephemeral port; results in "Permission denied (Bind failed)" Key: WFCORE-2026 URL: https://issues.jboss.org/browse/WFCORE-2026 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 3.0.0.Alpha12 Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 3.0.0.Alpha13 There is a discrepancy between how 0 is handled. XSD {noformat} <xs:attribute name="source-port" type="xs:positiveInteger" use="optional"> {noformat} doesn't allow 0. MODEL {noformat} .setAllowExpression(true).setValidator(new IntRangeValidator(0, 65535, true, true)) {noformat} IMPLEMENTATION {noformat} public Integer getAbsoluteSourcePort() { if (this.sourcePort == null) { return null; } if (this.fixedSourcePort) { return this.sourcePort; } final int portOffset = this.socketBindingManager.getPortOffset(); return this.sourcePort + portOffset; } {noformat} doesn't treat 0 correctly, relies on null value. Example to reproduce e.g. with modcluster integration in core: {noformat} [standalone@localhost:9990 /] /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=proxy1:add(port=9090,host=127.0.0.1,source-port=0 { "outcome" => "success", "response-headers" => {"process-state" => "reload-required"} } [standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=proxies,value=[proxy1]) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] :reload { "outcome" => "success", "result" => undefined } {noformat} Starting server with {noformat} -Djboss.socket.binding.port-offset=100 {noformat} yields {noformat} 20:15:40,471 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000043: Failed to send INFO command to localhost/127.0.0.1:9090: Permission denied (Bind failed) {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-777) Revisit OTP callback usage & corresponding tests

by David Lloyd (JIRA)

David Lloyd created ELY-777: ------------------------------- Summary: Revisit OTP callback usage & corresponding tests Key: ELY-777 URL: https://issues.jboss.org/browse/ELY-777 Project: WildFly Elytron Issue Type: Task Components: Authentication Mechanisms Reporter: David Lloyd Some tests need to be disabled because the CredentialSource approach to client credential acquisition does not mesh with the way OTP sometimes needs to acquire a new password for a reset operation. We need to come up with a way to establish separate credential acquire strategies for authenticate versus reset. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7643) JAX-WS Webservice endpoint naming conflict between different virtual hosts

by István Tóth (JIRA)

István Tóth created WFLY-7643: --------------------------------- Summary: JAX-WS Webservice endpoint naming conflict between different virtual hosts Key: WFLY-7643 URL: https://issues.jboss.org/browse/WFLY-7643 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 10.1.0.Final, 11.0.0.Alpha1 Reporter: István Tóth Assignee: Alessio Soldano Attachments: Hello.java, jboss-web.xml, vhost-config-fragment.xml When deploying identically named POJO JAX-WS webservice endpoints into different virtualhosts with the same context, the ServiceName generated for the second deployment conflicts with the first one, and the deployment fails with org.jboss.msc.service.DuplicateServiceException. This can be worked around by defining the endpoint as a servlet, and giving globally distinct <servlet-name> s to them. I think the cause for the bug is that the ServiceName for the Endpoint is in a server instance namespace, but the the name is generated from only the endpoint name, and the context, which is not unique among deployments on different virtual hosts. Adding the virtual host to the generated name would make the service name unique, and should also allow routing to it based on virtualhost info by web server. In the test case the names could be for example *jboss.ws.endpoint.vhost="hosta".context=."helloservice.endpoint.Hello"* and *jboss.ws.endpoint.vhost="hostb".context=."helloservice.endpoint.Hello"* . -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-625) Include the client schema in the jar

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-625?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-625: ------------------------------------ Assignee: Darran Lofthouse > Include the client schema in the jar > ------------------------------------ > > Key: ELY-625 > URL: https://issues.jboss.org/browse/ELY-625 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4163) Support infinispan batch job repository

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-4163?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-4163: ------------------------------------- Nothing at this point. The repository does exist in JBeret, but we need to look at how to integrate it with WildFly. > Support infinispan batch job repository > --------------------------------------- > > Key: WFLY-4163 > URL: https://issues.jboss.org/browse/WFLY-4163 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Affects Versions: 9.0.0.Alpha1 > Reporter: Cheng Fang > Assignee: James Perkins > > Infinispan / JDG batch job repository is expected to be in the upcoming JBeret milestone release. WildFly batch subsystem will need to update the subsystem configuration to support the same, including updating batch subsystem schema. > WFLY-3139 (Add MongoDB support for a batch repository) involves similar changes. > In JBeret SE distrobution, those configurations are specified in jberet.properties file. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1365) directory of images for drools-docs is not where it should be

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1365?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer reassigned DROOLS-1365: ---------------------------------------------- Assignee: Geoffrey De Smet (was: Michael Biarnes Kiefer) > directory of images for drools-docs is not where it should be > ------------------------------------------------------------- > > Key: DROOLS-1365 > URL: https://issues.jboss.org/browse/DROOLS-1365 > Project: Drools > Issue Type: Bug > Components: docs > Affects Versions: 6.5.0.Final > Reporter: Michael Biarnes Kiefer > Assignee: Geoffrey De Smet > > I see that the images 1.png, 2.png and 3.png are not anymore available under: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... (where they normally are supposed to be) > I saw on filemgmt.jboss.org, that these images are now in: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... > Maybe the URL si not constructed good, so "community/docbook" is missing? > What to do here? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1365) directory of images for drools-docs is not where it should be

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1365?page=com.atlassian.jira.plugi... ] Michael Biarnes Kiefer commented on DROOLS-1365: ------------------------------------------------ @Geoffrey: I saw that going back to 6.2.0.Final there is the same issue. This changes with 6.1.0.Final. Here the URL of images is the right one: http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/... not http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/... The big difference is between 6.1.0.Final and 6.2.0.Final. Looking at the effective poms: 6.1.0.Final..: maven-jdocbook-style-plugin: unavailable pressgang-xslt-ns: 2.0.2 maven-jdocbook-plugin: 2.3.7 and 2.3.8 6.2.0.Final..: maven-jdocbook-style-plugin: unavailable pressgang-xslt-ns: 3.1.2 maven-jdocbook-plugin: 2.3.9 All in all it seems that pressgang-xslt-ns was a major upgrade: from 2.0.2 to 3.1.2 - maybe this is the culprit? > directory of images for drools-docs is not where it should be > ------------------------------------------------------------- > > Key: DROOLS-1365 > URL: https://issues.jboss.org/browse/DROOLS-1365 > Project: Drools > Issue Type: Bug > Components: docs > Affects Versions: 6.5.0.Final > Reporter: Michael Biarnes Kiefer > Assignee: Michael Biarnes Kiefer > > I see that the images 1.png, 2.png and 3.png are not anymore available under: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... (where they normally are supposed to be) > I saw on filemgmt.jboss.org, that these images are now in: > https://docs.jboss.org/drools/release/6.5.0.Final/drools-docs/html/images... > Maybe the URL si not constructed good, so "community/docbook" is missing? > What to do here? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-776: --------------------------------- Fix Version/s: 1.1.0.Beta15 > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-776: --------------------------------- Priority: Critical (was: Major) > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-776: -------------------------------------- Marking as Critical as hard to remove later on. > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 7 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 November 2016