July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.0.6

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated WFLY-4819: ------------------------------- Summary: Upgrade Apache CXF from 3.0.5 to 3.0.6 (was: Upgrade Apache CXF from 3.0.5 to 3.0.7) > Upgrade Apache CXF from 3.0.5 to 3.0.6 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.0.7 when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.0.7

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Tomas Hofman commented on WFLY-4819: ------------------------------------ Sorry for that, of course it's 3.0.6. > Upgrade Apache CXF from 3.0.5 to 3.0.7 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.0.7 when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.0.7

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-4819: --------------------------------------- Why are you saying that the fix for CXF-6469 is coming in CXF 3.0.7 when the fix is already committed and 3.0.6 still to be released? > Upgrade Apache CXF from 3.0.5 to 3.0.7 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.0.7 when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.0.7

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated WFLY-4819: ------------------------------- Summary: Upgrade Apache CXF from 3.0.5 to 3.0.7 (was: Upgrade Apache CXF from 3.0.5 to 3.0.6) Description: Upgrade to Apache CXF 3.0.7 when available. (was: Upgrade to Apache CXF 3.0.6 when available.) > Upgrade Apache CXF from 3.0.5 to 3.0.7 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.0.7 when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4819) Upgrade Apache CXF from 3.0.5 to 3.0.6

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4819?page=com.atlassian.jira.plugin.... ] Tomas Hofman commented on WFLY-4819: ------------------------------------ 3.0.7 will fix CXF-6469 > Upgrade Apache CXF from 3.0.5 to 3.0.6 > -------------------------------------- > > Key: WFLY-4819 > URL: https://issues.jboss.org/browse/WFLY-4819 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Reporter: Tomas Hofman > Assignee: Alessio Soldano > Fix For: 10.0.0.Beta1 > > > Upgrade to Apache CXF 3.0.6 when available. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4855) Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-4855?page=com.atlassian.jira.plugin.... ] Tomas Hofman updated WFLY-4855: ------------------------------- Description: Adding a test case for CXF-6469 - verifying the schema imports are rewritten in various situations. > Test case for CXF-6469 (schemaLocation in xsd import is not rewritten) > ---------------------------------------------------------------------- > > Key: WFLY-4855 > URL: https://issues.jboss.org/browse/WFLY-4855 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 10.0.0.Alpha4 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Adding a test case for CXF-6469 - verifying the schema imports are rewritten in various situations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4855) Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-4855: ---------------------------------- Summary: Test case for CXF-6469 (schemaLocation in xsd import is not rewritten) Key: WFLY-4855 URL: https://issues.jboss.org/browse/WFLY-4855 Project: WildFly Issue Type: Enhancement Components: Test Suite Affects Versions: 10.0.0.Alpha4 Reporter: Tomas Hofman Assignee: Tomas Hofman -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4731) Change default value for journal-type to NIO

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-4731?page=com.atlassian.jira.plugin.... ] Miroslav Novak updated WFLY-4731: --------------------------------- Security: (was: Red Hat Internal) > Change default value for journal-type to NIO > -------------------------------------------- > > Key: WFLY-4731 > URL: https://issues.jboss.org/browse/WFLY-4731 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Alpha2 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > > Attribute journal-type is not specified and defaults to ASYNCIO. This has a side effect that EAP 7.0.0.DR2 (with ActiveMQ) prints warning to log if AIO is not located (on Windows, Solaris, HP-UX). > For this reason EAP 6.4 has default value for journal-type=NIO. We should keep it for EAP 7 as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-788) Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-788?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-788: ----------------------------------------- The discard of the model isn't happening in this situation. https://github.com/wildfly/wildfly-core/pull/853 needs work. > Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-788 > URL: https://issues.jboss.org/browse/WFCORE-788 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. > The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-788) Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-788?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-788: --------------------------------- Description: This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. was: This seems to be somewhat of an edge case, but it does exist. In the reproduce instructions you'll see a {{disable}} followed by a {{remove}} composite operation fails if the {{allow-resource-service-restart=true}} is set. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is not added back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen which makes the first step of the operation happy as the capability still exists. > Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-788 > URL: https://issues.jboss.org/browse/WFCORE-788 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. > The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years

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 July 2015