Develop Reference

Which version of the JAX-RS API is supported by TomEE 8.0? JAX-RS 2.0 or JAX-RS 2.1?

According to the TomEE Download Page, TomEE 8.0 implements the APIs of Java EE 8 and MicroProfile 2.0. Part of these specifications is the API JAX-RS 2.1.
Recently, however, I ran into ClassNotFoundExceptions when trying to use the the Jersey Testframework (Version 2.38), which also is based on JAX-RS 2.1. When I analyzed this problem, I found that Jersey introduced a dependency jakarta.ws.rs-api-2.1.6.jar, that contained different versions of the API classes than the ones from TomEE 8.0 (javaee-api-8.0-5.jar from org.apache.tomee:javaee-api:8.0-5). Furthermore, the source code from the latter library is commented with Apache Geronimo JAX-RS Spec 2.0. On the other hand, a javaee-api-8.0.jar from Oracle (javax:javaee-api:8.0) contains the same classes as the Jersey dependency.
So from this, it looks like TomEE is in fact based on JAX-RS 2.0. Can anybody shed a light on this discrepancy?

Incompatible versions of camel-activemq component and camel-http4 component

I have a Spring-boot Camel application that receives HTTP requests and has to put them on an ActiveMQ.
I am using Maven to handle my dependencies, but I have a problem with the Camel-ActiveMQ component.
When using camel I am trying to keep the versions of different components the same. So far version 2.24.2 was working fine until I wanted to add a route with an ActiveMQ endpoint. There is no Camel-ActiveMQ 2.24.2 version in the Maven repositories that I am looking in.
I can not find a version of the Camel-ActiveMQ artifact that matches my other camel-components.
Some links to the components that I am using:
- Camel-ActiveMQ
- Camel-HTTP4
- Camel-Spring-Boot-Starter
I have tried using mixed versions of Camel Components (e.g. 2.24.2 for all components but 3.0.0-RC1 for ActiveMQ). This causes class loading exceptions on runtime due to multiple versions of classes being available.
I have found a versions that exist for the rest of my components and Camel-ActiveMQ (3.0.0-M1) but this again gives classloading exceptions when running the applications
Where can I find compatible versions?

Reading further I found the following in the Camel-ActiveMQ documentation:
SPRING BOOT AUTO-CONFIGURATION
When using Spring Boot make sure to use the following Maven dependency to have support for auto configuration:
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-activemq-starter</artifactId>
<version>x.x.x</version>
<!-- use the same version as your Camel core version -->
</dependency>
There is no 2.24.2 version available, but running with 3.0.0-M1 seems to work. Seems that the Camel-Spring-Boot functionality is kinda new, and will force me to use a 3.x version of camel.

Use JAX-RS without being implementation specific

I have a service that I want to consume in a few projects in basically the same way. I'd like to simplify the process of sending and receiving data to and from these projects, so I would like to make a client jar that handles the process of packing and unpacking jaxrs responses/requests and include that in my other projects.
However, to use any jax-rs objects, I have to be dependent on a specific implementation of jax-rs. In my little client library I have to include jersey (or resteasy or cxf) to have access to any of the jax-rs imports. If I were to include this jar in any of my other projects, they'd be forced to use that rest implementation as well.
Is there a way to create a single project jar that utilizes jax-rs objects, that would use the jax-rs implementation of the consuming container instead of having many nearly identical client projects that just include a different jax-rs implementation?
Essentially, I want my project wars to include a jar that will handle packing and unpacking jax-rs rest objects that use whatever implementation of jax-rs the war project uses.

Classes from the javax.ws.rs.* package are portable and are expected to work across different JAX-RS implementations. Use the following dependency:
<dependency>
<groupId>javax.ws.rs</groupId>
<artifactId>javax.ws.rs-api</artifactId>
<version>2.1</version>
</dependency>
Classes from the following packages are implementation specific and you don't want to use them directly when you want your code to be portable across different implementations:
Jersey: org.glassfish.jersey.*
RESTEasy: org.jboss.resteasy.*
Apache CXF: org.apache.cxf.jaxrs.*
However such classes must be in the classpath during runtime.
The JAX-RS Client API was introduced in JAX-RS 2.0 and enhanced in JAX-RS 2.1 with reactive capabilities. Check the API documentation for details.
Prior JAX-RS 2.0, any client support was vendor specific and not portable. The proxy-based clients provided by most of the vendors are not portable either.
The JAX-RS Client API can be used as follows:
Client client = ClientBuilder.newClient();
Response response = client.target("http://example.org/hello").request("text/plain").get();
In the above code, a javax.ws.rs.client.Client instance will be created using the default javax.ws.rs.client.ClientBuilder implementation class provided by the JAX-RS implementation provider.
If you are interested, check the documentation for the Client implementations:
Jersey: org.glassfish.jersey.client.JerseyClient
RESTEasy: org.jboss.resteasy.client.jaxrs.ResteasyClient
Apache CXF: org.apache.cxf.jaxrs.client.spec.ClientImpl

Role based security for OSGi

I am searching for a security framework that allows role based security for OSGi services as well as CXF webservices.
Some time ago I already used spring security but as we now switched to blueprint it is not an option anymore as far as I understood. To configure the access rules I would like to mainly use the standard #RolesAllowed annotation. So what are my best starting points? I also thought about implementing this myself as a blueprint extension but I would prefer an existing solution.

I would suggest you go with Apache Shiro instead, http://shiro.apache.org/ .
It provides easy API's for authentication, authorization, cryptography, and session management. It can also be easily deployed inside a OSGI container. Some pros of Apache Shiro are listed here Apache Shiro vs Java EE native APIs

In the mean time I created a blueprint extension for authorization based on JAAS and Java EE annoations (#RolesAllowed, #PermitAll, #DenyAll). You can add the extension to any blueprint file. It will then scan all beans for these annoations and intercept calls if they are found. It uses an existing JAAS context to get the roles of the user.
So prerequisite for this is doing a JAAS login. I have also created a CXF JAASAuthentication feature that logs in a user based on basic auth or ws security username principal. The module works together with the Apache Karaf JAAS support. So all karaf users and roles apply.
I will create a tutorial to show how to use all of this once the aries blueprint release that includes the authorization module is out. In the mean time I would be happy if you try it out and report any problems you have.
Btw. another approach for karaf is the role based access control for OSGi services that is built into karaf 3+. It does not work with annotations but is also easy to use. See
http://coderthoughts.blogspot.de/2013/10/role-based-access-control-for-karaf.html

Java rest framework with programmable dispatcher?

I'm searching a java rest framework or JAX-RS implementation that allows me to configure the dispatcher at runtime through an API. In JAX-RS it is only possible to do the configuration with #Path and #HttpMethod annotations or by effectively building your own dispatcher in a sub-resource.
I'm searching for:
dispatcher.addResource("/my/{path}", Resource.class) or
dispatcher.addResource("/2nd/path", resourceHandlerFactory)

Unfortunately there is nothing in JAX-RS for dynamic resource specification as you've found. Apache Wink has another alternative to Restlet called DynamicResource http://incubator.apache.org/wink/1.1/html/5.1%20Registration%20and%20Configuration.html. I'd be quite interested in why you need dynamic resources as I had similar requirement.

Try Restlet. It provides runtime dispatch functionality through its Router class. See http://wiki.restlet.org/docs_2.1/13-restlet/27-restlet/326-restlet.html for an example.