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.
Created attachment 112726 [details] server output I can't run Java Web project (I've tried both Java EE 6 Web and 5) that implements basic REST services on WebLogic 12.1.1 (works well with GlassFish 3.1.1). Steps to reproduce: - follow steps in TS at http://wiki.netbeans.org/TS_70_JavaEE_Sanity for Ant project - in section "Configure, Build and deploy the Web Service Endpoint" you should be able to run the project. But I can't run it, it ends with "Deployment failed. The message was: :com.sun.jersey.spi.inject.Errors.ErrorMessagesException:null". The server log from output window is attached. Server: WebLogic 12.1.1 Product Version: NetBeans IDE Dev (Build 201111010600) Java: 1.7.0_01; Java HotSpot(TM) Client VM 21.1-b02 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb)
WL 12 is not yet publicly available right ? I need to check it after I get WL 12 but I have questions from what I see right now : 1) Jersey 1.8 libraries are used for web project as I see from log . Did you chose them specifically in the REST configuration dialog or it is by default ? Jersey server bundled libraries should be used by default. So the issue actually is : unable to recognize Jersey bundled libraries for WL. 2) It should works even with Jersey NB bundled libraries . This is separate issue and this is not NB issue. This is a bug in runtime : Jersey 1.8 or most likely WL.
I think it's not out yet. The selected Jersey was server-bundled version. I'll try it later with IDE bundled to see if there will be any difference
(In reply to comment #1) > WL 12 is not yet publicly available right ? > > I need to check it after I get WL 12 but I have questions from what I see > right now : > 1) Jersey 1.8 libraries are used for web project as I see from log . > Did you chose them specifically in the REST configuration dialog or it is > by default ? > Jersey server bundled libraries should be used by default. > So the issue actually is : unable to recognize Jersey bundled libraries for WL. I've realized that this is the issue actually. There is the option to use server bundled Jersey library ( which is used by default ) but WL JaxRs stack plugin is unable to find those libraries. So the problem is : JaxRsStackSupportImpl has a method extendsJerseyProjectClasspath() which did a search in all available server libraries for WL . It uses getServerJerseyLibraries method to get libraries: WLServerLibraryManager manager = new WLServerLibraryManager(platformImpl.getDeploymentManager()); Collection<ServerLibrary> libraries = new LinkedList<ServerLibrary>(); libraries.addAll(findJerseyLibraries(manager.getDeployableLibraries())); libraries.addAll(findJerseyLibraries(manager.getDeployedLibraries())); return libraries; This code works perfectly for WL version other than 12. "libraries" is empty for WL 12. So this is the issue of WL plugin. > 2) It should works even with Jersey NB bundled libraries . > This is separate issue and this is not NB issue. > This is a bug in runtime : Jersey 1.8 or most likely WL. This is the second issue as I already said. NB bundled Jersey 1.8 libraries are used as result of server bundled libraries absence. WL should work with this Jersey version but it doesn't. So this is the WL 12 runtime issue.
(In reply to comment #3) > (In reply to comment #1) > > WL 12 is not yet publicly available right ? > > > > I need to check it after I get WL 12 but I have questions from what I see > > right now : > > 1) Jersey 1.8 libraries are used for web project as I see from log . > > Did you chose them specifically in the REST configuration dialog or it is > > by default ? > > Jersey server bundled libraries should be used by default. > > So the issue actually is : unable to recognize Jersey bundled libraries for WL. > > I've realized that this is the issue actually. > There is the option to use server bundled Jersey library > ( which is used by default ) but WL JaxRs stack plugin is unable to find those > libraries. > > So the problem is : JaxRsStackSupportImpl has a method > extendsJerseyProjectClasspath() which did a search in all available server > libraries for WL . It uses getServerJerseyLibraries method to get libraries: > WLServerLibraryManager manager = new > WLServerLibraryManager(platformImpl.getDeploymentManager()); > Collection<ServerLibrary> libraries = new LinkedList<ServerLibrary>(); > libraries.addAll(findJerseyLibraries(manager.getDeployableLibraries())); > libraries.addAll(findJerseyLibraries(manager.getDeployedLibraries())); > return libraries; > > This code works perfectly for WL version other than 12. > "libraries" is empty for WL 12. > So this is the issue of WL plugin. Unfortunately does not seem to be a plugin issue. It does not return libraries as there are no such server libraries in WL 12. There are some jersey jars in server installation, but does not seem to be referenced as APIs jars. > > > 2) It should works even with Jersey NB bundled libraries . > > This is separate issue and this is not NB issue. > > This is a bug in runtime : Jersey 1.8 or most likely WL. > This is the second issue as I already said. NB bundled Jersey 1.8 libraries are > used as result of server bundled libraries absence. > WL should work with this Jersey version but it doesn't. > So this is the WL 12 runtime issue. Denis, can you file/discuss both these issues with WL team? Thanks.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > WL 12 is not yet publicly available right ? > > > > > > I need to check it after I get WL 12 but I have questions from what I see > > > right now : > > > 1) Jersey 1.8 libraries are used for web project as I see from log . > > > Did you chose them specifically in the REST configuration dialog or it is > > > by default ? > > > Jersey server bundled libraries should be used by default. > > > So the issue actually is : unable to recognize Jersey bundled libraries for WL. > > > > I've realized that this is the issue actually. > > There is the option to use server bundled Jersey library > > ( which is used by default ) but WL JaxRs stack plugin is unable to find those > > libraries. > > > > So the problem is : JaxRsStackSupportImpl has a method > > extendsJerseyProjectClasspath() which did a search in all available server > > libraries for WL . It uses getServerJerseyLibraries method to get libraries: > > WLServerLibraryManager manager = new > > WLServerLibraryManager(platformImpl.getDeploymentManager()); > > Collection<ServerLibrary> libraries = new LinkedList<ServerLibrary>(); > > libraries.addAll(findJerseyLibraries(manager.getDeployableLibraries())); > > libraries.addAll(findJerseyLibraries(manager.getDeployedLibraries())); > > return libraries; > > > > This code works perfectly for WL version other than 12. > > "libraries" is empty for WL 12. > > So this is the issue of WL plugin. > Unfortunately does not seem to be a plugin issue. It does not return libraries > as there are no such server libraries in WL 12. There are some jersey jars in > server installation, but does not seem to be referenced as APIs jars. > > > > > > 2) It should works even with Jersey NB bundled libraries . > > > This is separate issue and this is not NB issue. > > > This is a bug in runtime : Jersey 1.8 or most likely WL. > > This is the second issue as I already said. NB bundled Jersey 1.8 libraries are > > used as result of server bundled libraries absence. > > WL should work with this Jersey version but it doesn't. > > So this is the WL 12 runtime issue. > > Denis, can you file/discuss both these issues with WL team? > Thanks. Yes, that's right. There are no JAX-RS server bundled libraries . So both bugs are runtime WL bugs.
Bugs 13390306 and 13390345 are created in the WL tracker.
Regarding the JAX-RS bundled libraries, I found e.g.: ./modules/com.sun.jersey.client_1.0.0.0_1-9.jar ./modules/com.sun.jersey.core_1.0.0.0_1-9.jar ./modules/com.sun.jersey.json_1.0.0.0_1-9.jar ./modules/com.sun.jersey.multipart_1.0.0.0_1-9.jar ./modules/com.sun.jersey.server_1.0.0.0_1-9.jar ./modules/org.codehaus.jackson.core.asl_1.0.0.0_1-8-3.jar ./modules/org.codehaus.jackson.jaxrs_1.0.0.0_1-8-3.jar ./modules/org.codehaus.jackson.mapper.asl_1.0.0.0_1-8-3.jar ./modules/org.codehaus.jackson.xc_1.0.0.0_1-8-3.jar Can you please check again?
(In reply to comment #7) > Regarding the JAX-RS bundled libraries, I found e.g.: > > ./modules/com.sun.jersey.client_1.0.0.0_1-9.jar > ./modules/com.sun.jersey.core_1.0.0.0_1-9.jar > ./modules/com.sun.jersey.json_1.0.0.0_1-9.jar > ./modules/com.sun.jersey.multipart_1.0.0.0_1-9.jar > ./modules/com.sun.jersey.server_1.0.0.0_1-9.jar > ./modules/org.codehaus.jackson.core.asl_1.0.0.0_1-8-3.jar > ./modules/org.codehaus.jackson.jaxrs_1.0.0.0_1-8-3.jar > ./modules/org.codehaus.jackson.mapper.asl_1.0.0.0_1-8-3.jar > ./modules/org.codehaus.jackson.xc_1.0.0.0_1-8-3.jar > > Can you please check again? Right, they exist in my case also. But they are not wars ( deployable server libraries ). So I don't know are they should be available via ServerLibraries API or not. Reassign to server plugin area to evaluate.
Probably JaxRs stack implementation for WL should be changed respectively absence of server deployable libraries ( just add jar files into the projects classpath instead of server libraries api usage ).
Yes I think so, in Java EE 6 they are a part of the EE platform so it is not necessary to treat them as "optional" deployable libraries - they are baked in.
From my point of view the summary is: 1) The jersey apis are not on declared as APIs by WL so they are not on server classpath in the IDE. Denis might this be a defect in WL? 2) I certainly work around that if you say so to add them on classpath. 3) These jars are not server libraries and we don't want to do the mess by using server library concept for something which is not a library. 4) If there is some more tuning for WL needed it should happen in JaxRsStackSupportImpl. Denis of course you can change the JaxRsStackSupport API in desired way. Denis please let me know on 1) & 2)
Denis, any opinion?
(In reply to comment #11) > From my point of view the summary is: > 1) The jersey apis are not on declared as APIs by WL so they are not on server > classpath in the IDE. Denis might this be a defect in WL? > 2) I certainly work around that if you say so to add them on classpath. Do you mean the jars which are under Libraries subnode Oracle WebLogic Server node ? In this case I don't think so. I believe we should follow the same scenario as for GF: its classpath doesn't contain those jar file. But they are added from GF installation directory when needed. So this is not as issue in the WL I suppose. >3) These jars are not server libraries and we don't want to do the mess by >using server library concept for something which is not a library. >4) If there is some more tuning for WL needed it should happen in >JaxRsStackSupportImpl. Denis of course you can change the JaxRsStackSupport API >in desired way. No need to change API. It was designed from the very beginning to handle such situations. Only WL Jax-Rs implementation needs to be changed.
(In reply to comment #13) > (In reply to comment #11) > > From my point of view the summary is: > > 1) The jersey apis are not on declared as APIs by WL so they are not on server > > classpath in the IDE. Denis might this be a defect in WL? > > 2) I certainly work around that if you say so to add them on classpath. > Do you mean the jars which are under Libraries subnode > Oracle WebLogic Server node ? Yep. > In this case I don't think so. > I believe we should follow the same scenario as for GF: its classpath doesn't > contain those jar file. But they are added from GF installation directory > when needed. > So this is not as issue in the WL I suppose. > > >3) These jars are not server libraries and we don't want to do the mess by > >using server library concept for something which is not a library. > >4) If there is some more tuning for WL needed it should happen in > >JaxRsStackSupportImpl. Denis of course you can change the JaxRsStackSupport API > >in desired way. > No need to change API. It was designed from the very beginning to handle > such situations. Only WL Jax-Rs implementation needs to be changed. Ok, go ahead and change it to reflect your requirements. Let me know if you need any help with that.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #11) > > > From my point of view the summary is: > > > 1) The jersey apis are not on declared as APIs by WL so they are not on server > > > classpath in the IDE. Denis might this be a defect in WL? > > > 2) I certainly work around that if you say so to add them on classpath. > > Do you mean the jars which are under Libraries subnode > > Oracle WebLogic Server node ? > Yep. > > > In this case I don't think so. > > I believe we should follow the same scenario as for GF: its classpath doesn't > > contain those jar file. But they are added from GF installation directory > > when needed. > > So this is not as issue in the WL I suppose. > > > > >3) These jars are not server libraries and we don't want to do the mess by > > >using server library concept for something which is not a library. > > >4) If there is some more tuning for WL needed it should happen in > > >JaxRsStackSupportImpl. Denis of course you can change the JaxRsStackSupport API > > >in desired way. > > No need to change API. It was designed from the very beginning to handle > > such situations. Only WL Jax-Rs implementation needs to be changed. > Ok, go ahead and change it to reflect your requirements. Let me know if you > need any help with that. OK.
The first issue with Jersey server bundled jars is fixed. In the WL 12 Jersey are available as jar files not as war (deployable libraries). Those jars are added to the project classpath in the same manner as for GF instead of NB bundled Jersey . web-main#503238a587c8 The second problem is still bug in the WL runime.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/503238a587c8 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#204573 - Running Java Web App with REST service fails with Missing dependency for field...