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.
Please add Jersey related jars into the WL server classpath for JEE6 profile. JSR311 is part of JEE6 spec and it should present in the servers classpath. This API in the com.sun.jersey.core_xx.jar of WL12 installation dir. Absence of the API in the classpath doesn't allow to use REST services in the project. So currently Jersey related jars are added on the REST configuration stage ( see issue #204573 ). But such projects classpath extending are not needed actually and could be a problem ( see already mentioned issue #204573 for NB bundled Jersey and issue #204816 ). So server with JEE6 profile should contains JSR311 in the classpath. It allows to avoid extending project classpath at all. Currently WL has a number of Jersey related jars : com.sun.jersey.core_xxx.jar it is main jar with JSR311 and number of implementation jars : com.sun.jersey.client_xxx com.sun.jersey.json_xxx com.sun.jersey.multipart_xxx com.sun.jersey.server_xxx org.codehaus.jackson.core.asl_xxx org.codehaus.jackson.jaxrs_xxx org.codehaus.jackson.mapper.asl_xxx org.codehaus.jackson.xc_xxx org.codehaus.jettison_xxx The latter jar files are not part of JEE6 spec and not required in the server classpath. But they still can be used by user in his application. The resulting application could be non-portable ( just WL specific ) but still can be useful. So the additional question is about these libraries. Probably they should be also included into the server classpath. Otherwise some different method could be considered for their enabling. Please note that putting them into the project (not server) classpath is not a good approach: server is bootstrapped with these jars and they are available in the runtime. So no need to include them into the deployment unit of jee project. Extending project classpath with these implementation specific libaries should be avoided ( issue #204816 ). As an option : we can skip Jersey implementation specific jars at all. User will be able to add them manually in its classpath.
com.sun.jersey.* fixed in web-main e3ce5e8a2416
*** Bug 206796 has been marked as a duplicate of this bug. ***
Filed https://bug.oraclecorp.com/pls/bug/webbug_print.showbug?c_rptno=13557884 for api.jar.
(In reply to comment #0) > As an option : we can skip Jersey implementation specific jars at all. User > will be able to add them manually in its classpath. As I'm not an ws expert I don't want to make that decision. With the change in comment 3 all jersey libraries are added to CP. Denis, please evaluate whether only api jars should be added (which one?) or all jars you mentioned should be added (including jackson). I think you know better what users prefer and what is "right". Thanks.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/e3ce5e8a2416 User: Petr Hejl <phejl@netbeans.org> Log: #206526 Add jersey libraries into the server classpath for WL with JEE6
(In reply to comment #4) > (In reply to comment #0) > > As an option : we can skip Jersey implementation specific jars at all. User > > will be able to add them manually in its classpath. > As I'm not an ws expert I don't want to make that decision. With the change in > comment 3 all jersey libraries are added to CP. > > Denis, please evaluate whether only api jars should be added (which one?) or > all jars you mentioned should be added (including jackson). I think you know > better what users prefer and what is "right". > > Thanks. com.sun.jersey.core_1.0.0.0_1-9.jar contains JAX-RS API . That API is a part of JEE6 spec and should be in the server classpath. All other classes are implementation classes and are not required ( from JEE6 spec ). The same situation is for GF3.1 actually : there is no separate API jar file but jersey-core.jar contains JAX-RS API along with some impl Jersey classes. But its Project UI node doesn't contain Jersey impl classes ( just JAR-RS API ). I don't know how it is done exactly. So the JAX-RS API classes are mandatory. On the other hand current approach is good enough : user could use some Jersey specific impl classes in his application. Such application could be non-portable because other JEE6 server could use different JAX-RS impl. So the decision about Jersey classes in the server classpath is not actually JAX-RS specific but mostly JEE server node design decision . I would prefer to keep current approach with Jersey classes in the server classpath. There was a request about some specific Jersey version some time ago ( but I'm not sure about exact usage case ) so probably it could be useful.
Thanks, looks like we can consider this issue fixed. If we need any additional changes related to the Jersey-specific non-portable jars on classpath, let's file a separate issue for that.
Integrated into 'releases', will be available in build *201202082200* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/39f6b82b02cd User: Petr Hejl <phejl@netbeans.org> Log: #206526 Add jersey libraries into the server classpath for WL with JEE6 (transplanted from e3ce5e8a2416c7ee9d747207e7e1c0a14de4c48f)
Verified in patched 7.1 build. com.sun.jersey.* jars available on classpath.