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.
Created attachment 95354 [details] WebLogic log file with the exception 1. Register the latest WebLogic server 2. Create a new Java EE 5 application with WebLogic as the target 3. On the Frameworks panel, select JSF and accept the defaults 4. Deploy the application => Deployment exception will occur in the server log file, see attachment.
The following evaluation by Tomasz Slota is relevant: http://netbeans.org/bugzilla/show_bug.cgi?id=182313#c2
Following code added to weblogic.xml seems solve the issue: <library-ref> <library-name>jsf</library-name> <specification-version>1.2</specification-version> <implementation-version>1.2</implementation-version> <exact-match>false</exact-match> </library-ref> So it can be added automatically during adding JSF framework in case Application Server is WebLogic
Thanks for investigating, Alexey. Sounds like the server plugin will need to be involved, right? I am cc'ing Petr H as the WebLogic plugin owner.
(In reply to comment #3) > Thanks for investigating, Alexey. Sounds like the server plugin will need to be > involved, right? I am cc'ing Petr H as the WebLogic plugin owner. I'm sorry, but It was premature conclusion. Library reference will work only if jsf lib deployed to the server via admin console or via command line, before application deployed. It seems that I've deployed it via Jdeveloper, and then it was working in Netbeans. So we need a mechanism to deploy library to the WebLogic Server.
It seems that the easiest solution would be to restrict using library which comes with server option for WebLogic. I found that when using registered libraries, application can be deployment without any problems and additional steps, because in this case libs packed into application's war file.
That's not what I observed - see the steps to reproduce above, I just accepted all the defaults. And the libraries were NOT packaged into the war.
(In reply to comment #6) > That's not what I observed - see the steps to reproduce above, I just accepted > all the defaults. And the libraries were NOT packaged into the war. I mean to remove default option to use library which comes with server (until we will have possibility to deploy libraries before deploying the app), thus the default will be to use registered library. The same way as for maven web app.
I see, yes you are right. That could be an option, but I'd rather use that as a backup solution, if the proper solution (i.e. enabling the bundled library in WebLogic) can not be done for 6.9.
(In reply to comment #8) > I see, yes you are right. That could be an option, but I'd rather use that as a > backup solution, if the proper solution (i.e. enabling the bundled library in > WebLogic) can not be done for 6.9. Proper solution requires a method or an API in WebLogic plugin to deploy the bundled library. The rest I can manage on JSF side. Petr H could you comment on availability/possibility of such API in WebLogic plugin? Meanwhile I can integrate the backup solution, and convert issue to enhancement or task, Petr J. what do you think about it?
Integrated into 'main-golden', will be available in build *201003270201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0e7a648d8015 User: Alexey Butenko <alexeybutenko@netbeans.org> Log: #182282: backup solution
No longer a P2 after Alexey's workaround, reassigning to Petr H as the server integration owner.
Unfortunately, the workaround on the JSF framework side will not work. Because with this workaround, you will see that the following message is printed to the WebLogic console: SEVERE: JSF1030: The specified InjectionProvider implementation 'com.bea.faces.WeblogicInjectionProvider' cannot be loaded. This is really serious - this means that injection does not work. So if you have the NetBeans-generated JSF CRUD application, the following field in CustomerJpaController will not be initialized: @PersistenceUnit(unitName = "WebApplication62PU") private EntityManagerFactory emf = null; Then it will result in NPE during runtime: Caused by: java.lang.NullPointerException at entities.CustomerJpaController.getEntityManager(CustomerJpaController.java:31) You can find more discussion about this problem on the JSF forum: http://old.nabble.com/WeblogicInjectionProvider-cannot-be-loaded-td13705245.html#a13725064 Basically, it is NOT possible to include a JSF implementation in WEB-INF/lib - you have to use the version provided by WebLogic. Raising priority back to P2.
In the light of the problem outlined in the previous comment, I am thinking whether it would be better to remove Alexey's workaround, not package anything in WEB-INF/lib and just make it clear that weblogic.xml has to be modified to make JSF work. What do you think?
(In reply to comment #4) > > Library reference will work only if > jsf lib deployed to the server via admin console or via command line, before > application deployed. I do not understand this. Weblogic can use only its own version of JSF impl jar (one containing com.bea.faces.WeblogicInjectionProvider class) yet that JSF impl jar has to be deployed to server via admin console or via command line? Where did you get the right JSF jar to deploy? I would expect that if Weblogic needs special JSF impl then such jar would be part of the server and user could just use them by referencing them from weblogic.xml. Alexey, does JSF jar has to be deployed once per server or per web application? Where did you get that jar? If we cannot deploy non-Weblogic version of JSF (which is bug in Weblogic IMO) then I would go with weblogic.xml and in that case it is again server bug that JSF library is not available. Btw. http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/configurejsfandjtsl.html says that "JSF 1.2 (JavaServer™ Faces) and JSTL 1.2 (JSP™ Standard Tag Library) packages *are bundled* with WebLogic Server as shared Web application libraries. These libraries can be referenced by standard Web applications..." If it is matter of enabling JSF libraries once per server then I would just document it in release notes for users to do and would not worry about it from NB point of view.
I installed Weblogic and tested this and got answers to my questions: * JSF shared Web application library must be deployed once per server and is available in <install-dir>/wlserver/common/deployable-libraries as jsf-1.2.war or jsf-2.0.war * jsf-1.2.war/jsf-2.0.war contains wls.jsf.di.jar which contains single class (/com/bea/faces/WeblogicInjectionProvider.class) which is necessary for injection to work in JSF managed beans. wls.jsf.di.jar looks to me like internal Weblogic implementation code which should never been exposed outside of server IMO. It is possible to take that jar and add it to classpath of a project with regular Sun JSF and such project can be deployed and runs OK on Weblogic. But it is probably not legal, Weblogic/JSF version dependent, unsupported and therefore hard to recommend to our users (unless weblogic team advices that we could bundle that library in NB and use it safely). The only other option is shared web app library which works once library was deployed. Solution for that can be either leaving responsibility fully on user (and warn them for example in New Server wizard - deploy shared library before you use JSF etc.) or automatically deploy libraries for example during application deployment (Weblogic server plugin would have to parse weblogic.xml and deploy all required libraries which can be found in <install-dir>/wlserver/common/deployable-libraries and have not been deployed yet). Any other ideas?
Workaround removed: see http://hg.netbeans.org/web-main/rev/0509b9e6e5be
(In reply to comment #15) > ... > and use it safely). The only other option is shared web app library which works > once library was deployed. Solution for that can be either leaving > responsibility fully on user (and warn them for example in New Server wizard - > deploy shared library before you use JSF etc.) or automatically deploy > libraries for example during application deployment (Weblogic server plugin > would have to parse weblogic.xml and deploy all required libraries which can be > found in <install-dir>/wlserver/common/deployable-libraries and have not been > deployed yet). Any other ideas? I agree that we are either leave it for the user or take care of libraries on the server plug-in side.
(In reply to comment #17) > (In reply to comment #15) > > ... > > and use it safely). The only other option is shared web app library which works > > once library was deployed. Solution for that can be either leaving > > responsibility fully on user (and warn them for example in New Server wizard - > > deploy shared library before you use JSF etc.) or automatically deploy > > libraries for example during application deployment (Weblogic server plugin > > would have to parse weblogic.xml and deploy all required libraries which can be > > found in <install-dir>/wlserver/common/deployable-libraries and have not been > > deployed yet). Any other ideas? > I agree that we are either leave it for the user or take care of libraries on > the server plug-in side. I think we should 1) leave it up to user for 6.9 2) take care of libraries for 6.9.1 or whatever the next release will be (this will require API change afaik)
(In reply to comment #18) > 1) leave it up to user for 6.9 To make sure we have the same understanding this will mean that: * weblogic.xml will be created with reference to JSF server shared library * user has to manually deploy JSF server shared library (once per server installation) That also means that JSF framework panel in New Web Project should in ideal world have one more option in Libraries tab: "Use server shared library" followed by a combo box listing all versions available as shared libraries on selected server. Based on this selection weblogic.xml would be updated with reference to chosen version. Workaround for 6.9 could be to use "Use default library which comes with Server" and by default choose highest version available (that is JSF 2). Do we want to show a warning somewhere? For example when above mentioned checkbox is selected in JSF framework panel should we show warning in wizard saying "Make sure JSF shared server library is deployed on the server. More info" where 'more info' could be a link to http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/configurejsfandjtsl.html Any other problems to address?
(In reply to comment #19) > (In reply to comment #18) > > 1) leave it up to user for 6.9 > > To make sure we have the same understanding this will mean that: > * weblogic.xml will be created with reference to JSF server shared library > * user has to manually deploy JSF server shared library (once per server > installation) > No I think there should be warning in the wizard nothing more. Otherwise this would require to implement a) getting list of libs b) provide API to send selected library from project to serverplugin. Considering the code freeze and the fact it has never worked I wouldn't go this way.
(In reply to comment #20) > > > 1) leave it up to user for 6.9 > > > > To make sure we have the same understanding this will mean that: > > * weblogic.xml will be created with reference to JSF server shared library > > * user has to manually deploy JSF server shared library (once per server > > installation) > > No I think there should be warning in the wizard nothing more. Otherwise this > would require to implement a) getting list of libs b) provide API to send > selected library from project to serverplugin. Considering the code freeze and > the fact it has never worked I wouldn't go this way. I'm happy to add to j2ee.common or web.project an ugly hotfix for NB69 which would hardcode weblogic.xml content eg. if Weblogic.version < 10.0.3 use JSF1.2 shared library or use JSF2.0. Or at least generate weblogic.xml which contains all JSF libraries commented out and user would just has to uncomment one they want to use. Or something like that. What I would like to achieve is that user has to do as little as possible, ideally just deploy latest version of JSF library in WL server and that's it. What do you think?
(In reply to comment #21) > I'm happy to add to j2ee.common or web.project an ugly hotfix for NB69 which > would hardcode weblogic.xml content eg. if Weblogic.version < 10.0.3 use JSF1.2 > shared library or use JSF2.0. Or at least generate weblogic.xml which contains > all JSF libraries commented out and user would just has to uncomment one they > want to use. Or something like that. What I would like to achieve is that user > has to do as little as possible, ideally just deploy latest version of JSF > library in WL server and that's it. What do you think? I'm afraid there is no way (API again) for j2ee.common how to figure out weblogic version (only severplugin knows it). With weblogic.xml it is the same problem - serverplugin handles it. I personally think it is better to honestly admit "We don't support it, so do it yourself or wait for the next release." than to make half way solution which could confuse the user in a way "Does it work or not? What additional things should I do?". And I still think there is little impact to real world users - no single report on this so far afaik.
(In reply to comment #22) Fine with me.
Integrated into 'main-golden', will be available in build *201005182201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ User: Log:
Regarding the warning message, we just discussed with Petr H - we agree with David this would be good to add. Alexey, could you please add the warning message that David suggested in comment #19? We will want to transplant this message also to the 6.9 clone. Thanks.
(In reply to comment #25) > Regarding the warning message, we just discussed with Petr H - we agree with > David this would be good to add. Alexey, could you please add the warning > message that David suggested in comment #19? We will want to transplant this > message also to the 6.9 clone. Thanks. Ok, but there will an UI change then. I need to add a JLabel for a message somewhere in the panel since I'm not able to use existing label where all warnings and errors printed because it can be used only when isValid method of the WebModuleExtender class return false.
Ok, I did not know - this sounds like an unfortunate limitation. Would it be possible to add generic support for warning messages to this dialog at some point? As this is a UI change, please follow the late UI changes process: http://jupiter.czech.sun.com/wiki/view/Nbdoc/NB69LateUIChanges
(In reply to comment #27) > Ok, I did not know - this sounds like an unfortunate limitation. Would it be > possible to add generic support for warning messages to this dialog at some > point? As this is a UI change, please follow the late UI changes process: > http://jupiter.czech.sun.com/wiki/view/Nbdoc/NB69LateUIChanges Generic support (without UI changes) could be done in web.project module which is owned by David in PanelSupportedFrameworksVisual class. I've attached a simple fix, which is checking for info messages even in case the extender module is valid. David, could you review it? Will it work?
Created attachment 99203 [details] patch
(In reply to comment #29) > Created an attachment (id=99203) [details] > patch Looks good. Thanks Alexey.
http://hg.netbeans.org/web-main/rev/ed09feffc76c So, I've committed reviewed patch and warning message for Weblogic server. Note, there is no link in the message, because you can not click on hyperlink in Jlabel to open it in the browser directly without using Java backend. And this Jlabel is part of WizardDescriptor (Dialogs API).
Increasing to P1, since the warning message should be in 6.9
(In reply to comment #31) > Note, there is no link in the message, because you can not click on hyperlink > in Jlabel to open it in the browser directly without using Java backend. Just FYI: last time I saw it (or implemented it myself?) was to hardcode JLabel to have blue underlined text (underlying was I think done by setting HTML text to JLabel) and add handler for OnClick event which uses util API to browse an URL. (wizard to register GlassFish V3 contains hyperlink)(I think)
The warning message verified in the trunk build by QE. Please transplant.
transplanted http://hg.netbeans.org/release69/rev/ed1abd61b5c4
Downgrading back to P2 to request waiver.
Funny state : 69_HR_FIX as well as 6.9_WAIVER_REQUEST ??? If it's fixed : mark as FIXED and remove 6.9_WAIVER_REQUEST from keywords list if it's not fixed : remove 69_HR_FIX keyword If it's fixed paritally : close this one as FIXED, remove 6.9_WAIVER_REQUEST from keywords list and report new issue for 'not yet fixed part of the problem' Thanks in advance.
> Funny state : 69_HR_FIX as well as 6.9_WAIVER_REQUEST ??? Why funny? Why would that be illegal? 69_HR_FIX refers to a warning message that Alexey included during high resistance mode. I would not call this a partial fix, just a message so the workaround is easier to find. > remove 6.9_WAIVER_REQUEST > from keywords list and report new issue for 'not yet fixed part of the problem' Well, no part of this problem is fixed. The entire issue is still completely valid.
(In reply to comment #38) > > Funny state : 69_HR_FIX as well as 6.9_WAIVER_REQUEST ??? > > Why funny? Why would that be illegal? You are saying : "we fixed this issue during 6.9 HR" as well as "we don't want to fix this into 6.9" - sounds contradictory and it's illegal > 69_HR_FIX refers to a warning message that Alexey included during high > resistance mode. I would not call this a partial fix, just a message so the > workaround is easier to find. easy to explain: all 69_HR_FIX issues have to be fixed by FCS date of NetBeans 6.9 (just by definition: 69_HR_FIX means FIXED during 6.9 HR), if it's not fixed yet : 1. remove 69hrfix keyword from this issue(done) 2. (and if you want to track somewhere that you made some changes into 6.9 during HR:) create separate issue, add 69hrfix there, close it as fixed
> if you want to track somewhere that you made some changes into 6.9 during HR I don't, but I created it anyway - bug 186798.
(In reply to comment #40) > I don't, but I created it anyway - bug 186798. Thanks Petr.
Waiver approved.
Mini UI spec for JSF wizard: http://wiki.netbeans.org/WeblogicJSF
Created attachment 99767 [details] full patch The complete patch including the usage of the new API and JSF wizard changes. Does not implement library handling in EAR or editor classpath.
Created attachment 99768 [details] api pacth The j2eeserver (API) part of the patch above. The API provides a way to handle the server libraries in the workflow of j2eeserver infrastructure.
Please review the j2eeserver API change.
I've had offline discussion with PetrH and here are some more comments: DK01: ServerLibraryConfiguration may need also unconfigureRequiredLibrary - depends on whether UI will allow JSF library change or not. DK02: looking at ServerLibraryConfiguration class maybe a name which would indicate that project context is what matters here would be better? ProjectServerLibraryConfiguration? or ProjectServerLibraries? and methods could be just addLibrary/removeLibrary/getLibraries no? As that's what you are doing - adding a server library to project and getting their list. I think the word "Required" in method signatures of your API is redundant. DK03: ServerLibraryImplementation.getLibraryFile should not be in SPI. In Weblogic case it points to a single jar or WAR containing multiple JARs and that's an implementation specific detail which clients of the API should not see or make usage of. Something like "ClassPath ServerLibraryImplementation.getClassPath" would be better abstraction. DK04: "http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/programming/libraries.html" talks about EE Libraries and Optional Packages. Current API proposal deals only with EE Libraries, right? I think what GlassFish does is more like Optional Packages, but double check. DK05: I was thinking what to do when library is a WAR and contains several JARs. The trouble is that these JARs need to be available for project compilation even without appserver. Simple solution might be for server plugin to simply unpack these jars somewhere under server installation directory and use them from there. If project is not sharable and is opened in the IDE then everything should just work - server plugin would get a chance to fix server classpath and unpack libraries if needed. If project is sharable then everything is OK because sever classpath content is copied to project and so library jars would be copied as well. If project is not sharable and compiled from command line then server installation directory has to be given by user. And that server installation may or may not have unzipped libraries.
> DK01: ServerLibraryConfiguration may need also unconfigureRequiredLibrary - > depends on whether UI will allow JSF library change or not. Yes, we'll see. I don't want to put unused methods into the API. > DK02: looking at ServerLibraryConfiguration class maybe a name which would > indicate that project context is what matters here would be better? > ProjectServerLibraryConfiguration? or ProjectServerLibraries? I would agree however there is bunch of similar class (the whole config package) so I decided to respect the present convention. > and methods could > be just addLibrary/removeLibrary/getLibraries no? As that's what you are doing > - adding a server library to project and getting their list. I think the word > "Required" in method signatures of your API is redundant. Done. > DK03: ServerLibraryImplementation.getLibraryFile should not be in SPI. In > Weblogic case it points to a single jar or WAR containing multiple JARs and > that's an implementation specific detail which clients of the API should not > see or make usage of. Agreed. Done. > Something like "ClassPath > ServerLibraryImplementation.getClassPath" would be better abstraction. > > DK04: > "http://download-llnw.oracle.com/docs/cd/E12840_01/wls/docs103/programming/libraries.html" > talks about EE Libraries and Optional Packages. Current API proposal deals only > with EE Libraries, right? I think what GlassFish does is more like Optional > Packages, but double check. > > DK05: I was thinking what to do when library is a WAR and contains several > JARs. The trouble is that these JARs need to be available for project > compilation even without appserver. Simple solution might be for server plugin > to simply unpack these jars somewhere under server installation directory and > use them from there. If project is not sharable and is opened in the IDE then > everything should just work - server plugin would get a chance to fix server > classpath and unpack libraries if needed. If project is sharable then > everything is OK because sever classpath content is copied to project and so > library jars would be copied as well. If project is not sharable and compiled > from command line then server installation directory has to be given by user. > And that server installation may or may not have unzipped libraries. I'm experimenting with CP. I think the best place would be J2eePlatform.getClasspathEntries(J2eeModule) which would be complement or replacement for J2eePlatform.getClasspathEntries(). However this is really tough one. The method is used in project, in javadoc and source query and also for shared libraries. Other uneasy thing is that when shared library is created (typically during project creation) there is no project yet.
Created attachment 99822 [details] imrpoved patch
The patch is growing. Now it hadles the CP in the editor and in the Project node. It still does not handle a) sharability b) source & javadoc queries c) ear/ejb (should be easy to do once it is prototyped on war) Now I also think we should communicate the missing/broken library in a similar way we do for standard missing libraries.
Created attachment 100004 [details] improved patch 2
For better regression testing I pushed the current patch to web-main 02ae7e2f505b. More non-api changes will follow.
Integrated into 'main-golden', will be available in build *201006160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/02ae7e2f505b User: Petr Hejl <phejl@netbeans.org> Log: #182282 Empty JSF application can not be deployed to WebLogic
Petr, it seems that your commit caused #188443, Could you take a look, please?
Classpath handling - web-main 9e45cd1015cd.
Small optimization - web-main 44c17a45e8ed.
I tried with the latest build and things seem to be working well for Ant projects. So can this problem be considered fixed, or are there things that still need to be addressed? For Maven, this is basically tracked in a separate bug 175130, so let's continue the discussion there - in short, the same choice of server JSF library that is available for Ant should also be available for Maven, right?
(In reply to comment #57) > I tried with the latest build and things seem to be working well for Ant > projects. So can this problem be considered fixed, or are there things that > still need to be addressed? I think the creation of project - resolve missing library cycle should be made more user friendly. I expect I'll close the bug on Monday.
Initial library deployment (after project creation) should be fixed - web-main cb7f523dc6a6.
Integrated into 'main-golden', will be available in build *201007140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/cb7f523dc6a6 User: Petr Hejl <phejl@netbeans.org> Log: #182282 Empty JSF application can not be deployed to WebLogic - initial library depl.