- This topic has 4 replies, 2 voices, and was last updated 19 years, 1 month ago by
.
-
Posts
-
I purchased your app and am just starting to use it for tomcat/jsp/struts
work.I’m going through the first tutorial for Struts and created the new project made the classes, etc . I note two things that are keeping it from working.
1. I’m pretty certain I told it to create with Struts 1.0 not 1.1, but all headers say 1.1 – I may not have however, so there probably isn’t a problem other than how to change versions in existing projects (see question at end).
2. also, web.xml was created with DTD stuff pointing to servlet version 2_4 instead of 2_3 (I’m running tomcat 4.1.x) – now this time, I’m very sure I specified the right version of Tomcat from the beginning so I’m not sure where this came from.
3. Finally the web.xml was not handed tablib statements for the taglibs that
were defined in the login.jsp page we created via the tutorial process.So, any idea what went wrong on these items? If I don’t hear from you quickly, I’ll start over and re-do the tutorial from scratch since it’s not that much lost work. But in case starting over still doesn’t work (or if in the future I want to alter the struts version, or the servlet versions in a fully established project) are there ways to do that w/o starting over? I assume so, but especially with struts, I see no way to remove it or modify the version.
PS: I note that this tutorial appears to be with an older version as the dialogs look much different, you might want to upgrade the tutorials at some point to bring them up to date.
Thanks! Looking forward to using MyEclipse once I get through the learning curve!
1. I’m pretty certain I told it to create with Struts 1.0 not 1.1, but all headers say 1.1 – I may not have however, so there probably isn’t a problem other than how to change versions in existing projects (see question at end).
There can be some pretty big changes between releases of frameworks, so we do not provide migration steps for moving a project from one framework version to another. Also I don’t think we ship Struts 1.0 libs with MyEclipse as it is 4 years old or so and not recommended.
2. also, web.xml was created with DTD stuff pointing to servlet version 2_4 instead of 2_3 (I’m running tomcat 4.1.x) – now this time, I’m very sure I specified the right version of Tomcat from the beginning so I’m not sure where this came from.
The problem here is when you created your Web Project, you left it as the default (J2EE 1.4, uses Web 2.4 spec file). What you can do is quickly create a new Web Project, select J2EE 1.3 then copy the header out of the web.xml file and put it in your file.
3. Finally the web.xml was not handed tablib statements for the taglibs that
were defined in the login.jsp page we created via the tutorial process.Please clarify “does not handle”. The web 2.4 spec file has a modified layout, you must wrap your taglib tags in jsp-config tags for 2.4 file, for 2.3 you don’t need that (which you may be used to).
are there ways to do that w/o starting over? I assume so, but especially with struts, I see no way to remove it or modify the version.
There are manual ways to do this, yes, but not automatic for the reasons I mentioned above.
ARGHH! Indeed, I had a mental dyslexic moment, and left it at J2EE 1.4 THINKING about Tomcat 4.1 version… that MAY be the root of all the issues. I’ll try again and see if starting with the correct versions just might cause an improvement on the entire situation!
HOWEVER, and I’m sure making version changes is a fairly big issue for the entire JSP community, not just the IDE environment, but the inability to morph at least a fair percentage a reasonably complex project from one version to another would seem to be a pretty major issue as this J2EE stuff matures. Of course it’s always been an issue anyway for all languages, so it’s nothing new, but the ability to at least do some auto-housekeeping for that sort of thing to handle a percentage of code and config changes would seem to be a good item for the “someday” list.
Thanks! I shall try again and be more careful this time in selecting versions.
Actually – there is one more thing you might want to add and that is warning if a deployment is selected that indicates a versioning mis-match. IE: a J2EE 1.4 probably should NOT be deployed to Tomcat 1.4 – when I or some other soul sleeping on the watch selects a deployment that isn’t kosher, that would be a nice time to at least warn them something smells fishy.
Actually – there is one more thing you might want to add and that is warning if a deployment is selected that indicates a versioning mis-match. IE: a J2EE 1.4 probably should NOT be deployed to Tomcat 1.4 – when I or some other soul sleeping on the watch selects a deployment that isn’t kosher, that would be a nice time to at least warn them something smells fishy.
You are correct, we do this now for EAR, EJB, Web projects (for example, if you create an EJB, notice that you cannot deploy it to Tomcat), but the checking should go deeper as you pointed out.
