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.
There is a number of problems with existed restlib_gfv3 library which is used to configure Web project with REST. See f.e. issue #192733 ( the latest problems ). The mentioned issue is consequence of interference of different version of GF configured at the same time. Here is the description of the problem: - Install two GF servers : 3.1 and 3.0 ( or 3.0.1 ). - Remove .netbeans folder. - Start NB. It will be started without any configuration. - Look at the Libraries. There is not restlib_gfv3 library. - Add into Services tab GF 3.0.1 or (3.0) J2EE server . - Look at the Libraries. The library restlib_gfv3ee6 appears. - Create Web project . - Create RESTful from DB. - Look at the libraries . The classpath contains restlib_gfv3ee6 jars which are : jackson-core-asl jersey-gf-bundle jersey-multipart jettison mimepull jsr311-api - Remove (this step could be skipped) the GF 3.0.1 or 3.0 server instance. - Add GF 3.1 server instance. Look at the libraries in the project . They are changed : jackson-core-asl.jar jackson-jaxrs.jar jackson-mapper-asl.jar jersey-client.jar jersey-core.jar jersey-gf-server.jar jersey-json.jar jersey-multipart.jar jettison.jar mimepull.jar This is because the library content is changed. As result NB suppose to have either GF3.1 or 3.0(3.0.1) but not both at the same time. You cannot have different classpath based on restlib_gfv3 library if you have two projects with different GF servers : one has target 3.0 and other has target 3.1. Library of GF3.1 has always preference against 3.0. So 3.0 targeting will use 3.1 library instead of its own jars This is the one issue. The related issues is impossibility to distinguish two GF instances ( 3.1 and 3.0 ). They both have the same server type gfv3ee6. So one cannot distinguish them when there is a need to check presence of RESTful related jars in the server classpath. As result there is an issue : - Delete .netbeans folder. - Register GF3.1 - Create Web Project - Create RESTful from DB. As result there will be restful jars which are BUNDLED with NB. There is no restlib_gfv3 library jars. This is because WSStack functionality cannot distinguish GF3.1 and GF3.0 and tries to check presence of jars which are valid ONLY for 3.0. But 3.1 has different jars. As result bundled jars are used. What I see as decisions : 1) restlib_gfv3 library could be removed at all and JARs URI will be used to add them into the project instead of library. As result there will be no dependency on restlib_gfv3 library . 2) Implement org.netbeans.modules.j2ee.deployment.plugins.api.ServerLibrary support on the GF plugin side. Such approach (or similar) is preferable because current usage of restlib_gfv3 is little bit ugly and looks like a special hack for GF. The ServerLibrary approach is more strict and universal. I'm not sure is it possible to use this approach for plain jar files. The ServerLibrary usage will delegate classpath extending to the plugin implementation code.
I suppose postpone to fix this issue because it helps to avoid other issue #192733 with GF3.1.
I am not really sure about what you are telling me to do... Are you asking that I remove the restlib_gfv3xxx from the Libraries completely? If the library is gone, I assume this will have a negative impact on other parts of the rest ws development work-flow... You will be fixing those negative impacts?
I suggest to change approach with RESTful libraries. We need something else instead of having restlib_gf3 library . I see here two approaches which I have already wrote : 1) Just remove library ( this is from your side ). From my side : use REST jars directly in the project classpath instead of library. 2) Implement ServerLibrary(ies) for REST. This is server plugin change. I will need ti rewrite REST code according this change. I have described the problem . It really exists. I don't insist on some special solution. I just suggest some of them. If you have other solution for this problem please let me know.
After looking at issue 192733 I do not think it is caused by restlib_gfv3xxx library. The problem seems to exist even in fresh userdir and with only latest version of 'Jersey 1.3' library. Would you agree Denis or are there some other reasons for this issue? In general I think it is OK for newer version of GlassFish server plugin to upgrade an existing library to newer version (considering it is backward compatible update). We intentionally decided to keep the same server type ID for GF 3.0.1 and 3.1 as there should not be major differences. If we find some concrete case where we need to distinguish 3.0.1 from 3.1 or that we need to introduce restlib_gfv31 in addition to restlib_gfv3 then let's discuss it but I would like to first see a clearly explained reason for that distinction. (Sorry if you've already explained that and just overlooked it.)
Yes, I've explained it. But I believe it is hidden because of long description. It is not a problem to update rest library. The problem when you have BOTH GF3.0 and 3.1 registered as J2EE servers. In this case Projects which use different GF servers as targets have THE SAME Jersey jars. That's the issue. SO the project with GF3.0 will never use its own Jersey libraries. I don't see a reason why previous version of GF should use Jersey from the newer version. Because in this case WebLogic target project can also use GF Jersey library. This is not a big problem . But it is just confusing behavior. This is one problem. The second problem : Create GF3.1 target project and add to it RESTful WS. Look at the classpath. There will be Jersey jars FROM NB ( not GF3.1 jars ). This is the consequence of the same server type for GF3.0 and GF3.1. Current RESTful code distinguish server types . For each server type it expect special RESTful related jars. But these jars are different for 3.0 and 3.1. As result GF3.1 jars are not recognized as JAX-RS and NB bundled Jersey jars are used instead of server bundled jars.
(In reply to comment #5) > Yes, I've explained it. But I believe it is hidden because of long > description. Thanks for summarizing them again! re. 1st problem - I agree that it is not a big issue. Confusing but should not cause much harm. And problem is further diminished by the necessity to have both servers at the same time - not many users will do that I would say. And if they do they are transitioning from 3.0.1 to 3.1 anyway. So overall I would tend to not fix this one and wait if it causes some hard problem. re. The second problem - one thing I do not understand is this. You say > Create GF3.1 target project and add to it RESTful WS. > Look at the classpath. There will be Jersey jars FROM NB ( not GF3.1 jars ). > This is the consequence of the same server type for GF3.0 and GF3.1. I would expect that because server types are the same for GF 3.0.1 and 3.1 then RESTful support would do the same for 3.1 as is done for 3.0.1. > As result GF3.1 jars are not recognized What do you mean by this?? I thought RESTful support use server type to decide which library to add to project classpath? This must be the point I'm missing in order to understand you. (Feel free to point me to a source code and I will read the algorithm myself)
OK, let's walk through the code. Please look at the org.netbeans.modules.websvc.rest.projects.WebProjectRestSupport It's method ensureRestDevelopmentReady() check presence of Jersey jars in the server via call hasSwdpLibrary(). This method in the result ask WSStack class for JaxRs feature class. The presence if this WSStack means possibility to use server bundled Jersey libraries. For GF3.x servers the latter WSSStack implementation is org.netbeans.modules.websvc.wsstack.jaxrs.glassfish.v3.GlassFishV3JaxRsStack. The latter class is THE SAME for 3.0, 3.0.1 and 3.1 Check its impl and you will realize quickly why this is the problem. The latter class cares about four jars : "asm", "jersey-bundle", "jettison", "jsr311-api". These jars really exist in the GF3.0. But they are different for GF3.1. This is the very first observation . Of course it is possible to provide "OR" logic: search either one set of jars or other set of jars. But please see the further logic which adds REST jars into the classpath : the same ensureRestDevelopmentReady() in case of presence server bundled libraries call addServerJerseyLibrary(). Check this method implementation . It delegates call to getServerRestLibraryName(). The latter method implementation is hack for me. Why generic REST support class knows about some special library which belongs to GF ? Please note that this code is originally written not by me and I don't want to change it for 7.0. But I really like to change it for 7.x ! I don't like the current approach at all. So why I have crated this issue : I need help from server plugin side to do it in the correct way. You can notice that the same method ensureRestDevelopmentReady() has a special case to handle presence of ServerLibrary(ies) via addDeployableServerJerseyLibraries() which is introduced by me as fix for issue #195542. And the current issue is similar to the issue #195542. We have discussed hardcoded names of libraries for WL. This is mostly the same : hardcoded names of jars for GF. I suggest ( this is just an option, we can choose a different way ) to remove restlib_gfv3 library . And implement the Jersey jar files as ServerLibrary . In case of GF they are not deployable libraries ( like for WL ) but probably it is not a problem ( I don't know actually ). In this case WebProjectRestSupport don't need to now about essence of libraries. It can just configure them for project. As result no hacks and the code is the same for all J2EE servers. One thing we need to do : agree on the way to get list of libraries for J2EE server. I would like to have some server plugin method which allows to me get list of ServerLibraries based on some "tag". I can proceed to use WSStack existed functionality . But it could lead to the same problem as we have now with 3.1. Each client of J2EE server needs to handle any version of J2EE server and update its code respectively ( in my case this is GlassFishV3JaxRsStack ). This is not good approach. I would suppose to delegate such knowledge to the server plugin because they are updated with any new version of J2EE server and this is the appropriate place where knowledge about tagged libraries should be placed. I don't insist on the my suggestion. We can use any other if it fits . Please suggest any other solution of the problem.
based on what you have written, it sound like you have identified a number of interdependent defects in the current implementation of restful web services... this being one of them. Do you have an umbrella issue to track all of them? If you do not, I would suggest that you do that. It also sounds like resolving this defect needs to be part of a coordinated redesign effort... you may want to start a wiki page to facilitate collaboration. I am settign the TM on this particular issue to NEXT, since 'fixing' it in isolation will be the cause of a number of other issues. Starting down that path at this point of the development cycle seems like it will cause more pain than it will resolve.
(In reply to comment #8) > based on what you have written, it sound like you have identified a number of > interdependent defects in the current implementation of restful web services... > this being one of them. Do you have an umbrella issue to track all of them? They are related actually . No, I don't have an umbrella. I've filed this issue for tracking the problem with restlib . > If you do not, I would suggest that you do that. It also sounds like resolving > this defect needs to be part of a coordinated redesign effort... you may want > to start a wiki page to facilitate collaboration. Yes, you are right. I will do that. > > I am settign the TM on this particular issue to NEXT, since 'fixing' it in > isolation will be the cause of a number of other issues. Starting down that > path at this point of the development cycle seems like it will cause more pain > than it will resolve. Agreed. I suppose do not fix it right now from very beginning. And the issue is not about just restlib_gfv3 deletion but about change in the current approach. This issue is actually like an umbrella. But you are right I need to distinguish different issues.
Thanks for the patience. It is clear now! (In reply to comment #7) > I can proceed to use WSStack existed functionality . But it could lead to the > same problem as we have now with 3.1. Each client of J2EE server needs to > handle any version of J2EE server and update its code respectively ( in my case > this is GlassFishV3JaxRsStack ). This is not good approach. > I would suppose to delegate such knowledge to the server plugin because they > are updated with any new version of J2EE server and this is the appropriate > place where knowledge about tagged libraries should be placed. Just to make sure we are on the same page: The reason for WSStack API (I was told; I have not designed it) was to be able to enhance server plugins by 3rd party tools. Independently on server plugin a new API and SPI can be introduced and implemented by 3rd party. JAX-RS is one example. Whether it is a good approach or not and what was the main motivation for it I cannot say. But I do not see any reason why it should not work. Under the condition that 3rd party does not duplicate or hack something what should have been done in server plugin. I agree that we should create a Wiki page and list steps which needs to be done: * tagging of server libraries * explore possibility to use server libraries concept in scenarios like one described here * get rid of existing hacks and hardcoded jar names wherever possible * etc. Looking at code you pointed out I can imagine a *short term* solution: * 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.
I've created an umbrella bug for the described problem : issue #196466. So let's consider this issue as problem with restlib_gfv3 only.
Vince, please review the JaxRs stack plugin implementation for GF which I did as part of the web-main#d3c42579ec48 commit. You are owner of GF plugin so please change my implementation code if you think there is more appropriate way to accomplish Jax RS libraries search task for each GF version. And now you can remove restlib_gfv3xxx library and close all other related issues. The latter library is not used anymore.
(In reply to comment #12) > I did as part of the web-main#d3c42579ec48 commit. and http://hg.netbeans.org/main-silver?cmd=changeset;node=a83c1e78de9e Cool! Looks good that all these wsstack/jaxrs/glassfish/v*/GlassFish*.java are gone from websvc.restapi.
(In reply to comment #13) > (In reply to comment #12) > > I did as part of the web-main#d3c42579ec48 commit. > > and http://hg.netbeans.org/main-silver?cmd=changeset;node=a83c1e78de9e > > Cool! Looks good that all these wsstack/jaxrs/glassfish/v*/GlassFish*.java are > gone from websvc.restapi. Right. That's actually the main change of JaxRs stack. Sorry for mistaken commit number.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/a9c05b5e953d User: vince kraemer <vkraemer@netbeans.org> Log: #196127 : get rid of restlib_gfv3*
in the build