[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Ronald Sigal (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Ronald Sigal commented on WFLY-11566:
-------------------------------------
Hi everyone,
Sorry for the delay. Looking at the definitions of ElementType and ConstraintLocationKind, I see that they seem to be very similar, though not exactly the same.
The point of all of that code in SimpleViolationsContainer.compareConstraintViolation() was to verify that two ConstraintViolations were the same. I don't remember offhand why I had to do all of that field by field, but apparently I did. All I can say from the RESTEasy perspective is that if the two tests - getElementType() and getConstraintLocationKind() - are the same and interchangeable, then I don't think there is a problem.
-Ron
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFLY-13171) Validate requirement for modules previously exported by javax.ejb.api on JSF implementations
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13171:
-------------------------------------------
Summary: Validate requirement for modules previously exported by javax.ejb.api on JSF implementations
Key: WFLY-13171
URL: https://issues.redhat.com/browse/WFLY-13171
Project: WildFly
Issue Type: Sub-task
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Validate the need of these module dependencies in the following modules:
Modules:
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
Dependencies:
{code:java}
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
{code}
Additionally, remove javaee.api dependency and use only the required ones for the following test modules:
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
{code:java}
<module name="javaee.api"/>
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-5966?page=com.atlassian.jira.plugin... ]
Yeray Borges Santana updated WFLY-5966:
---------------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
-feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.redhat.com/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 18.0.0.Beta1, 18.0.0.Final
>
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> -feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml-
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
> jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-5966?page=com.atlassian.jira.plugin... ]
Yeray Borges Santana reopened WFLY-5966:
----------------------------------------
This issue was incorrectly set as fixed in 18.0.0.Final. There are still pending modules to review, so I am opening it again until all the modules are cleaned
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.redhat.com/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges Santana
> Priority: Major
> Fix For: 18.0.0.Beta1, 18.0.0.Final
>
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
> jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFWIP-309) MP Fault Tolerance - WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFWIP-309?page=com.atlassian.jira.plugin... ]
Radoslav Husar commented on WFWIP-309:
--------------------------------------
Thanks guys. Just to note, I have a fix and will update the PR with a fix later today.
> MP Fault Tolerance - WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-309
> URL: https://issues.redhat.com/browse/WFWIP-309
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP Fault Tolerance
> Reporter: Miroslav Novak
> Assignee: Radoslav Husar
> Priority: Blocker
>
> There is unexpected error log in following test scenario:
> - Deploy MP FT service with:
> {noformat}
> @Asynchronous
> @Bulkhead(value = 15, waitingTaskQueue = 15)
> @Timeout(value = 1000)
> @Fallback(fallbackMethod = "processFallback")
> public CompletionStage<MyConnection> bulkheadTimeout(boolean fail) throws InterruptedException {
> if (fail) {
> Thread.sleep(2000);
> }
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Hello from @Bulkhead @Timeout method";
> }
> });
> }
> private CompletionStage<MyConnection> processFallback(boolean fail) {
> return CompletableFuture.completedFuture(new MyConnection() {
> @Override
> public String getData() {
> return "Fallback Hello";
> }
> });
> }
> {noformat}
> - Send 10+ parallel requests with fail == true
> Expected result:
> All requests should go to fallback.
> Actual Result:
> This test is currently hitting issue WFWIP-308 however additionally there is error in server log:
> {code}
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) Exception in thread "pool-22-thread-4" Exception in thread "pool-22-thread-2" org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.ApplicationScoped
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:123)
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
> 16:55:41,374 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at org.eclipse.microprofile.metrics.MetricRegistry$Proxy$_$$_WeldClientProxy.getHistograms(Unknown Source)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramOf(MetricsCollectorFactory.java:105)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.histogramUpdate(MetricsCollectorFactory.java:86)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.metrics.MetricsCollectorFactory$MetricsCollectorImpl.bulkheadQueueLeft(MetricsCollectorFactory.java:125)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at io.smallrye.faulttolerance.core.bulkhead.CompletionStageBulkhead$CompletionStageBulkheadTask.run(CompletionStageBulkhead.java:78)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 16:55:41,375 ERROR [stderr] (pool-22-thread-2) at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFLY-13169) Enhance README of ejb-remote quickstart to be easier to setup the server
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-13169:
---------------------------------------
Summary: Enhance README of ejb-remote quickstart to be easier to setup the server
Key: WFLY-13169
URL: https://issues.redhat.com/browse/WFLY-13169
Project: WildFly
Issue Type: Enhancement
Components: Quickstarts
Affects Versions: 19.0.0.Beta2
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
The `ejb-remote` quickstart (https://github.com/wildfly/quickstart/tree/19.0.0.Beta2/ejb-remote) provides guidelines how to configure server and run ejb remote calls from client to server.
The text in README misses two points
* the server has to be setup with user/password credentials for the client may connect to it (otherwise the invocation failse). There is such information in the text but at the end of the guide and not at the place before the server is started (which is the correct location for it)
* there is not mentioned that's possible to run the client code without `mvn exec:exec` as the maven assembly plugin is configured in `pom.xml`. The text should contain a note how to run the assembly plugin and how then execute the client code.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (REMJMX-166) IllegalThreadStateException after idle jmx connection
by Shaun Appleton (Jira)
[ https://issues.redhat.com/browse/REMJMX-166?page=com.atlassian.jira.plugi... ]
Shaun Appleton updated REMJMX-166:
----------------------------------
Priority: Blocker (was: Major)
> IllegalThreadStateException after idle jmx connection
> -----------------------------------------------------
>
> Key: REMJMX-166
> URL: https://issues.redhat.com/browse/REMJMX-166
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Affects Versions: 3.0.2.Final, 3.0.3.Final
> Environment: org.jboss.remotingjmx:remoting-jmx:3.0.3.Final + java8
> Reporter: Märt Bakhoff
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> Start wildfly-17.0.1/bin/standalone.sh, then run this code snippet:
> {noformat}
> JMXServiceURL url = new JMXServiceURL("service:jmx:remote+http://127.0.0.1:9990");
> try (JMXConnector connector = new RemotingConnectorProvider().newJMXConnector(url, Collections.emptyMap())) {
> connector.connect();
> MBeanServerConnection beanServer = connector.getMBeanServerConnection();
> RuntimeMXBean bean = ManagementFactory.newPlatformMXBeanProxy(beanServer, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
> Thread.sleep(70_000);
> System.out.println("uptime: " + bean.getUptime());
> }
> {noformat}
> The following exception is always thrown:
> {noformat}
> Exception in thread "XNIO-1 task-12" java.lang.IllegalThreadStateException
> at java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867)
> at java.lang.Thread.init(Thread.java:405)
> at java.lang.Thread.init(Thread.java:349)
> at java.lang.Thread.<init>(Thread.java:599)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager$1.newThread(ClientExecutorManager.java:56)
> at java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:619)
> at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:932)
> at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378)
> at org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.execute(ClientExecutorManager.java:64)
> at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver.handleMessage(ClientCommon.java:118)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The cause is in org.jboss.remotingjmx.protocol.v2.ClientExecutorManager.<init>. It creates a thread pool with Executors.newCachedThreadPool that has the default keepAliveTime of 60s.
> The thread factory is using a daemon thread group REMOTING_JMX that will self-destruct when the cached thread is terminated.
> The same code works when using older org.jboss.remotingjmx:remoting-jmx:3.0.1.Final. The regression is likely caused by commit https://github.com/jbossas/remoting-jmx/commit/2d6ae6c26da43304b752fc48f1...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months