This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After upgrade of IDE bundled Jersey library to 2.0 (and of JAX-RS 1.0 to 2.0) there are few problems in scenarios like this one: Web Application is set to EE6 and is using Tomcat 7.0 server Code generator (I think it was Cross Origin Sharing one) generates code for Jersey 1.x but JAX-RS 2.0 and Jersey 2 is actually added to classpath. Result is that generated code is not compilable.
It's the same when REST client (Jersey strategy) is generated in web application configured for GlassFish (e.g. 3.1.2.2)
Created attachment 135466 [details] fix You are right Milan. Here is the patch which fixes that part of the problem. The issue was that client generator should not try to add libraries to classpath - it must let server's JaxRsStackSupport do that. In your particular case the algorithm knows that: * jaxRs1Available = true * jersey1AvailableOnServer = true * and everything else is false And using server's JaxRsStackSupport allows server to add its Jersey jars to project classpath. Which will result into Jersey 1.x jars being added to classpath.
Assigning to Milan. See my previous comment Milan.
Created attachment 135467 [details] fix previous patch was a wrong one
Applied the patch you suggested David. Good idea. Note that for "non Jersey available" server (e.g. Tomcat) not only Jersey API is needed but full Jersey lib is required. http://hg.netbeans.org/web-main/rev/151e1a463b82 This fix fixes the Jersey Client wizard generated code - at least for Tomcat and older GlassFish Java EE versions. I think, Cross Origin Sharing wizard, is another issue. Actually, in Java EE6 scenario, the wizard doesn't allow to complete the task at all, and it should. Generally the Error message in the wizard is confusing: ! REST is not configured. Jersey based configuration is required. I reported another issue, specifically for Cross Origin Sharing wizard. See the bug 230908.
(In reply to comment #5) > Note that for "non Jersey available" server (e.g. Tomcat) not only Jersey API > is needed but full Jersey lib is required. Yes. What I believe is going to happen in Tomcat case is that both JAX-RS 2.0 and Jersey 2.0 libraries will be added to project classpath and both will be deployed.
> Yes. What I believe is going to happen in Tomcat case is that both JAX-RS 2.0 and Jersey 2.0 libraries will be added to project classpath and both will be deployed. Yes, But it's still not enough. Note that non-Jersey container (Tomcat) still needs to specify some Jersey ServletContainer class in deployment descriptor, or am I wrong ? Shouldn't we create another library (Jersey 2.0 Containers) containing com.sun.jersey.spi.container.servlet.ServletContainer class ?
The previous comment is related to Rest Service in Tomcat web application scenario: - create web application with Tomcat server - create new JAX-WS 2.0 Rest Service
We should test the Tomcat scenario and see. I think that JAX-RS 2.0 dynamically registers a REST servlet. But this dynamic registration may work only in the latest Servlet specifications. In older ones the web.xml entry may be needed. I do not remember details off hand and we should test it in any case.
I think non-compilable code is not the issue anymore - this was the problem of REST Client code, which was fixed. There are still some problems described in bug 230908 (Confusing message in Cross-Origin Resource Sharing Filter wizard) and bug 231640 (Issues with javax.ws.rs.Application subclass on non Jersey web server, e.g. Tomcat)