September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12424) WS-Security in combination with MTOM attachments

by Jan Blizňák (Jira)

[ https://issues.jboss.org/browse/WFLY-12424?page=com.atlassian.jira.plugin... ] Jan Blizňák commented on WFLY-12424: ------------------------------------ This is already incorporated by upgrade to CXF 3.3.3 WFLY-12087 > WS-Security in combination with MTOM attachments > ------------------------------------------------ > > Key: WFLY-12424 > URL: https://issues.jboss.org/browse/WFLY-12424 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Priority: Major > > Please ensure to pick up this commit[1] of Apache CXF in next EAP release > [1]https://github.com/apache/cxf/commit/6207b11203790fbe5ac4404b13d2292e30... > Thanks! -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12423) Upgrade Apache CXF from 3.2.9 to 3.2.10

by Jan Blizňák (Jira)

[ https://issues.jboss.org/browse/WFLY-12423?page=com.atlassian.jira.plugin... ] Jan Blizňák closed WFLY-12423. ------------------------------ Resolution: Out of Date With WFLY-12070 in place already moving CXF to 3.3.x this jira seams out of date > Upgrade Apache CXF from 3.2.9 to 3.2.10 > --------------------------------------- > > Key: WFLY-12423 > URL: https://issues.jboss.org/browse/WFLY-12423 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Services > Affects Versions: 17.0.1.Final > Reporter: Ingo Weiss > Assignee: Jim Ma > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12462: ----------------------------------- I couldn't reproduce it either, with the attached reproducer. There is no particular restriction on the naming of ejb bean interface and classes, and this is odd that renaming ejb bean classes should make such a difference. Do you see the same error when you start wildfly default profile (./standalone) instead of the full profile? Can try the latest WildFly snapshot or [18.0.0.Beta1 |https://wildfly.org/downloads/]? > Incompatible conflicting binding Exception and EJB naming > --------------------------------------------------------- > > Key: WFLY-12462 > URL: https://issues.jboss.org/browse/WFLY-12462 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, EJB > Affects Versions: 17.0.1.Final > Environment: MacOS High Sierra > Reporter: Alexey Usharovski > Assignee: Cheng Fang > Priority: Minor > Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip > > > Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final > {code:java} > @Stateless > public class UserServiceImpl implements UserServiceRemote { > @Override > public List<UserRepr> getAllUsers() { > return null; > } > } > @Remote > public interface UserServiceRemote { > List<UserRepr> getAllUsers(); > } > {code} > The exception is > {code} > Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote > source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"}, > "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ], > "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]", > "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] } > {code} > Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content? > I've tried to look through the web console but found nothing interesting. > Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12419) Upgrade Generic JMS RA 2.0.2.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12419?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFLY-12419. ------------------------------------- Fix Version/s: 18.0.0.Final Assignee: Jeff Mesnil (was: Emmanuel Hugonnet) Resolution: Duplicate Issue > Upgrade Generic JMS RA 2.0.2.Final > ---------------------------------- > > Key: WFLY-12419 > URL: https://issues.jboss.org/browse/WFLY-12419 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Affects Versions: 17.0.1.Final > Reporter: Ilia Vassilev > Assignee: Jeff Mesnil > Priority: Major > Fix For: 18.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12427) Missing io.smallrye.health dependency on org.jboss.logging

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12427?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12427: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/12572 (was: https://github.com/wildfly/wildfly/pull/12527) > Missing io.smallrye.health dependency on org.jboss.logging > ---------------------------------------------------------- > > Key: WFLY-12427 > URL: https://issues.jboss.org/browse/WFLY-12427 > Project: WildFly > Issue Type: Bug > Components: MP Health > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 18.0.0.Final > > > I happened to notice this in a server log of a CI job: > {code} > 16:03:53,351 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 2) WELD-000119: Not generating any bean definitions from io.smallrye.health.SmallRyeHealthReporter because of underlying class loading error: Type org.jboss.logging.Logger from [Module "io.smallrye.health" version 1.0.2 from local module loader @4909b8da (finder: local module finder @3a03464 (roots: C:\buildAgent\work\37b47ae8b9c60325\full\testsuite\integration\smoke\target\wildfly\modules,C:\buildAgent\work\37b47ae8b9c60325\full\testsuite\integration\smoke\target\wildfly\modules\system\layers\base,C:\buildAgent\work\37b47ae8b9c60325\full\testsuite\integration\smoke\target\modules))] not found. If this is unexpected, enable DEBUG logging to see the full error. > {code} > The io.smallrye:smallrye-health-2.0:1.0.2 pom shows a dependency on JBoss Logging but the module.xml for its module does not. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12514) Server reload race conditions in testsuite/integration/multinode

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12514?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12514: ------------------------------------ Description: The testsuite/integration/multinode suite includes two servers. Tests do various manipulations of those servers and use the ServerReload.reloadIfRequired utility to attempt to reload the servers if necessary. The problem is the behavior of the ServerReload.reloadIfRequired(ModelControllerClient) method is to use TestsuiteEnvironment to get the address/port of the server to connect to after the reload in order to poll waiting for completion of the reload. But that breaks down in multi-server environments as TestsuiteEnvironment is going to only provide the data for one of the servers, so ServerReload is not going to accurately wait for completion of reload for the other. ServerReload provides an overloaded reloadIfRequired method where a ManagementClient instead of a ModelControllerClient can be provided. If that is used then the correct address/port is taken from the ManagementClient. So that variant should be used wherever possible. was: The testsuite/integration/multinode suite includes two servers. Tests do various manipulations of those servers and use the ServerReload utility to attempt to reload the servers if necessary. The problem is the default behavior of most of the ServerReload utility methods is to use TestsuiteEnvironment to get the address/port of the server to connect to after the reload in order to poll waiting for completion of the reload. But that breaks down in multi-server environments as TestsuiteEnvironment is going to only provide the data for one of the servers, so ServerReload is not going to accurately wait for completion of reload for the other. ServerReload provides a method where the address/port to use for waiting can be provided. > Server reload race conditions in testsuite/integration/multinode > ---------------------------------------------------------------- > > Key: WFLY-12514 > URL: https://issues.jboss.org/browse/WFLY-12514 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > The testsuite/integration/multinode suite includes two servers. Tests do various manipulations of those servers and use the ServerReload.reloadIfRequired utility to attempt to reload the servers if necessary. > The problem is the behavior of the ServerReload.reloadIfRequired(ModelControllerClient) method is to use TestsuiteEnvironment to get the address/port of the server to connect to after the reload in order to poll waiting for completion of the reload. But that breaks down in multi-server environments as TestsuiteEnvironment is going to only provide the data for one of the servers, so ServerReload is not going to accurately wait for completion of reload for the other. > ServerReload provides an overloaded reloadIfRequired method where a ManagementClient instead of a ModelControllerClient can be provided. If that is used then the correct address/port is taken from the ManagementClient. So that variant should be used wherever possible. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12514) Server reload race conditions in testsuite/integration/multinode

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12514?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFLY-12514: --------------------------------------- Assignee: Brian Stansberry > Server reload race conditions in testsuite/integration/multinode > ---------------------------------------------------------------- > > Key: WFLY-12514 > URL: https://issues.jboss.org/browse/WFLY-12514 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > The testsuite/integration/multinode suite includes two servers. Tests do various manipulations of those servers and use the ServerReload utility to attempt to reload the servers if necessary. > The problem is the default behavior of most of the ServerReload utility methods is to use TestsuiteEnvironment to get the address/port of the server to connect to after the reload in order to poll waiting for completion of the reload. But that breaks down in multi-server environments as TestsuiteEnvironment is going to only provide the data for one of the servers, so ServerReload is not going to accurately wait for completion of reload for the other. > ServerReload provides a method where the address/port to use for waiting can be provided. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12514) Server reload race conditions in testsuite/integration/multinode

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-12514: --------------------------------------- Summary: Server reload race conditions in testsuite/integration/multinode Key: WFLY-12514 URL: https://issues.jboss.org/browse/WFLY-12514 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Brian Stansberry The testsuite/integration/multinode suite includes two servers. Tests do various manipulations of those servers and use the ServerReload utility to attempt to reload the servers if necessary. The problem is the default behavior of most of the ServerReload utility methods is to use TestsuiteEnvironment to get the address/port of the server to connect to after the reload in order to poll waiting for completion of the reload. But that breaks down in multi-server environments as TestsuiteEnvironment is going to only provide the data for one of the servers, so ServerReload is not going to accurately wait for completion of reload for the other. ServerReload provides a method where the address/port to use for waiting can be provided. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12505) Remove unnecessary module dependencies in clustering modules

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12505?page=com.atlassian.jira.plugin... ] Paul Ferraro updated WFLY-12505: -------------------------------- Summary: Remove unnecessary module dependencies in clustering modules (was: Ban transitive dependencies for clustering modules) > Remove unnecessary module dependencies in clustering modules > ------------------------------------------------------------ > > Key: WFLY-12505 > URL: https://issues.jboss.org/browse/WFLY-12505 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 18.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The purpose here is to help identify unnecessary modules dependencies in the corresponding module.xml files, as there should be a 1:1 relationship between pom dependencies and module dependencies, with the exception of dynamically loaded dependencies - most of which should be optional. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12433) Upgrade jboss-jaxrs-api_2.1_spec to 2.0.0.Final

by Ronald Sigal (Jira)

[ https://issues.jboss.org/browse/WFLY-12433?page=com.atlassian.jira.plugin... ] Ronald Sigal commented on WFLY-12433: ------------------------------------- There have been no changes to https://github.com/eclipse-ee4j/jaxrs-api branch EE4J_8 since [~asoldano]'s most recent tag on https://github.com/jboss/jboss-jakarta-jaxrs-api_spec, and I was about to add a Final tag, but I don't have permission: "Permission to jboss/jboss-jakarta-jaxrs-api_spec.git denied to ronsigal." I could fork it and tag my own version, if that's OK. > Upgrade jboss-jaxrs-api_2.1_spec to 2.0.0.Final > ----------------------------------------------- > > Key: WFLY-12433 > URL: https://issues.jboss.org/browse/WFLY-12433 > Project: WildFly > Issue Type: Sub-task > Components: REST > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Priority: Major > Fix For: 18.0.0.Beta1 > > > JBoss Jakarta JAX-RS API fork: > https://github.com/jboss/jboss-jakarta-jaxrs-api_spec/ -- 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