Feedback on PR #895
by Alessio Soldano
Hi,
I forgot to explicitly ask about this few weeks ago...anyway, please see
https://github.com/resteasy/Resteasy/pull/895/files . The changes are
basically for detecting if the new Apache HTTP 4.3+ api are available;
if that's not the case, RESTEasy would automatically fallback to using
the old api.
What do you think?
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
10 years
Re: [resteasy-dev] RESTEasy providers tests refactoring
by Alessio Soldano
Hi Martin,
I'm cc-ing the public resteasy-dev list as this is something other
contributors might be interested in and/or have comments about.
Il 22/08/2016 15:33, Martin Stefanko ha scritto:
>
> I started moving test from individual providers into the testsuite and
> I would like to ask you for your opinion on a few things.
>
> 1. Would it be better if I'll do a separate commit / PR for each
> provider respectively or one huge commit?
As you feel is better
>
> 2. I started with jaxb, there are two packages that I am not really
> sure that are necessary in the testsuite [1].
Those might simply be leftovers from my initial efforts of removing
duplicated stuff in the testsuite. If you find test classes or resources
that are not used anywhere, please simply delete them.
>
> 3. I discussed with Ron problem with internationalization testing
> which is using <reuseForks>false</reuseForks>. I made a separate
> profile for i18n testing but it is taking far too long to execute. I
> am looking for some way to specify surefire configuration on more
> detailed level (test or category). Maybe it would be better to make an
> optional module for it.
Interesting topic. Generally speaking, in the long term I would like to
get rid of reuseForks=false anywhere it's possible (basically because
that can hide code side effects).
Is reuseForks strictly required for i18n testing? Can you briefly
explain why? how long is "too long" here?
Would having different profiles only for tests requiring
reuseForks=false be an option?
Cheers
Alessio
>
> Thank you.
>
> [1]
> https://github.com/resteasy/Resteasy/tree/master/providers/jaxb/src/test/...
> https://github.com/resteasy/Resteasy/tree/master/providers/jaxb/src/test/...
>
> Martin Stefanko
>
> Associate Software Engineer
> JBoss Sustaining Engineering Team
> Red Hat Czech s.r.o.
--
Alessio Soldano
Web Service Lead, JBoss
10 years
Re: [resteasy-dev] Are deprecated things going to be removed in 3.1.0.Final?
by Alessio Soldano
[CC-ing public dev list]
Yes, the plan is to remove deprecated stuff in 3.1.0.Final.
As for the tests relying on deprecated/removed things, I would expect
them to be rewritten to use new APIs, or dropped if they do not make
sense anymore.
Cheers
Alessio
Il 24/08/2016 10:48, Katerina Novotna ha scritto:
> Hi Alessio,
>
> On http://resteasy.jboss.org/ there is annoucement about 3.0.19.Final saying that after that new release will have deprecated some Resteasy 2 stuffs, like:
>
> * Resteasy 2 asynchronous invocation facility
> * Resteasy 2 client caching facility
> * Resteasy 2 client facility
> * Resteasy 2 interceptor facility
> * resteasy-hibernatevalidator-provider
>
> Are you still planning to do that? Asking because of there are tests using it ... just to know what to expect.
>
> Thanks,
> Katka
--
Alessio Soldano
Web Service Lead, JBoss
10 years
Testsuite reorganization - multiple target containers
by Alessio Soldano
Hi,
with the latest changes on master, it's now possible to have the new
integration testsuites run against different WildFly versions (till now
they've been using 10.0.0.Final).
The build supports option -Dserver.version=xyz which can be used to tell
it which version of WildFly to download.
Alternatively you could use -Dserver.home=/x/y/z to specify the path to
the container to be used instead of downloading anything (and that can
clearly be any version).
Before advertising this all, I'd like to:
1) get your feedback; in JBossWS we've always had something similar,
actually making use of established profiles (-PwidlflyXYZ) which is more
complex and rigid. Here I'd stay with a simple server.version property
that can be anything till we have a good reason for having better
control on the mechanism. WDYT?
2) make it clear that atm we only have clean testsuite runs with default
value (no server.version or server.version = 10.0.0.Final). Running
against 10.1.0.CR1 fails because of a wildfly creaper issue (we need a
release & upgrade of it), running against 9.0.2.Final results in a bunch
of failures and errors. Clearly, we should work on resolving all the
failures, I'd say at least when running against the latest 3 released
target containers. In the long term, we'd have 3 jobs on Jenkins/TC and
perhaps even 3 tasks performed by Travis for each PR.
So, for 2) any help is welcome. If you want to run current master
against WildFly 9.0.2.Final, the command to be used is:
mvn -Dserver.version=9.0.2.Final
-Dorg.jboss.resteasy.client.useOldHTTPClient=true install
The reason for the -Dorg.jboss.resteasy.client.useOldHTTPClient=true is
in the upgrade to the new Apache HTTP client api (not available on
9.0.2.Final and older containers). I do plan to try an automatic version
discovery mechanism in the next future so that we (and the final users)
do not have to bother about that.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
10 years
Fwd: resteasy-spring in integration tests
by Martin Stefanko
Forwarding to mailing list.
Hello Alessio,
--> can you provide a link to that discussion please?
I found out that it was a private communication. I'll find a way to pass it
to you.
--> Can you clarify this a bit? Did you check if resteasy's jboss-modules
module is properly replacing resteasy-spring the way it does with other
components?
yes, the resteasy-spring is not being properly replaced.
The directory "Resteasy/testsuite/integration-tests-spring/deployment/
target/test-server/wildfly-10.0.0.Final/modules/system/
layers/base/org/jboss/resteasy/resteasy-spring/main/bundled/resteasy-spring-jar"
contains the "resteasy-spring.jar" and "resteasy-spring-3.0.14.Final.jar".
I think the resteasy-spring.jar is used which does not contain the latest
version.
In WF "wildfly-11.0.0.Alpha1-SNAPSHOT/modules/system/layers/base/
org/jboss/resteasy/resteasy-spring/main/bundled/resteasy-spring-jar"
contains only the "resteasy-spring-3.0.19.Final.jar".
Martin Stefanko
Associate Software Engineer
JBoss Sustaining Engineering Team
Red Hat Czech s.r.o.
On Wed, Aug 10, 2016 at 10:04 AM, Alessio Soldano <asoldano(a)redhat.com>
wrote:
> Hi Martin,
>
> Il 05/08/2016 10:20, Martin Stefanko ha scritto:
>
>
> Hello all,
>
> For my issue [1], I changed the resteasy-spring module but this change is
> not reflected in the integration tests (integration-tests-spring/deployment).
> There was already a discussion similar to this topic on the mailing list
> about integration of the Spring in the project.
>
> can you provide a link to that discussion please?
>
>
> resteasy-spring is bundled in the server and it is not being replaced with
> the most recent version. I am adding links to the commit [2] and the build
> log [3]. With this we do not have any chance to change this module.
>
> Can you clarify this a bit? Did you check if resteasy's jboss-modules
> module is properly replacing resteasy-spring the way it does with other
> components?
>
> Cheers
> Alessio
>
>
>
> [1] https://issues.jboss.org/browse/RESTEASY-1287
> [2] https://github.com/xstefank/Resteasy/commit/1911ac0720bf
> 964698d8c64ed82345c09d18c80f
> [3] https://travis-ci.org/xstefank/Resteasy/builds/149760402
>
> Martin Stefanko
>
> Associate Software Engineer
> JBoss Sustaining Engineering Team
> Red Hat Czech s.r.o.
>
>
> _______________________________________________
> resteasy-dev mailing listresteasy-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>
>
> --
> Alessio Soldano
> Web Service Lead, JBoss
>
>
> _______________________________________________
> resteasy-dev mailing list
> resteasy-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>
10 years
Fwd: [Resteasy-developers] issue with restEasy client and jackson2 provider
by Marek Kopecky
Hi.
Mailing list resteasy-developers(a)lists.sourceforge.net was deprecated.
I'm forwarding this to actual mailing list (resteasy-dev(a)lists.jboss.org).
Marek
-------- Forwarded Message --------
Subject: [Resteasy-developers] issue with restEasy client and jackson2
provider
Date: Thu, 4 Aug 2016 17:39:26 +0000
From: Mario Rodriguez <marodriguez(a)llbean.com>
To: resteasy-developers(a)lists.sourceforge.net
<resteasy-developers(a)lists.sourceforge.net>
Hi, I have a Java REST webservice that connects to a Node.js REST
service via restEasy client. While I was using the old
org.codehaus.jackson.* version it was working fine, then I’m trying to
update to jackson2 provider but now I’m getting an error when the
restEasy client on my Java app is trying to post a message to the nodeJS
service.
Exception in thread "Thread-13" java.lang.NoSuchMethodErr
or:
com.fasterxml.jackson.databind.type.TypeFactory.constructType(Ljava/lang/refl
ect/Type;Ljava/lang/Class;)Lcom/fasterxml/jackson/databind/JavaType;
at com.fasterxml.jackson.module.jaxb.JaxbAnnotati
onIntrospector._fullSerializationType(JaxbAnnotationIntrospector.java:1474)
at com.fasterxml.jackson.module.jaxb.JaxbAnnotati
onIntrospector._findContentAdapter(JaxbAnnotationIntrospector.java:1410)
at com.fasterxml.jackson.module.jaxb.JaxbAnnotati
onIntrospector.findSerializationContentConverter(JaxbAnnotationIntrospector.java:
800)
at com.fasterxml.jackson.databind.introspect.Anno
tationIntrospectorPair.findSerializationContentConverter(AnnotationIntrospectorPa
ir.java:372)
at com.fasterxml.jackson.databind.ser.std.StdSeri
alizer.findConvertingContentSerializer(StdSerializer.java:417)
at com.fasterxml.jackson.databind.ser.std.AsArray
SerializerBase.createContextual(AsArraySerializerBase.java:198)
at com.fasterxml.jackson.databind.SerializerProvi
der.handlePrimaryContextualization(SerializerProvider.java:928)
at com.fasterxml.jackson.databind.SerializerProvi
der.findPrimaryPropertySerializer(SerializerProvider.java:626)
at com.fasterxml.jackson.databind.ser.impl.Proper
tySerializerMap.findAndAddPrimarySerializer(PropertySerializerMap.java:72)
at com.fasterxml.jackson.databind.ser.BeanPropert
yWriter._findAndAddDynamic(BeanPropertyWriter.java:834)
at com.fasterxml.jackson.databind.ser.BeanPropert
yWriter.serializeAsField(BeanPropertyWriter.java:650)
at com.fasterxml.jackson.databind.ser.std.BeanSer
ializerBase.serializeFields(BeanSerializerBase.java:678)
at com.fasterxml.jackson.databind.ser.BeanSeriali
zer.serialize(BeanSerializer.java:157)
at com.fasterxml.jackson.databind.ser.std.Collect
ionSerializer.serializeContents(CollectionSerializer.java:149)
at com.fasterxml.jackson.databind.ser.std.Collect
ionSerializer.serialize(CollectionSerializer.java:112)
at com.fasterxml.jackson.databind.ser.std.Collect
ionSerializer.serialize(CollectionSerializer.java:25)
at com.fasterxml.jackson.databind.ser.DefaultSeri
alizerProvider.serializeValue(DefaultSerializerProvider.java:253)
at com.fasterxml.jackson.databind.ObjectWriter$Pr
efetch.serialize(ObjectWriter.java:1425)
at com.fasterxml.jackson.databind.ObjectWriter.wr
iteValue(ObjectWriter.java:930)
at org.jboss.resteasy.plugins.providers.jackson.R
esteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:207)
at org.jboss.resteasy.core.interception.AbstractW
riterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
at org.jboss.resteasy.core.interception.AbstractW
riterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
at org.jboss.resteasy.plugins.interceptors.encodi
ng.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
at org.jboss.resteasy.core.interception.AbstractW
riterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
at org.jboss.resteasy.client.jaxrs.internal.Clien
tInvocation.writeRequestBody(ClientInvocation.java:370)
at org.jboss.resteasy.client.jaxrs.engines.Apache
HttpClient4Engine.writeRequestBodyToOutputStream(ApacheHttpClient4Engine.java:558
)
at org.jboss.resteasy.client.jaxrs.engines.Apache
HttpClient4Engine.buildEntity(ApacheHttpClient4Engine.java:524)
at org.jboss.resteasy.client.jaxrs.engines.Apache
HttpClient4Engine.loadHttpMethod(ApacheHttpClient4Engine.java:423)
at org.jboss.resteasy.client.jaxrs.engines.Apache
HttpClient4Engine.invoke(ApacheHttpClient4Engine.java:281)
at org.jboss.resteasy.client.jaxrs.internal.Clien
tInvocation.invoke(ClientInvocation.java:436)
at org.jboss.resteasy.client.jaxrs.internal.proxy
.ClientInvoker.invoke(ClientInvoker.java:102)
at org.jboss.resteasy.client.jaxrs.internal.proxy
.ClientProxy.invoke(ClientProxy.java:76)
at com.sun.proxy.$Proxy56.saveOrders(Unknown Sour
ce)
at com.llbean.order.history.extractor.writer.Serv
iceOrderWriter.writeOrders(ServiceOrderWriter.java:67)
at com.llbean.order.history.extractor.migration.W
orker.execute(Worker.java:29)
at com.llbean.order.history.extractor.migration.A
bstractExtractorTemplate.executeWorkers(AbstractExtractorTemplate.java:43)
at com.llbean.order.history.extractor.migration.A
bstractExtractorTemplate.extract(AbstractExtractorTemplate.java:31)
at com.llbean.order.history.extractor.rest.Initia
tionResource$1.run(InitiationResource.java:48)
at java.lang.Thread.run(Thread.java:745)
I found this page
http://stackoverflow.com/questions/21780208/resteasy-and-jackson-incompat...
making reference to an incompatibility on earlier versions of restEasy
and jackson2, however, I’m using Jackson 2.7 and restEasy 3.0.16.
Here is the gradle build settings:
// RestEasy (Server side JAX-RS implementation)
compile 'org.jboss.resteasy:resteasy-_jaxrs_:3.0.16.Final'
compile 'org.jboss.resteasy:resteasy-_guice_:3.0.16.Final'
compile
'org.jboss.resteasy:resteasy-_servlet_-initializer:3.0.16.Final'
compile 'org.jboss.resteasy:resteasy-jackson2-provider:3.0.16.Final'
// RESTEasy (JAX-RS client)
compile 'org.jboss.resteasy:resteasy-client:3.0.16.Final'
Any clue what I’m missing ?
*Mario Rodríguez *
Systems Analyst | Customer Technology Team | L.L.Bean Inc.
CR P: (506) 2201-0183 | US P: (207) 552-6677 ext. 40083
10 years, 1 month
feedback please [RESTEASY-1463] cleanup bld warnings generics
by Rebecca Searls
The resteasy code base generates 228+ compile time "unchecked" warnings related to generics usage.
I don't think our builds should be polluted with un-addressed warnings, because it makes it hard to
easily spot real build issues. I have cleaned up these warnings by code adjustments where possible
and the @SuppressWarnings annotation where code should not or can not be changed.
Please take a few minutes to review the 8 files (listed below) with code changes. It is helpful
to have other eyes confirm my changes will not break anything before I submit a pull requst
https://github.com/resteasy/Resteasy/compare/master...rsearls:resteasy-14...
The 228+ warnings are spread across 88 files. 79 of the 88 files have only a
@SuppressWarnings annotation added to them.
The first 8 files below have code changes to address the warnings.
The last file only has a test addition. It is related to the compiler warnings
only in that the processing of Character and char have the compiler warning.
It seemed like a good idea to add a test for these datatypes.
resteasy-jaxrs/src/main/java/org/jboss/resteasy/spi/metadata/ResourceBuilder.java
## Made inner class declarations more correct in generics stmt
providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/Content.java
providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/Entry.java
providers/resteasy-atom/src/main/java/org/jboss/resteasy/plugins/providers/atom/Text.java
resteasy-jaxrs/src/main/java/org/jboss/resteasy/specimpl/ResteasyHttpHeaders.java
resteasy-jaxrs/src/main/java/org/jboss/resteasy/util/HttpServletRequestDelegate.java
resteasy-jaxrs/src/main/java/org/jboss/resteasy/util/ParameterParser.java
testsuite/unit-tests/src/test/java/org/jboss/resteasy/test/util/UriBuilderTest.java
testsuite/unit-tests/src/test/java/org/jboss/resteasy/test/util/TypeConverterTest.java
## added test for Character and char types.
10 years, 1 month
RESTEasy 3.1.0.Beta1
by Alessio Soldano
Folks,
I've just tagged 3.1.0.Beta1 and released its artifacts to the nexus
maven repository.
This is a chance for starting playing with the new minor.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
10 years, 1 month
