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.
This is short term solution for issue #196466 and #196127 . This bug is not about end functionality but current approach of REST library configuration . The algorithm which is used for checking library presence and its configuration is bad. The restlib_gfv3 library is hardcoded in the WebProjectRestSupport ( maven REST support should be also corrected ). This is the sort term solution which should be done ( by David's suggestion ): * GlassFishV3JaxRsStack to play its role correctly according to current design should handle properly different versions of GlassFish - it should based on server instance or server installation file structure return jars corresponding to server it represents, is. "asm, jersey-bundle, jettison, jsr311-api" for GF 3.0.1 and different jars for GF 3.1 * WebProjectRestSupport.getServerRestLibraryName() should be deleted * WebProjectRestSupport.addServerJerseyLibrary() should instead of calling getServerRestLibraryName do JaxRsStackProvider.getJaxRsStack(j2eePlatform).getWSTool(JaxRs.Tool.JAXRS).getLibraries() and use returned jar URLs to locale corresponding library in LibraryManager (the library should always be there, no??). In worst case it could fallback on IDE Jersey library or simply add jars returned by getWSTool(JaxRs.Tool.JAXRS).getLibraries() to project classpath.
changeset: 193137:7611400663d7
Integrated into 'main-golden', will be available in build *201105050000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7611400663d7 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#196469 - Correct Jersey library classpath usage and Web Beans tests.