Bug 182282 - Empty JSF application can not be deployed to WebLogic
Empty JSF application can not be deployed to WebLogic
Status: RESOLVED FIXED
Product: javaee
Classification: Unclassified
Component: JSF
6.x
All All
: P2 (vote)
: 7.0
Assigned To: Petr Hejl
issues@javaee
: API, API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-18 09:29 UTC by Petr Jiricka
Modified: 2010-12-17 21:40 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
WebLogic log file with the exception (19.12 KB, text/plain)
2010-03-18 09:29 UTC, Petr Jiricka
Details
patch (991 bytes, patch)
2010-05-19 12:56 UTC, Alexey Butenko
Details | Diff
full patch (159.86 KB, patch)
2010-06-02 15:05 UTC, Petr Hejl
Details | Diff
api pacth (64.08 KB, patch)
2010-06-02 15:23 UTC, Petr Hejl
Details | Diff
imrpoved patch (158.97 KB, patch)
2010-06-04 14:42 UTC, Petr Hejl
Details | Diff
improved patch 2 (195.75 KB, patch)
2010-06-11 08:38 UTC, Petr Hejl
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2010-03-18 09:29:38 UTC
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.
Comment 1 Petr Jiricka 2010-03-19 17:55:00 UTC
The following evaluation by Tomasz Slota is relevant: http://netbeans.org/bugzilla/show_bug.cgi?id=182313#c2
Comment 2 Alexey Butenko 2010-03-25 09:58:57 UTC
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
Comment 3 Petr Jiricka 2010-03-25 11:41:58 UTC
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.
Comment 4 Alexey Butenko 2010-03-25 14:11:23 UTC
(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.
Comment 5 Alexey Butenko 2010-03-25 14:46:43 UTC
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.
Comment 6 Petr Jiricka 2010-03-25 16:14:20 UTC
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.
Comment 7 Alexey Butenko 2010-03-25 16:22:40 UTC
(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.
Comment 8 Petr Jiricka 2010-03-25 16:35:26 UTC
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.
Comment 9 Alexey Butenko 2010-03-26 07:28:58 UTC
(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?
Comment 10 Quality Engineering 2010-03-27 06:15:58 UTC
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
Comment 11 Petr Jiricka 2010-04-02 07:58:59 UTC
No longer a P2 after Alexey's workaround, reassigning to Petr H as the server integration owner.
Comment 12 Petr Jiricka 2010-05-13 13:45:53 UTC
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.
Comment 13 Petr Jiricka 2010-05-14 14:41:18 UTC
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?
Comment 14 David Konecny 2010-05-16 22:50:46 UTC
(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.
Comment 15 David Konecny 2010-05-17 02:59:05 UTC
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?
Comment 16 Alexey Butenko 2010-05-17 10:44:33 UTC
Workaround removed:
see http://hg.netbeans.org/web-main/rev/0509b9e6e5be
Comment 17 Alexey Butenko 2010-05-17 11:02:26 UTC
(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.
Comment 18 Petr Hejl 2010-05-17 18:07:50 UTC
(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)
Comment 19 David Konecny 2010-05-17 18:44:17 UTC
(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?
Comment 20 Petr Hejl 2010-05-17 18:57:22 UTC
(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.
Comment 21 David Konecny 2010-05-17 22:41:56 UTC
(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?
Comment 22 Petr Hejl 2010-05-18 14:02:41 UTC
(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.
Comment 23 David Konecny 2010-05-18 18:43:17 UTC
(In reply to comment #22)
Fine with me.
Comment 24 Quality Engineering 2010-05-19 06:09:08 UTC
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:
Comment 25 Petr Jiricka 2010-05-19 09:41:53 UTC
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.
Comment 26 Alexey Butenko 2010-05-19 11:38:15 UTC
(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.
Comment 27 Petr Jiricka 2010-05-19 11:46:50 UTC
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
Comment 28 Alexey Butenko 2010-05-19 12:55:56 UTC
(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?
Comment 29 Alexey Butenko 2010-05-19 12:56:45 UTC
Created attachment 99203 [details]
patch
Comment 30 David Konecny 2010-05-19 19:01:07 UTC
(In reply to comment #29)
> Created an attachment (id=99203) [details]
> patch

Looks good. Thanks Alexey.
Comment 31 Alexey Butenko 2010-05-20 08:55:56 UTC
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).
Comment 32 Alexey Butenko 2010-05-20 10:19:44 UTC
Increasing to P1, since the warning message should be in 6.9
Comment 33 David Konecny 2010-05-20 20:04:49 UTC
(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)
Comment 34 Martin Schovanek 2010-05-24 14:53:04 UTC
The warning message verified in the trunk build by QE. Please transplant.
Comment 35 Alexey Butenko 2010-05-25 07:36:02 UTC
transplanted
http://hg.netbeans.org/release69/rev/ed1abd61b5c4
Comment 36 Alexey Butenko 2010-05-25 07:43:48 UTC
Downgrading back to P2 to request waiver.
Comment 37 Marian Mirilovic 2010-05-27 08:15:22 UTC
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.
Comment 38 Petr Jiricka 2010-05-27 08:38:52 UTC
> 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.
Comment 39 Marian Mirilovic 2010-05-27 11:42:34 UTC
(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
Comment 40 Petr Jiricka 2010-05-27 11:58:27 UTC
> 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.
Comment 41 Marian Mirilovic 2010-05-27 12:24:58 UTC
(In reply to comment #40)
> I don't, but I created it anyway - bug 186798.
Thanks Petr.
Comment 42 Petr Jiricka 2010-05-28 10:19:59 UTC
Waiver approved.
Comment 43 Petr Hejl 2010-06-02 15:02:39 UTC
Mini UI spec for JSF wizard: http://wiki.netbeans.org/WeblogicJSF
Comment 44 Petr Hejl 2010-06-02 15:05:59 UTC
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.
Comment 45 Petr Hejl 2010-06-02 15:23:06 UTC
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.
Comment 46 Petr Hejl 2010-06-02 15:24:02 UTC
Please review the j2eeserver API change.
Comment 47 David Konecny 2010-06-03 02:11:23 UTC
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.
Comment 48 Petr Hejl 2010-06-04 14:41:07 UTC
> 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.
Comment 49 Petr Hejl 2010-06-04 14:42:04 UTC
Created attachment 99822 [details]
imrpoved patch
Comment 50 Petr Hejl 2010-06-11 08:35:30 UTC
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.
Comment 51 Petr Hejl 2010-06-11 08:38:39 UTC
Created attachment 100004 [details]
improved patch 2
Comment 52 Petr Hejl 2010-06-15 08:23:50 UTC
For better regression testing I pushed the current patch to web-main 02ae7e2f505b.
More non-api changes will follow.
Comment 53 Quality Engineering 2010-06-16 03:29:07 UTC
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
Comment 54 Alexey Butenko 2010-07-08 13:35:46 UTC
Petr, it seems that your commit caused #188443, Could you take a look, please?
Comment 55 Petr Hejl 2010-07-08 19:11:44 UTC
Classpath handling - web-main 9e45cd1015cd.
Comment 56 Petr Hejl 2010-07-08 21:19:07 UTC
Small optimization - web-main 44c17a45e8ed.
Comment 57 Petr Jiricka 2010-07-09 13:30:46 UTC
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?
Comment 58 Petr Hejl 2010-07-10 11:21:48 UTC
(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.
Comment 59 Petr Hejl 2010-07-13 13:53:41 UTC
Initial library deployment (after project creation) should be fixed - web-main cb7f523dc6a6.
Comment 60 Quality Engineering 2010-07-14 02:44:19 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo