2005.May.12 late evening (original text: Blockages, and !! to-do list) (Then the next two days until into wee hours May.15, I went back and started doing the tasks and inserting notes as I went along.) Blockages: 1. Can't find any way to compile&run my own servlets on Linux or Windows. a. On Linux, deploytool is very very slow and doesn't work anyway. i. It takes a full hour to configure a simple jsp application, and 3-4 hours to configure a full EJB. ii. Two out of four applications, after all that time spent, the deployed J2EE application bombs out with some kind of error. iii. One out of the two that deploy correctly, after I edit the source and re-compile it, and I try update files and re-deploy, it says none of the files have changed, and fails to update the JAR or whatever to replace the class file I changed, and so it's impossible to ever make changes. The fourth, which is a simple jsp application, I can edit the jsp file in-place on the system area, avoiding the bug in update files in deploytool, but after I add just one line of code sometimes I get server errors that the compiled jsp file is missing. iv. I can't find any way to have a JSP call a HttpServlet via the dispatch-forwarding mechanism. The only way I've found that works is to explicitly say: <%@ page import="DispatcherServlet" %> <% dis.doGet(request, response); %> which is definitely not the correct way to call a HttpServlet! b. On Windows, I can run the sample programs, but javac doesn't work, claims there's no such class as javax.servlet etc., so there's no way I can write any code of my own patch it into the examples in-place. c. On Windows, I can't find the XML file that registers the various Tomcat applications, so it's impossible for me to write a new source file (even if I could somehow compile it) and run it. Avoiding the blockages: I plan to write a multi-UI interface that calls to a HttpServlet. The first thing each HttpServlet will need to do is modify the request object to convert from the specific UI to the common interface, by calling an adapter, and the last thing each HttpServlet will need to do is modify the response object to match the particular UI that is in use, by calling another adaptor. The response object will contain a Java object representing the desired form(s) and flowing text before/after/between the form(s), which will be converted by the response adapter to the appropriate UI mode. 1. For a swing GUI toplevel, the request and response objects will be instantiated and initialized, and then the HttpServlet will be explicitly called. The request adaptor might not have much to do except instantiate a session object if there wasn't one already. After return, the response adaptor will convert the abstract text&forms object to the equivalent structure of swing components inside a JPanel. The swing GUI toplevel will then install the newly-built JPanel into the browser-equivalent JFrame, replacing the previous JPanel from the previous request. 2. For a CGI toplevel, upon entry to the HttpServlet there will be no request or response object, but the CGI variables will contain the encoded HTML form contents. The adapter will decode the HTML form and instantiate the request object and session object, and put the decoded form into the request object. Then the HttpServlet will instantiate the response object. The response adapter will convert the abstract text&forms object to a string of HTML and dump it to standard output. 3. For a J2EE application, the request object with form contents and session object will come already fully formed, so the request adapter won't have to do anything. The response adapter will convert the abstract text&forms object to a string of HTML and write it to the out object within the response object. My immediate plans for working on this project, starting with swing UI: !! Modify one of the already-working JSPs to use the Reflection API to print out various information about the request object, so that I can know what the swing toplevel needs construct as request object before calling the HttpServlet, to make it's just like the J2EE request object, and so I can know what the request adapter needs to do to finish making the request objects the same. Do the same for an already-working sample HttpServlet from the tutorial download. Compare to make sure they are both using the same environment. (Started on that task May.14, see notes on it later in this file.) !! If possible, modify the DispatchServlet java file to likewise print out this important information, both now when running under the J2EE server, and later when running under the swing toplevel. !! Write the swing toplevel just enough to create a dummy request object, and call DispatchServlet and see if it prints out somewhat the same as before so I know the swing toplevel is working properly. !! Write the request adapter to finish making exactly the correct object, so the printout from DispatchServlet exactly matches from before (except that session IDs would be different each time of course). !! Design the abstract text&form object. Have the DispatchServlet construct a dummy abstract-text&form object for testing purposes. !! Design the relation between the abstract text&for object and the hierarchy of JPanels and controls, and write the software to do the conversion. !! Write a dummy version of the complete swing toplevel. It has a JFrame with one button. When it's pressed, all the stuff I mentionned above occurs (make request object, pass to DispatchServlet, run request adapter, run dummy code to make abstract text&form object, run response adapter, return control to toplevel, patch JPanel into JFrame and redraw screen). !! Write code to convert contents of swing components to form contents variables and install them in the request object, instead of making a dummy request object as before. Unfortuntely it's now bedtime so I won't be able to do any of this tonight. InProgress: First task from above, started 2005.May.14 10:52 PDT ... took nap ... working ... I see what the JSP gets is really a org.apache.catalina.connector.HttpRequestFacade object which apparently implements (*) HttpServletRequest which is suitable for passing to HttpServlets and JSPs. At 14:26 I see there's no way to make a HttpServletRequestWrapper object except by already having a HttpServletRequest object, so I'm trying to find a way to make *any* kind of HttpServletRequest, possibly that org.apache.catalina.connector.HttpRequestFacade kind of object if it has a default constructor... (skip over footnote) (*) Hey, while typing above,, I accidently stumbled on the keys in emacs and pulled up a page that in emacs shows "hello" translated to various languages, using Unicode, the English/European stuff working of course, and most others not, but several languages also working, including Hebrew, Japanese, Chinese, Korean. It's located at /usr/share/emacs/20.4/etc/HELLO Testing whether it has a default constructor... no, it doesn't This will be really difficult. Need nap at 15:20. ... Towards end of nap as I was recovering from exhaustion, I thought of a trick I might try: Take the existing org.apache.catalina.connector.HttpRequestFacade object from J.Random interaction with the working JSP, and serialized it to a file. Then later when I need to instantiate a HttpRequest object I'll just use that by reading the old one back instead of the current roadblock of being unable to make a new one because the only public constructor requires a similar object to already exist. Note: Summary of before-nap status: So long as I don't try to use any of the classes I wrote myself, calling the Java API from JSP works 100% of the time, so I could make rapid progress using the Reflection API to explore the innerds of various classes related to HttpServlets. I could just as well write code to do it from a standalone application, as I did for my simple utility that lets me type in a class name and get back a listing of the methods, but using a Web browser where control-R to refresh automatically recompiles and runs the updated JSP, is slightly less hassle than the other way. So now at 16:39 I'm going to see if that catalina...Request class has serializable objects... Hmm, when I ask getInterfaces() it doesn't give me serializable, but does give me org.apache.catalina.Request, so I'll see what parent interface it might have... none. Idea dead. Out of desperation, I tried to write my own class called DummyHttpServletRequest which implements javax.servlet.http.HttpServletRequest, but the compiler complains that in the package javax.servlet.http it can't find the name HttpServletRequest, and I have no idea why the API documentation claims that package has that interface. This is a roadblock at 17:33. Back to the idea of trying to find any J.Random stupid sample program that runs as a HttpServlet and actually works, so I could then incrementally strip out its guts and replace with my own code. Time to start up the deploytool so I can see what applications are currently installed under what names... 17:34...17:42 deploytool is finally started, took a full 8 minutes just to start, and now I can see what applications I've installed already... Only four JSPs, not any java-coded Servlets. So at 17:51 I'm going to see if I can find a suitable Servlet to try configuring and installing with deploytool... 15:56 I've looked through all the directories of examples, and there aren't any standalone J2EE applications except JSPs and EJBs. Looking in the tutorial HTML stuff as one last resort... the only sample application they tell how to install is bookstore1, which has nearly ten different applets, so I'd rather use a smaller application, but this is all I have to try, so at 18:04 I'm starting to follow the instructions... it's taken more than 1.5 hours, now 19:35, and I'm not quite finished with configuring the WAR file, continuing... it's now 20:02, and for the past several minutes I've been stumped !!! by how I'm supposed to do table 10-2 which shows entries that look like: [Web Component Name] [Servlet Class] [Component Alias] The instructions say "8.Add each of the Web components listed in Table 10-2. For each servlet, click the Add to Existing WAR File radio button and select Bookstore1WAR from the combo box. Since the WAR contains all of the servlet classes, you do not have to add any more content." But I can't find that table, and I can't find the radio button to add to existing WAR file and I don't know what combo box where I'm supposed to do this. It's now 20:22 and I'm still stuck here in the middle of configuring the application. ... Now 20:45 and I'm still stuck in the same place. I've looked all over bookstore1App and can't find that table I'm supposed to update, and ten minutes ago I clicked on the file bookstore1WAR to see what I can find there but it hasn't yet updated the screen for that switch, and I'm ready to give up. Now at 20:57 it's finally finished updating the screen to show the General pane of bookstoreWAR, which doesn't show the table I'm looking for, and there are eleven other panes, and I am not going to spend the next two hours waiting for them all to show. So I'm going to skip this step for now and go on to the next ... finished doing step 9, which took until 22:01, more than one hour just for that one step, deploytool is so very horrendously slow!! Moving ahead to next step 10 ... that went fast, but 11 (map to error page) is taking horrendously long, already 23:35, and still can't get it finished because clicking inside the box where I need to fix a mistake (the instruction for 11.e was misleading and I fell for it) doesn't put the cursor there so there's no way I can edit the field to fix my mistake. It's now after midnight, May.15 at 00:07, when I've finally figured out why I couldn't edit the text fields to fix my mistake: deploytool is programmed to require the mouse be hovering over the field I'm trying to edit. If I move the mouse (actually trackball on this laptop) cursor away from the field so I can see what I'm doing, it locks the field and ignores my keystrokes, but if I move the cursor back over the field so it's blocking my view, *then* it allows me to edit again. So anyway I finally finished step 11. Moving on to step 12, filters ... Step 12.k. is impossible to do because BookStoreServlet doesn't appear in the menu, only BannerServlet appears available to select, and once it's selected there's no way to get rid of it except to delete the entire filter entry. !!! Aborting this step, and skipping to 13 at 00:20 ... Done with 13 (context root) at 00:29. Next is actual deployment, but because I skipped several steps above it wouldn't be safe, so I have to stop now until I get help.