[JBoss JIRA] (JGRP-2338) RpcDispatcher: non-reflective method invocations
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2338?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2338.
----------------------------
Resolution: Done
> RpcDispatcher: non-reflective method invocations
> ------------------------------------------------
>
> Key: JGRP-2338
> URL: https://issues.jboss.org/browse/JGRP-2338
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.0
>
>
> Running a native image produced by the GraalVM AOT (ahead-of-time) compiler prohibits the use of Java Reflection.
> However, RpcDispatcher uses {{java.lang.reflect.Method}} to invoke remote method calls.
> h4. Goal
> Provide a mode (in {{MethodCall}}) which doesn't require a {{MethodLookup}} table but rather takes user-provided code (e.g. a lambda) to find and invoke the correct method.
> This could be done by introducing an additional mode in {{MethodCall}} based on {{ID}} which calls the (user-provided) lambda to invoke a method. The lambda would read the arguments and invoke the method based on the received ID, then return the result.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11956:
-----------------------------------------
[~mkouba] -- [~guillaume.smet] was having trouble accessing JIRA but posted this input in Zulip:
Guillaume Smet: the gist of the issue is - I think - that the rest endpoint has a getter name
Guillaume Smet: HV considers it is a property and tries to validate as it is validating the bean is properly configured
Guillaume Smet: just removing the get prefix should fix the issue if my assumption is right
[~jbaesner] ^^^ is a possible workaround.
> @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: Alessio Soldano
> 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)
7 years, 1 month
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Martin Kouba (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Martin Kouba commented on WFLY-11956:
-------------------------------------
I don't understand why any {{InjectionTarget}} method should trigger method-level validation? Or even call the method? Method-level validation should be performed when a method is invoked. Or am I missing something? [~guillaume.smet] do you have an idea?
> @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: Alessio Soldano
> 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)
7 years, 1 month
[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement
by Scott Marlow (Jira)
[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ]
Scott Marlow reassigned WFLY-11891:
-----------------------------------
Assignee: Scott Marlow (was: Gail Badner)
> Add tests that enable JPA entity class bytecode enhancement
> -----------------------------------------------------------
>
> Key: WFLY-11891
> URL: https://issues.jboss.org/browse/WFLY-11891
> Project: WildFly
> Issue Type: Enhancement
> Components: JPA / Hibernate
> Affects Versions: 16.0.0.Final
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Minor
> Attachments: bytebuddy.log, javassist.log
>
>
> Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]:
> {code}
> <property name="hibernate.enhancer.enableDirtyTracking" value="true"/>
> <property name="hibernate.enhancer.enableLazyInitialization" value="true"/>
> <property name="hibernate.enhancer.enableAssociationManagement" value="true"/>
> {code}
> Steps to reproduce:
> * Build WildFly
> * cd testsuite/integration/basic
> * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase
> * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase
> * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase
> * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase
> Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure).
> To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (DROOLS-3770) Fix generic type retrieval inside SetPropertyHeaderCommand
by Gabriele Cardosi (Jira)
[ https://issues.jboss.org/browse/DROOLS-3770?page=com.atlassian.jira.plugi... ]
Gabriele Cardosi closed DROOLS-3770.
------------------------------------
Resolution: Done
Fixed with other PR
> Fix generic type retrieval inside SetPropertyHeaderCommand
> ----------------------------------------------------------
>
> Key: DROOLS-3770
> URL: https://issues.jboss.org/browse/DROOLS-3770
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: ScenarioSimulation
> Attachments: dmn-map.dmn
>
>
> The property editing information for a given column (included the DOMELEmentFactory) are set inside SetPropertyHeaderColumn.
> If the property is a collection, its generic type is retrieved with informations from the context.
> Currently, this mechanism uses the "steps" stored inside "elements", that point to full path of the property (and a mapped entry must exists).
> This is broken for top-level collection because are mapped in a different way, so a compatible method for different situations must be implemented
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-11956:
--------------------------------------
I took a glance at this (as a CDI guy, with resteasy and validator and I am greenhorn so mind that please).
Looking at what jaxrs does, there is a wrapper for CDI's {{InjectionTarget}} - that's the {{JaxrsInjectionTarget}} Brian mentioned earlier.
Behind the scenes, it enriches the invocation of {{inject()}} that CDI performs with jaxrs property injection and finally with validation.
Since {{InjectionTarget}} also has {{postConstruct()}} method, the validation could theoretically be moved there - I did a dirty check with this and it worked for me (for the test application). Notably this works even if the class itself does not use any {{@PostConstruct}}, the method on {{InjectionTarget}} will be invoked all the same. Not a clue what else it can possibly break though ;-)
Nonetheless, none of the above explains why hibernate validator calls the method *twice* which it IMO shouldn't.
It does so from [these two subsequent lines|https://github.com/hibernate/hibernate-validator/blob/6.0.15.Final/...] - the if check and the following line both end up with a reflective method invocation. I suppose this could be done once and the result stored if it's needed for several separate validations?
> @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: Alessio Soldano
> 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)
7 years, 1 month