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.

Bug 98879

Summary: Add REST support to web projects
Product: javaee Reporter: Nam Nguyen <nnguyen>
Component: Web ProjectAssignee: Nam Nguyen <nnguyen>
Status: RESOLVED FIXED    
Severity: blocker CC: pjiricka, ppisl, rnajman, vidhya
Priority: P1    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 98884, 98881    
Bug Blocks:    
Attachments: REST support change
REST support change
Add framework item for REST support
Latest change to WebActionProvider.java diff
add dependency to websvc/rest
web/project now depends on websvc/restapi
no more webframework provider declaration
AS plugin patch for SWDP libraries to support REST framework

Description Nam Nguyen 2007-03-24 15:22:42 UTC
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
Comment 1 Nam Nguyen 2007-03-24 16:26:53 UTC
Created attachment 39914 [details]
REST support change
Comment 2 Nam Nguyen 2007-03-24 16:27:56 UTC
Created attachment 39915 [details]
REST support change
Comment 3 Nam Nguyen 2007-03-24 16:38:32 UTC
Created attachment 39916 [details]
Add framework item for REST support
Comment 4 Nam Nguyen 2007-03-24 16:42:56 UTC
For change (1) please see issue 98881.
Comment 5 Nam Nguyen 2007-03-25 19:22:48 UTC
Created attachment 39922 [details]
Latest change to WebActionProvider.java diff
Comment 6 Petr Pisl 2007-03-26 09:23:33 UTC
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.
Comment 7 Petr Pisl 2007-03-26 11:05:31 UTC
Does this mean, that web project module will depend on the Rest module?
Comment 8 Nam Nguyen 2007-03-26 16:26:04 UTC
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.

Comment 9 Petr Jiricka 2007-03-26 16:48:16 UTC
> 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.
Comment 10 Nam Nguyen 2007-03-26 17:03:48 UTC
Created attachment 39960 [details]
add dependency to websvc/rest
Comment 11 Petr Pisl 2007-03-26 17:21:55 UTC
> 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. 

Comment 12 Nam Nguyen 2007-03-26 17:30:08 UTC
Agree.  I will create web/rest module for the framework class.
Comment 13 Petr Jiricka 2007-03-26 17:59:55 UTC
> 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.
Comment 14 Nam Nguyen 2007-03-26 18:16:56 UTC
> but it should not depend on modules which provide UI ...
I will create a separate websvc/restapi just for the RestSupport SPI.
Comment 15 Nam Nguyen 2007-03-27 04:00:42 UTC
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).

Comment 16 Nam Nguyen 2007-03-27 04:05:15 UTC
Created attachment 40002 [details]
web/project now depends on websvc/restapi
Comment 17 Nam Nguyen 2007-03-27 04:07:59 UTC
Created attachment 40003 [details]
no more webframework provider declaration
Comment 18 Nam Nguyen 2007-03-28 23:41:15 UTC
Created attachment 40113 [details]
AS plugin patch for SWDP libraries to support REST framework
Comment 19 _ pcw 2007-03-29 01:33:38 UTC
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.
Comment 20 _ pcw 2007-03-29 01:37:37 UTC
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?)
Comment 21 Nam Nguyen 2007-03-29 01:58:40 UTC
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.
Comment 22 Nam Nguyen 2007-06-19 00:46:09 UTC
Web project now support REST.  
Note: we decided not to use framework as REST web service should be on par with JAXWS web service.