February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6459) JAX-RS 2.1 Support

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6459?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-6459: -------------------------------- Fix Version/s: 12.0.0.Alpha1 > JAX-RS 2.1 Support > ------------------ > > Key: WFLY-6459 > URL: https://issues.jboss.org/browse/WFLY-6459 > Project: WildFly > Issue Type: Sub-task > Components: REST > Reporter: David Lloyd > Assignee: Alessio Soldano > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3554) Append the content to the file with name tmp|file results to 'tmp\|file' being created

by Marek Marusic (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3554?page=com.atlassian.jira.plugi... ] Marek Marusic reassigned WFCORE-3554: ------------------------------------- Assignee: Marek Marusic (was: Jean-Francois Denise) > Append the content to the file with name tmp|file results to 'tmp\|file' being created > -------------------------------------------------------------------------------------- > > Key: WFCORE-3554 > URL: https://issues.jboss.org/browse/WFCORE-3554 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Katerina Novotna > Assignee: Marek Marusic > > *Description of problem:* > Append the content to the file with name tmp|file results to 'tmp\|file' being created. > *Actual results:* > {code} > [standalone@embedded /] version >> tmp\|file > The file created is named 'tmp\|file' > {code} > *Expected results:* > {code} > The file created is named 'tmp|file' > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7787) Upgrade RESTEasy to 3.1.0.Final

by Mário Braga (JIRA)

[ https://issues.jboss.org/browse/WFLY-7787?page=com.atlassian.jira.plugin.... ] Mário Braga commented on WFLY-7787: ----------------------------------- I just verify wildfly 11. RESTEasy is still on 3.0.24.Final. Did you guys find any issue and downgrade to 3.0.x? Or is it safe to manually upgrade and use wildfly with 3.1.x? Thanks ! > Upgrade RESTEasy to 3.1.0.Final > ------------------------------- > > Key: WFLY-7787 > URL: https://issues.jboss.org/browse/WFLY-7787 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 11.0.0.Alpha1 > > > Upgrade RESTEasy from 3.1.0.CR3 to 3.1.0.Final -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-6) React.js Prototype

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/SWSQE-6?page=com.atlassian.jira.plugin.sy... ] viet nguyen updated SWSQE-6: ---------------------------- Description: Github: https://github.com/Hawkular-QE/swsui-test Travis-ci: https://travis-ci.org/Hawkular-QE/swsui-test > React.js Prototype > ------------------ > > Key: SWSQE-6 > URL: https://issues.jboss.org/browse/SWSQE-6 > Project: Swift Sunshine QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: viet nguyen > > Github: https://github.com/Hawkular-QE/swsui-test > Travis-ci: https://travis-ci.org/Hawkular-QE/swsui-test -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9007) The bin/product.conf and the org.jboss.as.product:<xxx> module should come in via an FP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9007?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9007: ---------------------------------------- This is going to require more thought, as doing this via a FP means that users who neglect to add this not-obviously-useful FP will end up without this stuff. So this needs to be a package in a low-level FP, and probably quite a lot of the use for it should be rethought in the context of the new provisioning system. > The bin/product.conf and the org.jboss.as.product:<xxx> module should come in via an FP > --------------------------------------------------------------------------------------- > > Key: WFLY-9007 > URL: https://issues.jboss.org/browse/WFLY-9007 > Project: WildFly > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 12.0.0.Alpha1 > > > For WFLY-4692 we moved the "product" stuff out of [servlet-]feature-pack and into [servlet-]dist. But this means it doesn't end up in the skinny dist produced by the "[servlet-]build" module. Plus it makes the "dist" a kind of FP of its own. > The stuff in [servlet-]dist/src/distribution should be its own FP. That one *perhaps* depends on the related normal feature-pack. Then build and dist use the new FP in addition to or instead of the regular feature-pack. > So, the regular feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP. > Whether the new "product" FP depends on the regular feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist besides the official one. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3019: ------------------------------------------ This is going to require more thought, as doing this via a FP means that users who neglect to add this not-obviously-useful FP will end up without this stuff. So this needs to be a package in a low-level FP, and probably quite a lot of the use for it should be rethought in the context of the new provisioning system. > The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-3019 > URL: https://issues.jboss.org/browse/WFCORE-3019 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own. > The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack. > So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP. > Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-377) The management API should provide a command to restart only all servers that are in state 'reload-required'

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-377?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-377: ------------------------------------ Fix Version/s: (was: 4.0.0.Beta2) > The management API should provide a command to restart only all servers that are in state 'reload-required' > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-377 > URL: https://issues.jboss.org/browse/WFCORE-377 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Wolf-Dieter Fink > Labels: cli, domain, domain-mode, management > > After configuration changes via CLI batch it might be that different processes needs to be restarted. > It is possible to iterate over all servers and check it. > But I think it would be easier to have a command that restart all controllers and servers conditional to the 'relod required' state > - at domain level > - at host level > - at server level > command example : > :restart(ifRequired=true) > :reload(ifRequired=true) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3019: ------------------------------------- Fix Version/s: (was: 4.0.0.Beta2) > The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-3019 > URL: https://issues.jboss.org/browse/WFCORE-3019 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own. > The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack. > So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP. > Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-785) Improve capability related error messages

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-785: ------------------------------------ Fix Version/s: (was: 4.0.0.Beta2) > Improve capability related error messages > ----------------------------------------- > > Key: WFCORE-785 > URL: https://issues.jboss.org/browse/WFCORE-785 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > > When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example: > /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown." > This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message. > Likely solutions are: > 1) If CapabilityRegistryImpl has more context than is being used, look into using it. > 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.) > 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information. > I expect 3) is the likely solution. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2930) Support a socket-binding-group as a child of profile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2930?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2930: ------------------------------------- Fix Version/s: 5.0.0.Alpha1 (was: 4.0.0.Beta2) > Support a socket-binding-group as a child of profile > ---------------------------------------------------- > > Key: WFCORE-2930 > URL: https://issues.jboss.org/browse/WFCORE-2930 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Fix For: 5.0.0.Alpha1 > > > Allow a single socket-binding-group resource as a child of profile, such that resolution of bindings from the subsystems are limited to the s-b-g associated with the profile. > A server-group that uses such a profile cannot reference a socket-binding-group. And a server in that server-group cannot reference an s-b-g to override the one from the server-group/profile. > I'm not sure how the s-b-g resource will work. Perhaps the resource would go away under 'profile' with the bindings direct children of profile. The 'default-interface' attribute then becomes an attribute of profile. Or perhaps there will be an s-b-g resource, but with a fixed name that's the same as the profile. Currently I think the latter. > This will be necessary for resolution of config elements using the upcoming provisioning tool. The tool will not be able to do correct "feature" resolution using the complex rules we currently support. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 February 2018