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.
Summary: | Bundling the JSF implementation in WAR archive for Maven projects does not work on WebLogic | ||
---|---|---|---|
Product: | javaee | Reporter: | Petr Jiricka <pjiricka> |
Component: | JSF | Assignee: | Alexey Butenko <alexeybutenko> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | alexeybutenko, dkonecny, kganfield, mfukala, mkleint, phejl |
Priority: | P2 | ||
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Petr Jiricka
2009-10-21 16:54:31 UTC
it's the jsf framework codebase that needs to use different api to add jsf jars/libraries to a project. reassigning. the maven part is reasonably trivial, see ContainerCPModifierImpl, and feel free to change that once you implement the logic of when to add on classpath only ad when add to war file as well. my reply from 174899: re : "As for packaging - the correct approach would be to add this library to the compilation classpath, but not to package it in the war file. Can this be done using the ClassPathExtender/Modifier APIs?" there is no such way in the CpExtender/Modifier API as far as I know. There's one way that always adds the "provided" scope dependencies (thus adds on classpath and not in war). See org.netbeans.modules.j2ee.core.api.support.classpath.ContainerClassPathModifier, using that one however requires changes on both sides of the contracts - see org.netbeans.modules.maven.j2ee.ContainerCPModifierImpl However i'm not sure that the "provided" scope is always desired. As I understood the problem it only affects j2ee 6 + gf 3, right? If you add provided scoped dep to the project and run on different app server you will get classnotfounds at runtime. re. "there is no such way in the CpExtender/Modifier API as far as I know" - true, that's why web project introduces its own API: org.netbeans.modules.web.project.api.WebProjectLibrariesModifier. Just mentioning it for record. Probably just adding JSF API (regardless of EE version) should be safe. In cases where JSF impl is missing on server user can add it themselves to project classpath. David what about JSF version, do you mean both 1.2 and 2.0? And do we need then to make JSF implementation available in Library Manager as separate library? re. "David [...] do you mean both 1.2 and 2.0?" - for JSF 1.2 (or any existing pre-EE technology my general approach is to leave everything as it was in NB 6.7 unless users were complaining about it. But I think the same approach we are implementing for JSF 2.0 is applicable for JSF 1.2 as well. re. "And do we need then to make JSF implementation available in Library Manager as separate library?" - let me think out loud for a minute about current state: in Ant based projects JSF framework has 3 options in Libraries panel - (1) use JSF on server (preferred option); (2) use registered library or (3) create a new library (these two options are for users who knows that their server either do not have any JSF - eg. Tomcat - or users who have to use different JSF version then available on server). Case (1) requires JSF API only; cases (2) and (3) requires both API and implementation. So far so good. Now, for Maven there are only options (2) and (3) because server is optional in Maven context. I'm guessing that Maven integration in NetBeans works like this: when option (2) is selected whatever is specified in libraries maven-pom volume is added to Maven's pom.xml. In that case I think that current NetBeans JSF libraries (JSF 1.2 and JSF 2) should keep JSF API and JSF IMPL in classpath volume but should have only JSF API in maven-pom volume. That would mean that users of Maven project can compile their sources and deploy them to server which most likely has JSF impl. And if server does not have JSF impl then user has to edit their pom.xml and add the JSF IMPL jar to runtime classpath by hand. Does it make sense what I'm saying? David, I've checked removing maven-pom value for JSF impl jar from library and it seems that it works, like you suggested. Milos, do you have any objections for removing maven-pom value for JSF impl jar? Wouldn't it happen that we will get issue http://www.netbeans.org/issues/show_bug.cgi?id=170990 back? Cc'ing also Marek - JSF impl is needed on the classpath because of the facelets editor, so check with Marek before making this change. We may not be able to do this because of dependency on Marek. Anyway, I don't feel strongly that this is actually a defect, if it turns out to be hard to do or labor intensive, feel free to change to ENHANCEMENT. alexey: well observed. If you have the jsf-impl jar in library classpath, but missing in maven-pom volume, you can eventually get the 170990 issue back. Not exactly the hanging problem (which was AFAIK fixed by another issues), but you will still get the maven support to attempt to find the jsf-impl jar (as it's in library classpath, but missing the pom-volume) in the repository index. Due to implementation details though, if there is still something defined in the maven-pom volume, it will be used. If maven-pom is missing, the other steps will be done.. Guys, please file an issue to web/jsf.editor if you are about the remove the jsf-impl.jar from the compile classpath. I do need to modify the code so the jsf-impl.jar is taken from the web.jsf20 library instead of from the server classpath. I agree with Petr that it is not worth to fix too much work (P4 or enhancement). Marek, do you use jsf-impl.jar in order to provide some editor features? Even if this issue will not get resolved it would be safer to use required impl JAR from IDE installation rather then from project classpath. I have excluded the jsf-impl and jsf-api jars from the facelets libraries scanner classpath in web-main#78ae1c52636d. Since the classloader's parent is the module one and the module depends on jsf20 library, the jars exposed from web.jsf20 library should be used now. changed to enhancement Need to change this back to (possibly waivable) P2 DEFECT because of bug 182282. Basically, JSF implementation bundled in WEB-INF/lib will not work on WebLogic; WebLogic's own implementation needs to be used instead, see this comment: http://netbeans.org/bugzilla/show_bug.cgi?id=182282#c12 This also means that JSF support in Maven is somewhat server-dependent, and we may need to encourage the user to set the server before adding JSF framework (so the IDE knows whether to add it on the packaging classpath, or just use provided scope). This is already the case for JPA, see also bug 178970. Changing the subject to capture the real issue and requestiong a waiver for NetBeans 6.9. The workaround is to modify the pom file to provide the correct packaging so it works on WebLogic. 6.9 waiver approved. So conclusion: Need to decide either include or not JSF implementation jar, and for what cases? (1) use JSF on server -- it is OK (2) use registered library -- here the main issue. According to the previous comments only JSF API can be left here. But Maven? What if we will add the note about Application Server like it is done in persistence? (3) is up to the user Did I miss something? I don't quite understand the question, but I'd say we need to look at the problems in this order: - It is becoming clear that the JSF configuration panel needs to be aware of the server, and must behave based on the currently selected server. See bug 188284. - When the server is known, we need to select the right default, so things work out of the box. - Then the next question is what will happen when the user changes the default. I am hesitating whether the IDE should do something to prevent the user from shooting himself in the foot, or whether it should just give her the freedom to screw up. Opinions? (In reply to comment #16) > I don't quite understand the question, but I'd say we need to look at the > problems in this order: > - It is becoming clear that the JSF configuration panel needs to be aware of > the server, and must behave based on the currently selected server. See bug > 188284. I mean that issue when written about providing note about Application Server. > - When the server is known, we need to select the right default, so things work > out of the box. > - Then the next question is what will happen when the user changes the default. > I am hesitating whether the IDE should do something to prevent the user from > shooting himself in the foot, or whether it should just give her the freedom to > screw up. Opinions? What about option like it is done for missing server or library? When the project is highlighted with an warning triangle, and resolve <some> problem... item appeared in popup menu for the project. It can be done when the JSF RI is not present in the classpath, this would work for Tomcat case, and for Maven Web App case. > What about option like it is done for missing server or library? When the
> project is highlighted with an warning triangle, and resolve <some> problem...
Yes, this could work.
Currently a big part of bug 182282 is implemented, i.e. for Ant projects, the user can choose which server library to use when using JSF on WebLogic. The same choice should be available also for Maven projects when WebLogic is set as the target server. Do we know how specifically to solve this? Integrated into 'main-golden', will be available in build *201007160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c03db73b2b0d User: Alexey Butenko <alexeybutenko@netbeans.org> Log: #175130: Bundling the JSF implementation in WAR archive for Maven projects does not work on WebLogic #188284: The IDE should warn the user when adding JSF and no target server is set Finally I've merged JSF libs back to add API with IMPL when choosing Registered libs option as we discussed in email. http://hg.netbeans.org/web-main/rev/17767f52f748 So it seems that we can consider the issue as fixed. There are some cases left such as javaee-web-api and jsf-api on EE6 Maven project, but IMO it should be filled separately. Added check box: package this library to WAR for maven+no server case http://hg.netbeans.org/web-main/rev/98fcd7ce6c85 Integrated into 'main-golden', will be available in build *201007170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/17767f52f748 User: Alexey Butenko <alexeybutenko@netbeans.org> Log: #175130: splitting JSF libs back. |