JIRA - GitHub integration
by Alessio Soldano
Folks,
FYI the JIRA - GitHub integration is now properly set; so you can see
the commits for a given issue in it's jira page; see for instance:
https://issues.jboss.org/browse/RESTEASY-1361
The commits scan is ongoing, so it might take some time to have all
jiras/commits processed.
Cheers
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
8 years, 11 months
Resolving failing test, (arquillian/RESTEASY-903-WF8) recommendations wanted
by Rebecca Searls
I'm testing the Apache deprecation changes. Tests in /home/rsearls/j1/Resteasy/jaxrs/arquillian/RESTEASY-903-WF8
are failing. The testing version of wildfly is using target/wildfly/modules/system/layers/base/org/apache/httpcomponents/main/httpclient-4.2.1.jar
however our code changes required version httpclient-4.3.6.jar or higher, because class
org.apache.http.conn.HttpClientConnectionManager is in the later versions but not in 4.2.1.
jaxrs/jboss-modules does not provide a module for httpcomponents. jarxrs/pom.xml is using version 4.3.6
for building the components.
How would you recommend I resolve this?
8 years, 11 months
Remove top jaxrs dir in upstream
by Weinan Li
Hi Team,
I'm planning to remove 'jaxrs' top dir next week, which I guess will affect all the open PRs, wdyt?
--
Weinan Li / JBoss
8 years, 11 months
Magnolia
by Ron Sigal
I've just released an updated Magnolia page. The announcement on the
front page says
>
> Announcement:Resteasy 3.0.17.Final is available
> <http://resteasy.jboss.org/#>
>
> Release 3.0.17.Final is a maintenance release, with over 30 bug fixes
> plus a handful of enhancements. It is also the last in the 3.0.x
> series of releases, prior to a reorganization of the Resteasy codebase
> that will result in 3.1.0.Final. In 3.1.0.Final, there will some
> changes to look for:
>
> * Released jars will target Java 8.
> * Currently deprecated classes will be removed.
>
> Note that new development will take place on the master branch at
> github. There will be no further updates of the 3.0.x generation,
> other than possible critical bug fixes.
>
Let me know if you think I should change the wording anywhere.
I've also made a couple of corrections. For example, I noticed that
somewhere, probably the Build page, we still referenced Subversion. :-[
-Ron
--
My company's smarter than your company (unless you work for Red Hat)
8 years, 11 months
Proposed changes to org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine
by Rebecca Searls
I'm cleaning up the deprecated apache classes in resteasy-client.
I am currently working on org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.
One of four ApacheHttpClient4Engine constructor methods is using the deprecated class
org.apache.http.impl.client.DefaultHttpClient.
public ApacheHttpClient4Engine()
{
this.httpClient = new DefaultHttpClient();
this.createdHttpClient = true;
}
Apache's (version 4.3) requirement is to use a HttpClientBuilder to generated a new HttpClient
object. I can generated the HttpClient using Builder, HOWEVER doing so will mean a HttpHost
can never be assigned to the this.httpClient object.
I propose doing the following to address this.
1) Implement the no-arg constructor using the new Builder procedure.
Adding Javadoc comments of the restriction to this constructor.
2) Create a new constructor method that requires the input argument of HttpHost
and generates the HttpClient using the Builder procedure.
ApacheHttpClient4Engine methods getDefaultProxy setDefaultProxy are obsolete.
A HttpPort object can not longer be set or retrieved from HttpClient using
org.apache.http.params.HttpParams.
I don't find any Resteasy code calling getDefaultProxy. There is only 1 call
to setDefaultProxy which is easily addressed.
Since both methods are public, I propose the following changes.
1) Tag both methods deprecated.
2) getDefaultProxy() will always return NULL;
3) setDefaultProxy() will do nothing.
4) Add Javadoc to both methods.
Comments and suggestions on these proposals would be appreciated.
8 years, 11 months
@RolesAllowed and interfaces
by Robert Marcano
Greetings.
When using resource interfaces, the RolesAllowed annotation is only used
if it is found on the interface and not on the implementation class.
This took me by surprise because if you use the same annotation on an
EJB, it is only valid when it is on the bean implementation, not on the
remote or local interfaces. Probably there should be some consistency
here with other JEE specs.
I use interfaces in order to use a proxy based client from a remote JVM
that is migrating from EJB remoting. There is no need for the clients to
know which roles are allowed (or their names), so I want to avoid the
need to add RolesAllowed to the interfaces.
Before submitting a bug report or working on a patch. What is the best
approach here?
1- only use RolesAllowed when they are on the implementation class, It
will break existing code
2- implementation RolesAllowed override interface RolesAllowed
3- merge implementation RolesAllowed and interface RolesAllowed. Union
or intersection of both group of roles?
The same questions are valid for @PermitAll and @DenyAll
Note: please update the website mailing list link, I subscribed to the
sourceforge mailing list yesterday in order to send this email. Noticed
the migration notice because I checked today the web archive for the
lack of response.
8 years, 12 months
Release 3.0.17.Final next week
by Weinan Li
Hi Team,
I'll release 3.0.17.Final this week. Which will have these affections:
- I'll remove the top 'jaxrs' dir to make the directories flat
- I'll create Branch_3_0_x and the future development for 3.0.x will be merged into this branch
- The 'master' branch will have version '3.1.0-SNAPSHOT'
Please let me know if there are any problems.
- Weinan Li
8 years, 12 months
Add RESTEasy-WADL into Wildfly
by Weinan Li
I start to get resteasy-wadl related issues from community users, and I guess it's good time to add it into WildFly. I'll work on this.
- Weinan Li
8 years, 12 months
