Dustin Marx

I am still using Struts 1.0.2 since 1.1 is just beta and we don't want to move to 1.1 until it is production-ready. We will then use the Validator that is bundled with 1.1. For now, though, we use the ActionForm classes that you mention in part to do what you mention. I believe that ActionFormBean is a class used internally by Struts and is not something you have to extend or otherwise concern yourself with. If you extend the ActionForm classes as you describe, thinks should work as you describe.
An interesting resource in seeing the different parts of Struts is at http://rollerjm.free.fr/pro/Struts.html and it talks a little about ActionForm and ActionFormBean. The names are confusing.

I have only been using Oracle9iAS-OC4J for a couple months, but have not noticed any significant "gotchas" so far. I have used Struts throughout the application with Java Server Pages and servlets without any problems. I think the fact that OC4J is Orion-based is a good sign.

One of the things I find to be particularly interesting about Jakarta and all of its sub-projects (Struts, Turbine, Velocity, etc.) is that they are the work of dedicated, intelligent people who happen to have strongly differing opinions about what is "best." In theory, anyone can participate in making these sub-projects happen and each project typically is affected by several different developers and users. It is interesting to me that there is so little overlap between sub-projects in most cases.

Ted Husted has a Struts FAQ kick-off that contains links to some user opinions about these differences. Specifically, go to the URL http://husted.com/about/scaffolding/kickstart.html#turbine to see some links to comparisons of Struts and Turbine. An alternate URL for the same information is http://www.jguru.com/faq/view.jsp?EID=471938 .

I recommend, if this is still a problem, that you make sure that your action class (com.mtp.store.action.CategoryAction) extends the Struts Action class. If it does not extend this class, you can get a message like the one you are seeing.

I was happy to find this thread since this is exactly what I need to do -- access session information inside a custom tag. However, I had to change the code slightly from that mentioned above to get it to work. I was required to directly access the pageContext data member rather than being able to go through a getPageContext() acccessor method because no such method was available for me. So, my code looked like this:
HttpSession session = pageContext.getSession();
I am posting this in case someone else is able to benefit from this thread as I have.

I have not read it, but I was impressed with the writing style and knowledge the author of that book has displayed in responses to messages in this forum during the week.

An article related to this is "Savor success with Java on the front end" by Alex Kalinovsky at http://www.javaworld.com/javaworld/jw-04-2001/jw-0420-swing_p.html .
In this article, Alex points out two performance issues plaguing XML applications today -- lack of tools for code generation (especially for stylesheets) and processing (parsing) speed. He ends the article with a section on "basic rules of thumb" for when to use HTML/JSP versus Java Swing versus XML/XSLT. I think the WebCream product he mentions is interesting -- it converts Java (AWT or Swing) into HTML dynamically.

The interesting thing is that, according to the "Developing Web Applications with Oracle JavaServer Pages" article, Oracle9i Application Server Release 2.0 will allow OSE to run outside of the database in Microsoft's JDK. The article then explains some reasons you might choose to run OSE in either the database JVM or in the JDK.

I notice that the latest edition "Oracle" magazine (May/June 2001) features two articles on JSP (starting on pages 117 and 125 respectively). The article "Dealing with JSP" talks about some advantages of running a servlet (or JSP) in the Oracle Servlet Engine (OSE). The other article focuses on JDeveloper 3.2's "custom BC4J Data Tags" and is called "Tag Your Way to JavaServer Pages Application Success."
The URL for this magazine is http://www.oracle.com/oramag/

JavaBeans are basically just Java classes that meet a few minor restrictions (such as having a constructor that accepts no arguments). This is one of the reasons I like moving Java syntax out of a JSP and into a JavaBean when possible -- the underlying JavaBean can be used by other non-JSP applications (any applications that can make use of Java classes). This is also why I try to make my Java custom tag handler classes as small as possible and have them utilize JavaBeans -- while the JavaBeans are as reusable as the functionality placed in them, Java tag handlers are really only usable by JSPs.

I understand that you can precompile JSPs now as well. The Java "Blueprints" at http://java.sun.com/j2ee/blueprints/packaging_deployment/tools/index.html even reports that this is a necessary requirement for a J2EE server to perform at deployment of a J2EE application.

J2EE Blueprints Best Practices and Architectural Recommendations http://java.sun.com/j2ee/blueprints/
(especially "Web Tier" section)
JSP Design Notes http://www.aurorainfo.com/wp8/
Understanding JavaServer Pages Model 2 Architecture http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc_p.html

Personally, I am more comfortable with having the application server handle all of the presentation side rather than deployment through the database. In the above message, I was just speculating on what might be some advantages of the latter, but I still prefer application server deployment. It just seems more natural to me.

I am not sure if this will answer what you are asking, but I'll give it a try.
The application server normally provides an EJB container and a JSP container and allows for you to change appropriate settings to let EJBs and JSPs communicate with one another. At that point, you can have Java directly in the JSP (or in a JavaBean used by the JSP) access EJBs as normal Java code does (getting the home interface, etc.).