Picking up from after Labbook.May12.txt, it's now May.15
Early in the morning (last night) while having trouble sleeping,
I came up with an idea: Runtime checking of a class against an
interface, not the case of print/println I already did, but now
for HttpServletRequest and HttpServletResponse. So then I can
run a Servlet which has parameters of type Object but which does
runtime checking to make sure they are really suitable for treating
as if HttpServletRequest and HttpServletResponse respectively.
If the Servlet is running as a J2EE servlet application, then it
really will have parameters of that type. But if it's running under
a swing or CGI conversion rig, it'll have fake objects which act just
like they are HttpServletRequest or HttpServletResponse but in fact
they are my own hand-crafted classes where I can create the objects
from scratch. (I haven't been able to find any public constructors
for HttpServletRequest and HttpServletResponse, so I have no way to
create them on Linux where I have no way to run a Servlet.)
So during the day time May.15 I wrote CompareIntCls.java which
gets the list of methods from an interface and a class, sorts each,
and collates them to produce three lists:
- Those in the interface but not the class (violations of the class
implementing the protocol);
- Those in both the interface and the class, indicating correct
implementation of the interface but with 'throws' exceptions
not yet compared, and return type not yet compared (maybe I should
do that, and signal an exception if they aren't compatible?),
and maybe other subtle properties (public/private, static/instance)
that need checking.
- Those in the class but not the interface (indicating that I might
have written worthless code, if this is one of my minimal fake
substitutes for HttpServletRequest or HttpServletResponse), but
to be expected with an actual live HttpServletRequest or
HttpServletResponse tested against my very minimal interface spec.
Then I uploaded that file to show to the world, and updated my JavaClass
WebSite to better index the various files I've uploaded. It's now
23:25, past my best bedtime, so I'll do just a little bit more tonight.
I think I'll try to deploy the hello1 application, which consists of
two HttpServlets. Now 23:28 as I start the J2EE server ... done at 23:35,
next running ant ... done at 23:40, next starting deploytool ... done
at 23:49, next starting to adapt tutorial instructions to guess what
needs to be done for hello1 ... past midnight, got new application named
and got past intro screen of new web component, now Monday May.16 00:12,
now let's guess what to do next ... finished adding the web component
at 00:36, what's next? I'll skip step 8 (table 10-2) because I have
no idea where that's located in deploytool, and I'll skip 9 thru 12
because they aren't applicable to hello1. At 00:42, moving ahead with
step 13, context root ... at 00:46 that was done and I saved and
started deployment, at 00:48 it was done asking me to confirm which
application to deploy, at 00:50 it showed first progress (contacted
server), deployment done at 01:03 and I clicked OK button, 01:04
it finished refreshing main screen and I went to Netscape, 01:05 I
was able to guess at the URL and entered it, at 01:08 it finally
put up the greeting screen, I typed my name, clicked submit, but instead
of giving me the response form it gave me the original greeting form
again. Half-broken! Anyway, total time = 1:18 to configure it +
0:17 to deploy + 0:05 to run it to where it shows the initial greeting
screen = 1:40 grand total.
Now let me see if I can edit the source, recompile it, manually copy
the class file to the system area, and refresh screen, to effect
a change in that greeting form ... did edit&recompile, now looking
around, I see no isolated class files on system java area, but I see
three jar files associated with this application:
/usr/java/j2sdkee1.3/repository/adsl-63-192-44-196.roadguy.com/applications/
hello1App1116255081029.jar
hello1App1116255123405Server.jar
hello1AppClient.jar
I assume I would need to update the contents of at least one of those,
but which one? The other day I wrote come code to explore JAR files using
the API in java.util.jar.JarFile and java.util.zip.ZipEntry, and I should
be able to configure it to look into these JAR files... first jar file
doesn't have any regular class files, second ditto, third ditto, so I wonder
where the server is keeping the two class files, one of which actually
was run to make the initial greeting form? Bedtime at 01:55
May.16 07:15 PDT, half awake, ready to resume. I did a re-load of the Web
page, no good, not getting the change I made, so it's not getting the
class file directly from the build directory at runtime, it has that
copied to some system place as I always assumed. So I'm curious whether
there are *ever* files within those jar files on repository? The ones
for hello1 are all very small, about 4k, but some are larger:
-rw-rw-r-- 1 15600 Apr 26 15:59 conv2App1114556343819Server.jar
-rw-rw-r-- 1 11957 Apr 13 18:19 converterAppClient.jar
-rw-rw-r-- 1 18632 Apr 13 18:19 converterApp1113441343351Server.jar
(those times are GMT) so let me adapt my jar-examination program to see
what's in them...
These files within JAR file: conv2App1114556343819Server.jar:
Conv2.class
Conv2Home.class
Conv2Bean.class
Conv2Bean_EJBObjectImpl.class
Conv2Bean_RemoteHomeImpl.class
_Conv2Home_Stub.class
_Conv2Bean_RemoteHomeImpl_Tie.class
_Conv2_Stub.class
_Conv2Bean_EJBObjectImpl_Tie.class
These files within JAR file: converterAppClient.jar:
Converter.class
ConverterBean.class
ConverterHome.class
ConverterClient.class
_ConverterHome_Stub.class
_Converter_Stub.class
These files within JAR file: converterApp1113441343351Server.jar:
Converter.class
ConverterBean.class
ConverterHome.class
ConverterClient.class
ConverterBean_RemoteHomeImpl.class
ConverterBean_EJBObjectImpl.class
_ConverterHome_Stub.class
_ConverterBean_RemoteHomeImpl_Tie.class
_Converter_Stub.class
_ConverterBean_EJBObjectImpl_Tie.class
Summary, only the applications which are EJBs use such files. Looking
elsewhere for copy of class files for hello1 ...
/home/rem/TmpDowned/TestEE/j2eetutorial/examples/build/web/hello1/
has a copy of GreetingServlet.class, so I renamed that out of the
way and copied the new version in its place, and had Netscape reload
the Web page, no change, still the original version. So I have no idea
where the old version is cached that I might update it. So let's try
deploytool "Update files" to see whether that works any better than
it did with the other application (where it said nothing has changed
so it refused to update anything)... first I got rid of the copy of
the updated class file, and renamed the old version back in place, so
as to avoid confusing deploytool. Next, at 08:18, to ask deploytool
to update files ... at 08:22 it says it updated the file, so I saved
it and will now try to deploy again ... at 08:27 it showed first progress
(Contacted Server) ... at 08:33 it's done, I'll press OK button now ...
done. Now at 08:38 I'll have Netscape reload the page ...
A Servlet Exception Has Occurred
Exception Report:
javax.servlet.ServletException: Error allocating a servlet instance
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:606)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2314)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:368)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:995)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1088)
at java.lang.Thread.run(Thread.java:484)
Root Cause:
java.lang.ClassFormatError: GreetingServlet (Bad magic number)
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:486)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1484)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:851)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1230)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1113)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:790)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:602)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:215)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:246)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2314)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:368)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:995)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1088)
at java.lang.Thread.run(Thread.java:484)
Summary: It's impossible to modify a J2EE application and deploy it
again. The only legitimate thing that can be done is to rename the
folder containing those files, configure a whole new application using
those renamed files (which takes 1.5 to 6 hours or maybe even longer),
and deploy the new application, which takes one hour 40 minutes even
for the most simple "hello1" application.
So now it's time to get working on my multi-UI stuff so that I can use
a simple GUI interface to debug the application, with a turnaround
time of two minutes instead of two-to-six hours each time I change one
line of code and want to test it.
Well, let me first try a couple other ideas. First, I've undeployed the
hello1 application, and will try to deploy it again, hoping whatever was
confused will be fixed ... OK, past the confirmation of what application
to deploy at 09:21 ... finished at 09:28 and clicked OK button,
now to have Netscape reload page ... same error as last time:
A Servlet Exception Has Occurred
Exception Report:
javax.servlet.ServletException: Error allocating a servlet instance
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:606)
...
So let me go back to the hack whereby I have a JSP as the application
but patch it in-place to directly call a HttpServlet.doGet() method,
first need to find where I did that ... That was date/index3.jsp, but
at the point I stopped work on it several days ago all it did was give
me a blank screen, and write a file on /tmp/ which shows it really
did run. Now I need to modify it to output to the JSP 'out' stream...
The existing code in date/index3.jsp is:
<%@ page import="DispatcherServlet" %>