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.
1. Create a Java EE 5 Web project with WLS 10.3.4dev as target server. 2. Create a REST service 3. REST configuration dialog will appear after finishing the wizard, which offers to add the Jersey library to classpath. However, on the latest WebLogic (dev build), Jersey is included as a shared library under wlserver/common/deployable-libraries. The IDE should give the user the option to use this library, like we do for JSF. Cc'ing Petr H and David as they have been involved in the shared libraries.
Denis, see j2eeserver/apichanges.xml change 1.68 for some details about Server Libraries or ask questions here. I agree with PetrJ that user should be given option of using Weblogic server library.
David, Petr could you point to me the UI actions for related JSF functionality ? I don't understand exactly what result should be for the project. Weblogic contains .war deployable libraries . So what result is expected : there is no need to include them in to the libraries classpath at all or classpath should somehow contains .war ? ( I don't understand how .WAR (not .JAR) file could be included as library. ) If library should be deployed along with project files then how J2EE server change will be handled ?
(In reply to comment #2) > David, Petr could you point to me the UI actions for related JSF functionality > ? > I don't understand exactly what result should be for the project. > Weblogic contains .war deployable libraries . > So what result is expected : there is no need to include them in to the > libraries > classpath at all or classpath should somehow contains .war ? ( I don't > understand > how .WAR (not .JAR) file could be included as library. ) Please do not think about it in this way. It different concept and all these implementation details should be already solved for free for you. There is no explicit copying etc. What you really need is ServerInstance.LibraryManager libManager = Deployment.getDefault().getServerInstance(serverInstanceID).getLibraryManager(); libManager.getDeployedLibraries() and libManager.getDeployableLibraries() This way you can get the list of available or deployable libraries. And when you figure out what server library (typically name and minimum version) you want to use you have to configure it for the project. This is done by J2eeModule.ConfigSupport.configureLibrary(ServerLibraryDependency library) It is used in JSFConfigurationPanelVisual and JSFFrameworkProvider. Note that you should preserve the old behavior for server plugins which do not implement concept of server libraries.
OK, thanks, I will try.
changeset: 179481:d8b4032a5697user: Denis Anisimov <ads@netbeans.org>date: Thu Oct 14 15:28:26 2010 0400summary: Fix for BZ
changeset: 179481:d8b4032a5697 user: Denis Anisimov <ads@netbeans.org> date: Thu Oct 14 15:28:26 2010 +0400 summary: Fix for BZ#190853 - Shared REST library not used on WebLogic
Integrated into 'main-golden', will be available in build *201010150000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d8b4032a5697 User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#190853 - Shared REST library not used on WebLogic
I am just testing this now, and I am thinking, shouldn't "Server library" be the default? Also, regarding the UI, the two checkboxes that behave a bit like radio buttons seem kind of weird. Wouldn't it be better to e.g. have a combo box with three choices - 1. IDE library, 2. server library, 3. do not add anything to CP? Also, when I choose the library from the server, the project will still include enterprise/modules/ext/rest/jsr311/jsr311-api-1.1.1.jar on the classpath. Is this intentional? Should not this be taken also from the server classpath? I.e. $WLS_HOME/common/deployable-libraries/jsr311-api-1.1.1.war ?
1) It's reasonable and no problem. 2) It can be done. But there are reasons do not do it. Personally for me two mutually exclusive checkboxes are better than three radio buttons with third option : do not add anything. Other argument here is the UI consistency. Although there is no change UI on the fly but the same dialog will looks differently for various J2EE servers : - for one there will be checkbox - for other radio buttons instead of checkboxes appears. And additional ( less important ) reason : more complicated UI implementation layout related to alternative controls. Please note that this is just my opinion. It can be ignored because I'm not an expert in the UI. But I have followed this arguments because of minimal changes . 3) Again it could be done. But I would prefer do not do it. The reasons here are more serious. First of all : api jar should be added into the classpath obligatory. Api jar contains annotations which are used for RESTful WS. Otherwise generated class file will be non-compilable. So this jar file doesn't relate to Jersey dialog. So there is too options : 1) Add additional controls into Jersey dialog about usage server bundled api jar 2) Silently add api jar from server library (if jersey bundled library is chosen). Both options are not good from my point of view. Even worse : one more dialog ( because api jar is not jersey ) about api jar. Second reason : it relates to first one actually. Usage of server bundled library doesn't add jar file to classpath immediately. There will be mark on project about absence of required library. And library will be added into the project only after explicit additional user action. So on the moment of RESTful WS class generation api jar is not in the classpath. And there will be again compilation errors. Third reason : let's assume server bundled api jar is added into classpath. User have decided to change J2EE server. Jersey library is just RI and it influence only on runtime. NB project could be still used for further development without a problem. But server bundled api jar will not be available for new J2EE server. As result project will have errors and classes will be uncompilable.
The correct (in terms of guidelines and best practises) is the following: -------------------------------------- [x] Add Jersey Library to the Project Source: [ Web logic bundled | v ] -------------------------------------- where first row is a checkbox, second is a combo box (also, radiobuttons could be used but they would take more space in the dialog). Also, don't take exact wording as written in stone. It may also be helpful to show library version in the combo box as it may be important determinator for the user which library to choose. It's not necessarily most minimalistic UI, but it should be the easiest to use and it clearly communicates how these three options are related. It should address Denis' comments number 1 & 2, I can not help with number 3 without more in-depth involvement as I'm not an expert in this domain (ws).
OK, thanks. I agree with the proposition about UI. 3d item is out of UI scope . There are number of functionality questions related to item 3 ( I have described them already previously ). Bug is reopened : Jersey dialog should be improved accordingly to previous comment.
changeset: 183453:27a748523e2c user: Denis Anisimov <ads@netbeans.org> date: Tue Nov 30 13:56:02 2010 +0300 summary: Fix for BZ#190853 - Shared REST library not used on WebLogic
Integrated into 'main-golden', will be available in build *201012010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/27a748523e2c User: Denis Anisimov <ads@netbeans.org> Log: Fix for BZ#190853 - Shared REST library not used on WebLogic