Forwarding to the list :-)
---------- Forwarded message ----------
From: Alessio Soldano <asoldano(a)redhat.com>
Date: Wed, Sep 27, 2017 at 10:24 PM
Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically
To: Christian Kaltepoth <christian(a)kaltepoth.de>
On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth <christian(a)kaltepoth.de
> sorry for the delayed response. I agree that if some SPI would allow to
> modify the builders, it should be done before the resource is registered in
> the resource factory. Do you think such a SPI would be useful for others?
Probably yes, but your scenario might even be enough to justify it.
I would be happy to contribute some code if it improves portability between
> RESTEasy and the MVC RI.
Sure, feel free to work on that and send a PR.
> Thanks for pointing me to the resteasy-cdi integration. I'll have a deeper
> look at it in the next days.
OK, good, I hope that can offer some idea for integrating.
Yeah, sorry, you guys are right, I had a lone `oc cluster` up on 8443
that I didn't account for, I only checked that my 8080 port was free.
Thanks and sorry for the noise.
On 22/03/18 17:52, Alessio Soldano wrote:
> Are you still having problems or managed to run the testsuite locally?
> On Tue, Mar 20, 2018 at 1:06 PM, Stephane Epardaud <stef(a)epardaud.fr
> <mailto:firstname.lastname@example.org>> wrote:
> Damn, that's pretty annoying because I don't know what could be
> the issue and most tests don't pass.
> Apache Maven 3.5.0
> Maven home: /usr/share/maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.13.0-31-generic", arch: "amd64",
> family: "unix"
> I'm running it with `mvn clean install`
> On 20/03/18 12:54, Alessio Soldano wrote:
>> Of course they run :-) Latest run on Travis CI against latest
>> commit passed 23hrs ago, btw.
>> How are you running the testsuite, which jdk and mvn version?
>> On Tue, Mar 20, 2018 at 11:39 AM, Stephane Epardaud
>> <stef(a)epardaud.fr <mailto:email@example.com>> wrote:
>> I get lots of test failures where the clients can't be
>> cleaned up because they're null:
>> at org.jboss.resteasy.test.resource.basic.WiderMappingTest.cleanup(WiderMappingTest.java:60)
>> Do tests run on master for you?
>> resteasy-dev mailing list
>> Alessio Soldano
>> Associate Manager
>> Red Hat
> resteasy-dev mailing list
> resteasy-dev(a)lists.jboss.org <mailto:firstname.lastname@example.org>
> Alessio Soldano
> Associate Manager
> Red Hat
I'm currently working on Ozark, which is the reference implementation for
JSR-371 (MVC 1.0). My current focus is to improve the integration between
Ozark and RESTEasy.
The MVC specification has some special requirements regarding validation.
Especially it requires that resource methods (called controller methods in
MVC) get executed even if validation errors were detected according to the
Bean Validation annotation places on resource properties and resource
method parameters. This is required so that the controller can handle these
errors, which most typically varies between pages.
To achieve this, Ozark currently implements a custom validation layer
without relying on the native JAX-RS validation which (by design) aborts
request processing as soon as validation errors are detected. This
basically works fine, but it currently forces users to manually disable the
native JAX-RS validation by annotating controllers with
@ValidateOnExecution(NONE). Of course this isn't very user friendly, so I'm
looking for ways to work around this.
So I'm looking for ways to disable the validation on a per request basis.
It is important to do this only for individual requests because this
behavior most only be applied if the request is processed by a MVC
controller. Regular JAX-RS resources must not be affected by this.
Of course I would love to find a way to make this work with current
RESTEasy versions. But I would also be happy to contribute code if you
think that some kind of SPI makes sense.
I get lots of test failures where the clients can't be cleaned up
because they're null:
Do tests run on master for you?