Bugzilla – Full Text Bug Listing
| Summary: | API and UI changes for adoption of Library Provider Framework | ||
|---|---|---|---|
| Product: | [WebTools] Java Server Faces | Reporter: | Gerry Kessler <gerry.kessler> |
| Component: | JSF Tools | Assignee: | Gerry Kessler <gerry.kessler> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | cameron.bateman, konstantin, leewas, raghunathan.srinivasan, robert_gallagher, spaxton, thebravoman |
| Version: | 3.1 | Keywords: | plan |
| Target Milestone: | 3.1 M7 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 250208 | ||
|
Description
Gerry Kessler
This all looks quite good. While we're talking about these changes to the facet installation page, can I bring up the rest of the UI area below the Library Provider section. Currently the rest of the fields are: JSF Configuration File JSF Servlet Name JSF Servlet Classname URL Mapping Patterns With the new library provider mechanism, at least some of the default values in these fields can be potentially confusing or even wrong. For example, one of the scenarios I'm going to implement a library provider for is a Portal server target. In that case, there is actually no Faces Servlet. My implementation code will remove a defined Faces Servlet (if necessary) before setting up a Faces Portlet, so I'm not really concerned about changing the behavior of the facet installer logic. But given the added power that library providers will have, could we consider removing these fields from the UI (at the very least the 2 middle values regarding the servlet registration)? It's completely fine that the facet install uses these default values to set up the project, but for the exceptional cases where a particular library provider will need to do something else it makes for a misleading UI. I suspect users hardly ever change these defaults in the facet config page anyway, so for the very few cases where the defaults won't satisfy, changing them in the already-created project doesn't seem like an unnecessary burden. Thanks for the input Scott. Although they are highly correlated, your comments refer more to the facet than to our adoption of the Libary Provider framework. Could I ask that you create a new enhancement request and outline your use case? How do you currently deal with portals/portlets, and how would you ideally prefer it to be handled? I've opened Bug 255097 for my comments in #1. I'm a WTP user and have one question. I use both a tomcat 6 and JBossAS (or full JavaEE5 featured server) for the JSF application development and testing. Tomcat 6 doesn't include JSF libarary and JBossAS does. So currently if I want to deploy to Tomcat 6, then J2EE module dependency needs to be checked, but to deploy to JBossAS, J2EE modulde dependency needs to be unchecked. So, my question is: Is it possible to the J2EE module dependency automatically be changed according to target runtime? If not, the feature, which automatically resolving the library dependencies according to target runtime, need to be added to the features of Library Framework. Thanks. > I use both a tomcat 6 and JBossAS (or full JavaEE5 featured server) for > the JSF application development and testing. Tomcat 6 doesn't include JSF > libarary and JBossAS does. So currently if I want to deploy to Tomcat 6, > then J2EE module dependency needs to be checked, but to deploy to JBossAS, > J2EE modulde dependency needs to be unchecked. > So, my question is: > Is it possible to the J2EE module dependency automatically be changed > according to target runtime? See Bug 254536 that tracks improving the JBoss adapter that ships with WTP to correctly specify that it is able to provide the required libraries for JSF and JPA facets. Note that the server adapter that is part of JBoss IDE (separate install - google it) does this correctly already. This work is effectively complete. One outstanding issue is being tracked by 255097. |