[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Guillaume Smet (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Guillaume Smet commented on WFLY-11956:
---------------------------------------
Well, as demonstrated in the attached log file, the two calls are from completely different paths. It is not a bug per se.
The first call comes from:
{code}
javax.persistence.Persistence$PersistenceUtilImpl.isLoaded(Persistence.java:154)
org.hibernate.validator.internal.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:52)
org.hibernate.validator.internal.engine.resolver.CachingJPATraversableResolverForSingleValidation.lambda$isReachable$0(CachingJPATraversableResolverForSingleValidation.java:43)
{code}
As you have a {{@Valid}} on the property, we have to check if the value is reachable from a JPA perspective. Unfortunately, we don't have a way to easily check if an object is a possible entity so right now, for each class, we ask Hibernate ORM if the value of the property is an initialized value or some sort of lazy proxy. I will try to ask Steve if he sees a better way to do that and if we could somehow determine if the object is an entity.
The second call is the validation itself, for which you obviously need the value.
As for adding an additional SPI, why not but I'm not a big fan of including it in a micro release so it will have to wait for 6.1.
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ELY-1764) Get all Provider implementations moved to their own module.
by Darran Lofthouse (Jira)
[ https://issues.jboss.org/browse/ELY-1764?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1764:
----------------------------------
Fix Version/s: 2.0.0.Alpha4
> Get all Provider implementations moved to their own module.
> -----------------------------------------------------------
>
> Key: ELY-1764
> URL: https://issues.jboss.org/browse/ELY-1764
> Project: WildFly Elytron
> Issue Type: Task
> Reporter: Darran Lofthouse
> Assignee: Diana Vilkolakova
> Priority: Blocker
> Fix For: 1.9.0.CR3, 2.0.0.Alpha4
>
>
> Generally it was the authentication client and it's XML parser that needed to be able to load all Elytron Providers so we hard coded Provider resolution.
> We have a couple of alternative options: -
> # Hard code the class names in the authentication client and attempt to load 'best efforts'
> # Load using ServiceLoader discovery but sort them into the correct position.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months