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.
Changes: (0) Implementation of RestSupport in project lookup. (1) build-impl.xsl: adding targets -init-rest, -rest-pre-compile, test-restbeans (2) project context sensitive command: 'Test Rest Beans' (3) Framework item: REST
Created attachment 39914 [details] REST support change
Created attachment 39915 [details] REST support change
Created attachment 39916 [details] Add framework item for REST support
For change (1) please see issue 98881.
Created attachment 39922 [details] Latest change to WebActionProvider.java diff
This is example of unextensibility of our projects. In this situation I basically agree with these changes, but I don't like that the Rest support is done directly in web project module. Shouldn't be done in different module? The project module should contain just the project infrastructure, nothing else.
Does this mean, that web project module will depend on the Rest module?
Yes, web/project module depends on websvc/rest same as it dependends on websvc/core ... I would want to have the framework implementation in Rest Support module websvc/rest. But, this is not possible because websvc is part of ide8, where web/api is part of enterpise4. It would be weird to have a whole module with only one small framework implementation. Hence I temporarily defined the framework implementation as inner class of RestSupport. I agree that it would be ideal for project system should have a generic framework API similar to web/api.
> Yes, web/project module depends on websvc/rest same as it dependends on > websvc/core ... I don't think so. web/project depends on clientapi, jaxwsapi, jaxwsmodel, serviceapi and websvcapi, but not on websvc/core. Nam, can you please attach your changes in project.xml? Thanks.
Created attachment 39960 [details] add dependency to websvc/rest
> It would be weird to have a whole module with > only one small framework implementation. Hence I temporarily defined the > framework implementation as inner class of RestSupport. I understand, your point. From my point of view, the web project module shouldn't contains such things. IMHO it's better to have small module, because user can switch off the support. When you will add other functionality to the rest support, it will be easier to add to the "web-rest" support module, then to the web project module. In the current state the Rest Framework support will be there always, which is difference against other frameworks.
Agree. I will create web/rest module for the framework class.
> From my point of view, the web project module shouldn't contains such things. More generally, it should be able do disable the "main" module for REST support without disabling web/project, and this should disable all REST-related UI, and also all external libraries. It is ok if web/project contains hooks for REST or depends on non-visual REST support, but it should not depend on modules which provide UI or external libraries.
> but it should not depend on modules which provide UI ... I will create a separate websvc/restapi just for the RestSupport SPI.
I have created websvc/restapi and web/webrest in trunk. web/project {dev_restsupport} now depends on restapi instead of rest. web/project {dev_restsupport} layer.xml now also have no declaration of rest framework provider. (attached diffs of the 2 files).
Created attachment 40002 [details] web/project now depends on websvc/restapi
Created attachment 40003 [details] no more webframework provider declaration
Created attachment 40113 [details] AS plugin patch for SWDP libraries to support REST framework
Maybe I'm just being nitpicky, but I don't like the patch to PlatformImpl.java. 1. (line 88) It unnecessarily creates a static HashSet instead of just a String array. This wastes memory. Method at line 311 would need to be recoded slightly to accomodate this. 2. (line 298) It incorrectly checks for possibly empty library list -- the list will never be null but it might be empty - e.g check should be ... if(l.size > 0) ... Other than that, I guess it looks ok.
Hmm actually, I take back #2 in the previous comment -- it could be null. In fact, the method @ 311 short circuits and returns either full list or null. I presume these libraries are always packed in an all-or-none format? If that changes, this code will break -- is this unnecessarily fragile? (ie why not just return a list of whatever libraries do exist?)
Thanks Peter. I have fixed (1). Yes for (2), its all or nothing philosophy. The jars has to exists in order for the framework to function.
Web project now support REST. Note: we decided not to use framework as REST web service should be on par with JAXWS web service.