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 209713 - "REST Resources configuration" too complicated
Summary: "REST Resources configuration" too complicated
Status: RESOLVED FIXED
Alias: None
Product: webservices
Classification: Unclassified
Component: REST (show other bugs)
Version: 7.1.1
Hardware: All All
: P3 normal (vote)
Assignee: Denis Anisimov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-19 03:18 UTC by David Konecny
Modified: 2012-04-27 17:04 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Konecny 2012-03-19 03:18:18 UTC
After reading issue 209515 and issue 209711 I'm thinking that %SUBJ% dialog is too complicated and could be replace with following UI:

-------------------

[ ] Use Jersey

-------------------

I mean, if user has not ticked the box we know they are after functionality defined in EE/JAX-RS spec and all what IDE would do is to generate ApplicationConfig class with empty content:

@javax.ws.rs.ApplicationPath("webresources")
public class ApplicationConfig extends javax.ws.rs.core.Application {

and let user edit it. Current NetBeans support which generates this class from build script seems to me pretty useless unless I missed some code which would later add something useful there. In any case I think it is OK to let the user edit it by hand and not provide any additional support for it. It would be nice-to-have feature to have a UI somewhere (project properties??) which would list all relevant classes and let user tick them on/off and based on that regenerate ApplicationConfig.getClasses method. Note that in this scenario nothing is added to compilation classpath.

If user ticked "Use Jersey" then we know they are after additional Jersey features not covered by EE/JAX-RS spec and we would automatically generate web.xml with Jersey servlet (seems like a preferred way to configure Jersey although it is a bit said as we spent quite a lot of effort to not generate web.xml ever again) and add Jersey jars (from application server) to project classpath with packaging checkbox off. Again it would be nice-to-have feature to show "Jersey" tab on web.xml GUI multiview with all the advanced Jersey options.

Anything what this solution would not cover?
Comment 1 Denis Anisimov 2012-03-19 07:05:32 UTC
First of all : I don't think this is DEFECT. I think it is enhancement.

The description is applicable only for JEE6 profile.
In this case Jersey is not required for JAX-RS. As result explicit Jersey usage 
means that user wants to add some specific functionality.
I agree here that dialog cold be simplified in the suggested way and moreover 
it could be removed at all probably : one option dialog looks strange.
Explicit Jersey usage is rare usecase and should be optional: it could possible
to change bevhavior via additional options after service generation.

There is also JEE5 case where Jersey is required because JAX-RS is not a part of
JEE5 spec.
What do you suggest in that case ? 
Please note that application will not work without some additional configuration :
- web.xml should be modified respectively 
- classpath should be extended ( previous modification depends on what exactly 
classes are used )
- user could choose some different JAX-RS realization and configure application 
manually.

Actually the reason of the current state of dialog is exactly JEE5 case:
 consider also JEE5 profile with server-bundled libraries available on the 
runtime server ( in the GF case they are just a plain jars; 
deployable libraries for WL case ).

So it is not so simple as it looks like at the first glance.
Comment 2 David Konecny 2012-03-19 20:09:53 UTC
I do care primarily only about EE6. If we can significantly simplify something for EE6 then we should always do it. And for EE5 just leave the complex solution in place. I know that it is harder to achieve then it sounds. :-) But let not EE5 issues cripple people who are working only with EE6.

> I agree here that dialog cold be simplified in the suggested way and moreover 
> it could be removed at all probably

Definitely. I do not think it is necessary at all. The option of Jersey-or-not could be moved into wizard generating services or somewhere else.

> Explicit Jersey usage is rare usecase and should be optional: it could possible
> to change bevhavior via additional options after service generation.

I'm thinking about Jersey as "EE6 spec plus some more features" so user should be always happy with vanilla EE6 projects and if they want more they just have to enable it somewhere and they will get more. But "more" does not obsolete or replaces EE6 spec - it builds on top of it and enhances it. I think.
 
> There is also JEE5 case where Jersey is required because JAX-RS is not a part
> of
> JEE5 spec.
> What do you suggest in that case ? 

If EE5 then leave-everything-as-is else use-simpler-solutuion
Comment 3 Denis Anisimov 2012-03-20 05:48:05 UTC
OK, I agree with this.
Comment 4 Petr Jiricka 2012-03-20 10:17:57 UTC
Ok, sounds like there is agreement. I would only suggest to change the wording of the "Use Jersey" checkbox (assuming we display it e.g. in the new REST service wizard) to something like "Use specific Jersey features or configuration options", because if the user wants to use Jersey, that does not yet mean that they want to use non-standard features. They may be thinking "yes, I want to use Jersey as the implementation of the standard, but I want to use pure JAX-RS".
Comment 5 Denis Anisimov 2012-03-20 10:19:37 UTC
(In reply to comment #4)
> Ok, sounds like there is agreement. I would only suggest to change the wording
> of the "Use Jersey" checkbox (assuming we display it e.g. in the new REST
> service wizard) to something like "Use specific Jersey features or
> configuration options", because if the user wants to use Jersey, that does not
> yet mean that they want to use non-standard features. They may be thinking
> "yes, I want to use Jersey as the implementation of the standard, but I want to
> use pure JAX-RS".

Agreed.
Comment 6 japod 2012-03-22 11:06:31 UTC
This proposal looks good to me.
Comment 7 Denis Anisimov 2012-04-25 13:10:33 UTC
web-main#faa3c672629b: REST config dialog is removed for JEE6.
Jersey vs REST JEE6 feature is configured in the wizards.
JEE5 profile projects keep previous approach.
Comment 8 Petr Jiricka 2012-04-27 13:21:24 UTC
Thanks a lot, I am testing this and it works fine so far, I found just a few issues and questions (plus some more that I filed separately):
1. Should the Use Jersey specific features checkbox be checked by default?
2. The default package for ApplicationConfig should not be org.netbeans.rest.application.config, as this is not NetBeans code. How about <application_name>.rest.config, i.e. for example webapplication16.rest.config? This would be consistent with the naming of main class in Java SE projects.
3. It happened to me that when I created the first REST service, the ApplicationConfig was empty, i.e. methods getClasses() and getResourceClasses() were missing. (They were then created when I created a second web services.) But this looks like a random issue, in another case these methods were creating while creating the first service in the project.
4. After we change ApplicationConfig, it should be saved I think - currently we leave it modified in editor.
5. When I move ApplicationConfig to another package, it is not updated by creating a new web service. We can probably detect its location/name from the Java index, no?

Anyway should this bug now be closed as fixed? Should I file the above as separate subissues?
Comment 9 Denis Anisimov 2012-04-27 14:48:21 UTC
(In reply to comment #8)
> Thanks a lot, I am testing this and it works fine so far, I found just a few
> issues and questions (plus some more that I filed separately):
> 1. Should the Use Jersey specific features checkbox be checked by default?
Jersey is just a specific REST implementation. I don't see a reason to keep 
it as default way to use REST. Generally user uses JEE6 defined features.
> 2. The default package for ApplicationConfig should not be
> org.netbeans.rest.application.config, as this is not NetBeans code. How about
> <application_name>.rest.config, i.e. for example webapplication16.rest.config?
> This would be consistent with the naming of main class in Java SE projects.
> 3. It happened to me that when I created the first REST service, the
> ApplicationConfig was empty, i.e. methods getClasses() and getResourceClasses()
> were missing. (They were then created when I created a second web services.)
> But this looks like a random issue, in another case these methods were creating
> while creating the first service in the project.
> 4. After we change ApplicationConfig, it should be saved I think - currently we
> leave it modified in editor.
> 5. When I move ApplicationConfig to another package, it is not updated by
> creating a new web service. We can probably detect its location/name from the
> Java index, no?
Yes, I think so.
> 
> Anyway should this bug now be closed as fixed? Should I file the above as
> separate subissues?

That's not a bug, this is a task about improving REST configuration.  
I'm not sure what is the best way to handle this issue.
Comment 10 Petr Jiricka 2012-04-27 17:04:45 UTC
Ok, I filed items 2-5 under a new enhancement 211871.

> I'm not sure what is the best way to handle this issue.

I think we can now close it as fixed.