[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Matěj Novotný commented on WFLY-11566:
--------------------------------------
After some digging, [~mkouba], [~tomekadamski] and I came up with the following...
The instance of [{{ValidatorFactory}} that WFLY uses|https://github.com/wildfly/wildfly/blob/master/bean-validation/src/m...] seems to be a CDI-enabled instance (a bean) that is provided somewhere else and retrieved via CDI [here|https://github.com/wildfly/wildfly/blob/master/weld/bean-validation/...].
We think that the bean is most likely provided via [Hibernate Validator CDI extension in their repository|https://github.com/hibernate/hibernate-validator/blob/master/c...] - this way you get fully configured Factory instance.
Now, what we need is to be able to configure this instance somehow, namely to pass in [BeanMetadataClassNormalizer|https://github.com/hibernate/hibernate-valida...] that will be able to unwrap EJB proxies.
So the theoretical options are:
* Configure the Factory once WFLY gets it
** Not sure this is possible, I suspect it will be immutable
* Provide a custom new bean that will replace this Factory (e.g. an enabled CDI alternative that will "override" the original bean), this new bean will be configured by WFLY
** This is hacky, but something that could work for starters, CDI bean annotated with {{@Alternative @Priority()}} will be used instead of the original bean assuming it has same type(s) and qualifier(s)
* Find a way to pass config options to Hibernate Validator so they are aware of it while booting and providing their own bean
** NOTE - you cannot do that via another CDI bean. Assuming HV is providing bean via extension, they won't be able to use other beans at that point, it is too early in the process.
I'd be nice to have some input/confirmation from HV team [~guillaume.smet] [~y.rodiere] on how the bean is provided and whether it can be configured afterwards?
> 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)
5 years
[JBoss JIRA] (ELY-1915) stronger credential store
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1915?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-1915:
---------------------------------------
A while back I think [~dmlloyd] suggested we could back the credential store in a similar way to how we back our filesystem realm, that could be something to consider - if we were to do that we could have complete control of how the entries are encrypted.
If we did that I would consider that we look at both symetric and asymetric encryption, one use case I think could be useful is: -
# A DBA creates a new account with password for a server.
# The DBA encrypts an entry in an agreed format using the public key of the server.
# The entry is imported into the server's credential store.
# The server loads the entry from the credential store using it's private key to decrypt.
I have seen cases where users use multiple credential stores so one team providing credentials can not see the credentials provided by another team.
Anyway that is a bit of a tangent but if we do look to increase the strength of the encryption I think reviewing the type of the encryption at the same time is worth considering.
> stronger credential store
> -------------------------
>
> Key: ELY-1915
> URL: https://issues.redhat.com/browse/ELY-1915
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: Credential Store
> Affects Versions: 1.6.1.Final
> Reporter: Hisanobu Okuda
> Priority: Major
>
> JCEKS which is used for credential store uses 3DES. Need more stronger credential store based on a stronger cryptography like AES256 or more.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-12886) WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
by Matěj Novotný (Jira)
[ https://issues.redhat.com/browse/WFLY-12886?page=com.atlassian.jira.plugi... ]
Matěj Novotný closed WFLY-12886.
--------------------------------
Resolution: Explained
> WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12886
> URL: https://issues.redhat.com/browse/WFLY-12886
> Project: WildFly
> Issue Type: Enhancement
> Components: CDI / Weld
> Affects Versions: 17.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Minor
>
> I get this info when starting wildfly server:
> {code:java}
> 01:33:09,168 INFO [org.jboss.weld.Bootstrap] WELD-000119: Not generating any bean definitions from com.utils.WebUtils because of underlying class loading error: Type java.net.http.HttpClient from [Module "deployment.myapp.war" from Service Module Loader] not found.
> {code}
> My WebUtils.class imports:
> {code:java}
> import java.net.URI;
> import java.net.http.HttpClient;
> import java.net.http.HttpRequest;
> import java.net.http.HttpResponse.BodyHandlers;
> {code}
> Should I include java se module by myself in wildfly to remove this log?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-12886) WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
by nimo stephan (Jira)
[ https://issues.redhat.com/browse/WFLY-12886?page=com.atlassian.jira.plugi... ]
nimo stephan edited comment on WFLY-12886 at 12/20/19 3:58 AM:
---------------------------------------------------------------
Thanks! With @Vetoed the log of WELD-000119 is not shown anymore. I think the issue can be closed as there is no bug.
was (Author: nimo22):
Thanks! With @Vetoed the log of WELD-000119 is not shown anymore. I think the issue can be closed.
> WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12886
> URL: https://issues.redhat.com/browse/WFLY-12886
> Project: WildFly
> Issue Type: Enhancement
> Components: CDI / Weld
> Affects Versions: 17.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Minor
>
> I get this info when starting wildfly server:
> {code:java}
> 01:33:09,168 INFO [org.jboss.weld.Bootstrap] WELD-000119: Not generating any bean definitions from com.utils.WebUtils because of underlying class loading error: Type java.net.http.HttpClient from [Module "deployment.myapp.war" from Service Module Loader] not found.
> {code}
> My WebUtils.class imports:
> {code:java}
> import java.net.URI;
> import java.net.http.HttpClient;
> import java.net.http.HttpRequest;
> import java.net.http.HttpResponse.BodyHandlers;
> {code}
> Should I include java se module by myself in wildfly to remove this log?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[JBoss JIRA] (WFLY-12886) WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
by nimo stephan (Jira)
[ https://issues.redhat.com/browse/WFLY-12886?page=com.atlassian.jira.plugi... ]
nimo stephan commented on WFLY-12886:
-------------------------------------
Thanks! With @Vetoed the log of WELD-000119 is not shown anymore. I think the issue can be closed.
> WELD-000119: Not generating any bean definitions from..class loading error: Type java.net.http.HttpClient
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12886
> URL: https://issues.redhat.com/browse/WFLY-12886
> Project: WildFly
> Issue Type: Enhancement
> Components: CDI / Weld
> Affects Versions: 17.0.1.Final
> Reporter: nimo stephan
> Assignee: Matěj Novotný
> Priority: Minor
>
> I get this info when starting wildfly server:
> {code:java}
> 01:33:09,168 INFO [org.jboss.weld.Bootstrap] WELD-000119: Not generating any bean definitions from com.utils.WebUtils because of underlying class loading error: Type java.net.http.HttpClient from [Module "deployment.myapp.war" from Service Module Loader] not found.
> {code}
> My WebUtils.class imports:
> {code:java}
> import java.net.URI;
> import java.net.http.HttpClient;
> import java.net.http.HttpRequest;
> import java.net.http.HttpResponse.BodyHandlers;
> {code}
> Should I include java se module by myself in wildfly to remove this log?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years