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.

Bug 119406 - After project has been created, changing server will fail if they have different support for JSF
Summary: After project has been created, changing server will fail if they have differ...
Status: NEW
Alias: None
Product: javaee
Classification: Unclassified
Component: Web Project (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: David Konecny
URL:
Keywords:
Depends on:
Blocks: 111131
  Show dependency tree
 
Reported: 2007-10-18 19:53 UTC by _ potingwu
Modified: 2010-09-21 09:55 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ potingwu 2007-10-18 19:53:17 UTC 
After project has been created, changing server will fail if they have different support for JSF.

Steps:
1. Create a web project with JSF framework and target to GlassFish server
2. Deploy good
---
3. Change the server to Tomcat
4. Deploy failed because Tomcat does not have JSF support

We should plan this feature for post NetBeans 6.0. When switching server, the JSF libraries should also be updated. I
assign it to web/project instead of web/jsf is because there is no API for framework that can listen to 'server change'
event.
Comment 1 _ potingwu 2007-10-18 20:04:57 UTC 
Framework does need this listener (to get the 'server changed' event) not just for the JSF support. Please see
issue#111131, the JDBC resource will also need to be rescaned when server changed.
Comment 2 David Konecny 2007-10-22 08:34:37 UTC 
Why don't we always include JSF jars in 'web project with JSF framework' regardless of server being used?

In case of GlassFish the JSF jars would be there twice in runtime. But is that a problem? Customers who know they are
using GlassFish can remove extra JSF jars in project properties but out-of-the-box project would just work on both
Tomcat and GF. Actually, sooner or later it may be required anyway to keep JSF jars in project even in case of GF - e.g.
GF server running with JSF ver.Y but customer is using (older or newer) JSF ver.X and therefore needs to deploy the app
with their JSF version.
Comment 3 _ potingwu 2007-10-22 17:17:14 UTC 
Then users may need to maintain every copy of JSF libraries in each of their project instead of just go to their server
and replace it by the version they want.

Yes, 2 approaches are all acceptable as I think. But the point is not just the JSF libraries developers need to handle
when switching the target server. I.e., as I described, the JDBC resource is another issue. And the listener is still
needed.
Comment 4 David Konecny 2007-10-23 10:36:30 UTC 
Re. "JDBC resource, listeners" - agreed, there should be a support. Although we should carefully decide on scope of the
support. We should not spend too much resources on something what is (IMO) quite theoretical problem. On real life
projects you just have a server and you develop against that server and there is no need to change the server; sometimes
you may have different development server from production one; but these are almost all use-cases we should try to address.