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.
NB-big Dev (200704180000), JDK 1.5.0_12 I tried to create Enterprise | Enterprise Application project and found out there is no index.jsp file in EntepriseApplication-war|Web Pages folder. It used to be there some time ago, is it intentional ? We are using this file in performance test case "Measure Memory Footprint after J2EE Workflow", so if it will not be a part of the project we need to create another jsp file in our tests.
*** Issue 101731 has been marked as a duplicate of this issue. ***
it could be caused by the "fix" for issue 99555, have a look at it
sorry, i meant issue 99555
*** Issue 102456 has been marked as a duplicate of this issue. ***
Yes, it is a side effect of my "fix" of 99555. Before 99555 was fixed index.jsp was created for every web module. This is a problem when the user chooses a framework, because frameworks may want to create different welcome files. So creation of welcome files is now does in web project wizard after the frameworks are added. OTOH the enterprise app project wizard does not allow to add any frameworks into web module. The best solution would probably be to add a flag "boolean createWelcomeFile" into WebProjectCreateData and set it to true in EAR project, false in WAR wizard. The code for creation of index.jsp is now in NewWebProjectWizardIterator instantiate method, can be moved for example into WebProjectUtil and called from both NewWebProjectWizardIterator and from WebProjectUtilities.
since it's my regression I'll fix it
Why do you need a boolean value? Can't the web project let the frameworks create the welcome files first and create index.jsp if no welcome file has been created (or there are no frameworks in the project)? I see code in NewWebProjectWizardIterator that seems to do just that. Can't that code work, or am I just missing something?
AFAIK NewWebProjectWizardIterator currently has no way to indicate which of created files is the welcome page. The new approach seem to assume that only one presentation-layer framework will be used, which is kind of regression. The old approach was that newly added frameworks were patching index.jsp and putting a reference to their own welcome page. I like it better (not the way it was implemented though), because it enabled users to combine arbitrary set of frameworks that (normally) don't know anything about each other.
> AFAIK NewWebProjectWizardIterator currently has no way to indicate which of > created files is the welcome page. That is of course not true. Welcome pages are added into web.xml so they can be detected by NewWebProjectWizardIterator. Did you find this not working? > The new approach seem to assume that only one presentation-layer framework > will be used, which is kind of regression. Not true again, if framework does not add any welcome page then the default index.jsp will be added. Did you test and find this not working? > The old approach was that newly added frameworks were patching index.jsp and > putting a reference to their own welcome page. I like it better (not the way > it was implemented though), because it enabled users to combine arbitrary set > of frameworks that (normally) don't know anything about each other. The old approach was not good for the case when there is on framework, for example JSF or visual JSF, which is IMHO the most typical case. Then the index.jsp is not useful for anything because these frameworks create their own page. The original index.jsp with links to all framework welcome pages is IMO not useful for real application, there will always be one welcome page for the whole app.
Andrei: the code in NWPWI works (I hope:) but the problem is that it is not called when the enterprise project calls WPU.createProject(). In that case no welcome page is created.
sorry, I had my own vision of the term "welcome page" and I didn't make it clear: - there is exactly one entry-point (index) page per project - there may be multiple framework-specific "hello, world" pages (I saw them as "welcome pages" too) >> AFAIK NewWebProjectWizardIterator currently has no way to indicate which of >> created files is the welcome page. >That is of course not true. Welcome pages are added into web.xml so they can be >detected by NewWebProjectWizardIterator. Did you find this not working? - in the end only one of the welcome pages will be shown (the last or the first added). I would rather see index of all the welcome pages - one cannot specify a welcome page located in a subdirectory of the content root using web.xml - one cannot rely on the order of calling the extend() method for particular frameworks >> The new approach seem to assume that only one presentation-layer framework >> will be used, which is kind of regression. >Not true again, if framework does not add any welcome page then the default >index.jsp will be added. Did you test and find this not working? I was concerned about the case when *more than one* framework adds a welcome page >> The old approach was that newly added frameworks were patching index.jsp and >> putting a reference to their own welcome page. I like it better (not the way >> it was implemented though), because it enabled users to combine arbitrary set >> of frameworks that (normally) don't know anything about each other. >The old approach was not good for the case when there is on framework, for >example JSF or visual JSF, which is IMHO the most typical case. Since we offer *multiple* choice for the frameworks to be used, we should not assume there will be no more than one. I agree this is what happens in most cases today, but there is a good chance that it changes in the future >Then the index.jsp is not useful for anything because these frameworks create their own page. The original index.jsp with links to all framework welcome pages is IMO >not useful for real application, there will always be one welcome page for the >whole app. I think index and welcome pages are useful for developers to kick-start, get educated about capabilities of the frameworks used. They don't have to be a skeleton of production-quality application. PS. My concerns are inspired by the experience of working on the GWT support plugin
Your vision is what was implemented, but it is confusing for the single framework (typical) case, e.g. you get index.jsp + Page1.jsp created for visual JSF framework. That is why I changed it. I agree that the multiple frameworks case cannot be completely ignored. OTOH, creating index.jsp with links to all framework welcome pages does not make much sense for the user. The user will want to have ONE welcome page in the end. The welcome file list is a list only to cover the case when some of the pages do not exist, if all pages on the welcome file list exist then first will be used so there is no point in adding multiple. I think then when using multiple frameworks the user will have to decide what she wants for the welcome page. I think that even if we did some complicated logic about combining frameworks chances are we would not cover all the corner cases and all combinations. In any case, this is IMO wasted effort as the user will always change it later so in real life it will only save a tiny amount of time (or none) to the user.
I think the discussion here is about something else, than the issue is itself. It's true that we support adding multiple frameworks at once, but I think it's not so common. If you feel that is it important to discuss this, please create a new issue.
I agree with Pavel in desc13. However, I would like to make sure that if more welcome pages get created, they will always be created in the same order for the same set of frameworks. Probably just ordering the frameworks by their names would do (perhaps it's already being done, haven't looked). Re. desc11: ah, I see. You could probably refactor the code to an ensureWelcomePage() method called by both NWPWI and WPU But I still don't see a reason for the boolean flag, and I would prefer that it be avoided if possible.
Andrei, the code to create welcome file cannot be called in createProject unconditionally because createProject is called from NWPWI before the frameworks are added. I can add ensureWelcomePage() that will be called after createProject() (and after adding frameworks from NWPWI) to avoid adding the flag, not a big deal.
I'm sorry, I should have looked at this more carefully. I didn't realize createProject() was called from NWPWI. Now I also see that ensureWelcomePage() would have to be in WPU, and WPU clients must know they must call it. Yes, I know we control the clients. Still, consider the following alternative: split WPU into WebProjectUtilitiesImpl and API WPU simply delegating to WPUI. WPUI contains methods like createProject() and ensureWelcomePage(). NWPWI calls just WPUI.createProject(). WPU.createProject() calls both WPUI.createProject() and WPUI.ensureWelcomePage(). No change visible to the clients of WPU. But I understand if this looks unnecessarily complicated to you -- in that case the boolean flag with a default value of true is probably the best alternative. Sorry again for the mess.
I just fixed this issue by adding the ensureWelcomePage(). The friend API can be improved later if needed. /cvs/web/project/src/org/netbeans/modules/web/project/api/WebProjectUtilities.java,v <-- WebProjectUtilities.java new revision: 1.15; previous revision: 1.14 /cvs/web/project/src/org/netbeans/modules/web/project/ui/wizards/NewWebProjectWizardIterator.java,v <-- NewWebProjectWizardIterator.java new revision: 1.28; previous revision: 1.27 /cvs/j2ee/earproject/src/org/netbeans/modules/j2ee/earproject/ui/wizards/NewEarProjectWizardIterator.java,v <-- NewEarProjectWizardIterator.java new revision: 1.22; previous revision: 1.21
verified in 200705040000