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.
At the moment IDE bundles only JAX-RS 1.0 APIs and Jersey 1.x. That's not enough. For example 'REST Java Client' wizard needs to use JAX-RS 2.0 + Jersey 2.0 when it generates code into J2SE Project. On the other hand JAX-RS 1.0 and/or Jersey 1.x may be still needed for EE5/6 applications and therefore IDE should probably bundle all four libraries: JAX-RS 1 and 2; Jersey 1 and 2.
There is an analogous situation in the JSF area - we stopped bundling JSF 2.1 and are now only bundling JSF 2.2. Although one difference may be that with JSF, applications don't typically rely on the implementation-specific APIs (unlike in the case of JAX-RS/Jersey). BTW, is there a possibility to register Jersey manually? That would provide a satisfactory workaround.
> There is an analogous situation in the JSF area We could bundle just the latest versions. And use them even in Tomcat EE5/6 projects. And user could change them to lower versions manually if desirable. > BTW, is there a possibility to register Jersey manually? That would provide a > satisfactory workaround. Yes but for example 'REST Java Client' uses hardcoded library and it generates either Jersey 1.x or JAX-RS 2.0 code. So if user manually switches library to Jersey 2.0 they will have to also update the code.
Based on the discussion with Martin J we think this is too risky/big change for 7.3.1, and this should be waived for 7.3.1.
Petr, I had a look at the binaries which we should bundle and I found http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.glassfish.jersey.bundles%22%20AND%20a%3A%22jax-rs-ri%22 where jax-rs-ri 2.0-rc1 can be downloaded and it contains following files: lib/jersey-client-2.0-rc1.jar lib/jersey-common-2.0-rc1.jar lib/jersey-container-servlet-2.0-rc1.jar lib/jersey-container-servlet-core-2.0-rc1.jar lib/jersey-server-2.0-rc1.jar ext/asm-all-repackaged-2.1.78.jar ext/cglib-2.1.78.jar ext/guava-14.0.jar ext/hk2-api-2.1.78.jar ext/hk2-locator-2.1.78.jar ext/hk2-utils-2.1.78.jar ext/javax.annotation-api-1.2-b02.jar ext/javax.inject-1.jar ext/javax.inject-2.1.78.jar ext/javax.ws.rs-api-2.0-rc3.jar ext/osgi-resource-locator-1.0.1.jar ext/validation-api-1.1.0.CR3.jar Let's ignore for now that it is RC. We should update NetBeans module websvc.restlib which provides two libraries: * restapi - this one (named JAX-RS 2.0 API) would contain ext/javax.ws.rs-api-2.0-rc3.jar; current 1.1.1 version contains also JavaDoc jar but I would not worry about that - Java EE javadoc is already bundled somewhere else * swdp - this one (named Jersey 2.0) would contain all other jars, right? OR have we been selective in the past and excluded some jars? Can you arrange or confirm that licence/legal wise this is all OK and ready to go? I would prefer to update libraries now and start testing the IDE and later just replace RC version with final bits. What do you think guys?? Does it make sense? Thanks.
web-main#d77f62bbfde5 Martin, could you review my changes in Maven section of Ant Libraries? Thanks. One thing I removed compared to previous versions is Jersey Javadoc. I can re-add it if needed it but I did not want to to make library too big. I also created external/readme file which describes where the ZIP files came from.
I just realized that websvc.restlib exports public API and the API contains most of old Jersey APIs, ie. com.sun.jersey.api* . I do not know why it has this public API and who possibly using it or whether it was just a silly mistake. The problem is that Jersey 2.0 is incompatible and does not provide any of these APIs and have their own new APIs packages in org.glassfish.jersey*. I'm not pushing my changes to main trunk yet and asking: do we want to break compatibility here or not???
> do we want to break compatibility here or not??? I think we do want to break it (and increase module major version).
(In reply to comment #6) > I just realized that websvc.restlib exports public API and the API contains > most of old Jersey APIs, ie. com.sun.jersey.api* . I do not know why it has > this public API and who possibly using it or whether it was just a silly > mistake. From what I can see the same approach is also used in websvc.jaxws21api and websvc.jaxrpc16.
OK, I've increased the major module version and I found single reference in NetBeans codes based which was using old Jersey API (apisupport.restsample/rest-sample-application/rest-sample-module) and I fixed it (#fa9fc15ce9b) (although it will need to be retested). I just discovered some freaky exception which I was sure I caused by REST library upgrade - issue 229946 - but I just noticed that the exception was filed first before my changes! Great, that means I did not cause and I can push this fix. :-)
I filed also: * issue 230418 - "verify that apisupport.restsample/rest-sample-application/rest-sample-module still works" * issue 230417 - "Will not load class o.o.f.l.FrameworkFactory arbitrarily from one of ModuleCL@7b238834[org.netbeans.libs.osgi] and ModuleCL@6f07524[org.netbeans.modules.websvc.restlib]"
Integrated into 'main-golden', will be available in build *201305292301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/d77f62bbfde5 User: David Konecny <dkonecny@netbeans.org> Log: #229898 - bundle JAX-RS 2.0 and Jersey 2.0 libraries
Integrated into 'main-golden', will be available in build *201306181109* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/44fe781f061c User: Milan Kuchtiak <mkuchtiak@netbeans.org> Log: #229898, update Jersey library to be usable for non Jersey server
Integrated into 'main-silver', will be available in build *201307232300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e65ec384cd61 User: Milan Kuchtiak <mkuchtiak@netbeans.org> Log: #229898: remove jersey-media-multipart from Maven Jersey library
TS 73 RESTWebServices [edit]RESTful Web Services Specification Test suite: Jersey Configuration Does not specify what Web Service to create, for example Java EE or Java Web? 1. Create new web project with GlassFish server ADD: Installation of GlassFish Server is a prerequisite Create Web Project: File->New Project->Java Web->Web Application Accept all defaults, (Next->Next->Finish) 2. Open new file wizard and select Web Services|RESTful Web Services from Patterns Step 6 does not exist (Check Use Jersey specific features check box) Step 11 – no web.xml file is in the Configuration folder
Thank You for pointing at this inconsistence. Note, the wizard UI has changed a little for 7.4: For Jersey 2.0 (JavaEE 7), there is no Jersey configuration (web.xml) panel available in the wizard, so steps 6 and 11 are irrelevant. Also step 9 isn't actual, as REST support relies fully on JavaEE 7 API that is bundled with GlassFish server, so the step 9 could be removed as well. Stepan, could you please update the Test Suite.
(In reply to Milan Kuchtiak from comment #15) > ... > > Stepan, could you please update the Test Suite. I created a page with the TS modified to match 7.4 workflow at http://wiki.netbeans.org/TS_74_RESTWebServices Changing issue status back to fixed.