Dennis,
On 7/8/24 17:05, DdC wrote:
Still struggling launching my hck app on Win10 & tomcat 9.0.88.It
runs (dont laugh) on: XP/Win7 & tomcat 4.0.4 Linux-gnu & tomcat
6.0.32
Tomcat 9 ought to be able to run a Servlet-2.0-era application just fine
unless you use one or two things that have been deprecated and won't
work anymore (20 years later).
Tomcat 9.0.88 displays fine with localhost:8080.
Do you mean that the ROOT application ("Welcome to Tomcat") runs? I
wouldn't expect anything less.
What version of Java are you using, now? Hopefully it's at least 17 or 21.
App hck compiles OK (dont laugh) with a script
using:CLASSPATH=.;c:\tomcat4\j2ee.jar;c:\tomcat4\webapps\hck\WEB-INF\classes;c:\tomcat4\lib\
This isn't a script. Can you post the whole thing?
Starting subsequently tomcat4 hiccups with:<<<<<NOTE: Picked up JDK_JAVA_OPTIONS:
--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED
--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED08-Jul-2024 12:00:24.731 INFO [main]
org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/9.0.8808-Jul-2024
12:00:24.748 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Apr 9
2024 13:22:30 UTC08-Jul-2024 12:00:24.748 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log
Server version number: 9.0.88.008-Jul-2024 12:00:24.748 INFO
[main]org.apache.catalina.startup.VersionLoggerListener.log OS Name:Windows 10......08-Jul-2024 12:00:27.313
INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory
[C:\tomcat4\webapps\hck]08-Jul-2024 12:00:30.041 SEVERE [main]
org.apache.catalina.startup.HostConfig.deployDirectory Error deploying web application directory
[C:\tomcat4\webapps\hck] java.lang.IllegalStateException: Error starting child at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:690) at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:659)
atorg.apache.catalina.core.StandardHost.addChild(StandardHost.java:661)at... ... ...>>>>>
Why, oh why does this tomcat not accept what has been compiled withj2ee.jar??
This copy-pasta is very difficult to read. Can you sent it without ...
re-formatting or whatever else is going on with your email sender?
Your error does not contain the "real error". If there are 50 lines of
stack trace, please post them ALL. Otherwise it will not be possible to
tell what the root problem is.
You have a runtime error above and a compiler error below. It's tough to
follow your journey, here.
Definitely do not put j2ee.jar into your web application's WEB-INF/lib
directory.
Using the classpath without j2ee.jar: CLASSPATH=.;c:\tomcat4\webapps\hck\WEB-INF\classes;c:\tomcat4\lib\the
compilation of the hck app fails early
with:<<<<<c:\tomcat4\webapps\hck\WEB-INF\classes\com>javac *.javaZAjax.java:9: error: cannot
find symbolpublic class ZAjax extends HttpServlet { ^ symbol: class
HttpServletZAjax.java:12: error: cannot find symbol public void doGet (HttpServletRequest req,
^ symbol: class HttpServletRequest location: class ZAjax >>>>>
> Why, oh why is the servlet infrastructure not found?
This is what I'm seeing (roughly)
C:> SET CLASSPATH=.;c:\tomcat4\webapps\hck\WEB-INF\classes;c:\tomcat4\lib\
C:> CD c:\tomcat4\webapps\hck\WEB-INF\classes\com
C:> javac *.java
This is an unusual way to compile Java. Given the package structure, I
would expect that ZAjax.java begins with the line "package com;" (which
itself is weird, but 100% legal, just unexpected). Because of that, it's
in a directory called "com". I would usually see something like this:
C:> SET CLASSPATH=.;c:\tomcat4\webapps\hck\WEB-INF\classes;c:\tomcat4\lib\
C:> CD c:\tomcat4\webapps\hck\WEB-INF\classes\
C:> javac com\*.java
... plus any other sources you might have. Typically, one does not put
sources directly into the web application, but that's also 100% legal
and not a problem... just unusual.
What does your directory structure look like? How many .java files do
you have? What libraries to you need in order to compile?
Okay, I'm guessing that j2ee.jar contains a whole lot of stuff including
the Servlet APIs you need to compile against.
Your CLASSPATH only seems to reference the classes already compiled in
WEB-INF\classes. Including Tomcat's lib\ directory does nothing,
actually. Removing the j2ee.jar from the CLASSPATH causes compilation
failures because Java doesn't include the Servlet APIs in the core
API... you need a library for that.
You may be used to C where compiling (often) results in a binary
containing everything. That's not the case with Java. Think of Java .jar
files as being .dll files as well as .h and .lib files all rolled into
one: you can compile against foo.jar but then run with bar.jar as long
as the classes you referenced during the compile from foo.jar are
present and API-compatible with those in bar.jar.
So you are likely going to be able to compile using j2ee.jar in your
CLASSPATH or (better, IMHO), using Tomcat's servlet-api.jar instead.
At runtime, you will ALWAYS get Tomcat's servlet-api.jar which is why
you do not need to -- and indeed you must not -- include j2ee.jar in
your application's WEB-INF/lib directory.
Try using the file $CATALINA_HOME/lib/servlet-api.jar in your CLASSPATH
for compiling. That contains only the servlet-related stuff. You might
need more but "j2ee.jar" could be anything. CATALINA_HOME points to
wherever you have installed Tomcat. It looks like you are building
against Tomcat 4. Why not build against Tomcat 9? Or have you replaced
Tomxat in C:\tomcat4 with Tomcat 9?
BTW tomcat 8 is not available anymore, neither on the backup site ...
That's correct, Tomcat 8.5.x has been removed from the home page but the
documentation is still there and the downloads are still available if
you really want them. There is no reason to go back to Tomcat 8.5 so
continue with Tomcat 9.
Okay, I have found your project online including source. It's going to
take a bunch of work to get this going but it's not that bad. The major
effort will be that you can't use the "invoker servlet" anymore where
you make a call to "/foo.bar.Baz" and get your foo.bar.Baz servlet to be
called. You MUST explicitly-define each servlet and map them to URL
patterns these days.
If you know all the servlet names you know you need to make public, you
can just loop through them and do this:
<servlet>
<servlet-name>foo.bar.Baz</servlet-name>
<servlet-class>foo.bar.Baz</servlet-class>
</servlet>
// ... other <servlet> definitions ...
Then:
<servlet-mapping>
<servlet-name>foo.bar.Baz</servlet-name>
<url-pattern>/foo.bar.Baz</url-pattern>
</servlet-mapping>
// ... other <servlet-mapping> definitions ...
Put these into WEB-INF/web.xml with a proper XML envelope for web.xml.
For example:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd";
version="4.0">
(servlet stuff from above)
</web-app>
Note that I copied the header and footer of this XML document from
Tomcat's conf/web.xml file.
There are a whole lot of other recommendations I would have for your
application, but my guess is that you "just want to get it working"
before doing anything else.
-chris
dennis de
champeaux--------------------------------------------------------------
Home page: rs6.risingnet.net/~ddccMarketing site: www . OntoOO.comKindle
books: Side Effects: Impacts on the 21st
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48
Even if not
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7 9/11::
They had the Sun in their
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9
On Tuesday, May 21, 2024 at 08:38:02 AM PDT, Christopher Schultz
<ch...@christopherschultz.net> wrote:
Hello,
On 5/18/24 23:40, DdC wrote:
Gave up on installing 9.0.88. on Win10.
Why did you give up? ZIP installation is a single command (either via
CMD or UI shell). EXE installer is pretty straightforward, too. There's
also a third-party installer that has a few more features including the
ability to upgrade an existing installation. (I recommend against
upgrading an existing installation specifically, but that's not a
recommendation against that third-party installer.)
Do you mean you gave up trying to get your application running on it?
Succeeded with 10.1.23 andjdk-18.0.2.1.
Why Java 18? It's been EOL for years at this point. You should use Java
21 these days for anything new.
Did you know that Tomcat 10 is fundamentally different than previous
versions?
The lib directory has j2ee.jar, which I have used in earliertomcat versions.
What does j2ee.jar contain? That seems so unspecific as to be problematic.
Compilation of a system was OK apart from some warnings because Java
has changed since the code was written.
?
There is a web.xml file in WEB-INF.
Okay...
Invoking a servlet gives a 500 error with the ominous complaint:
class su.SUlogin cannot be cast to jakarta.servlet.Servlet
(su.SUlogin is in unnamed module of loader org.apache.catalina ...
) Looks like that my code is quite out of date.Any suggestion for a
fix?Going back to an earlier tomcat?
Did you read the migration guide for Tomcat 10.1?
I would highly recommend going back to 9.0 for the time being. If you
remove j2ee.jar, does your project compile? If not, what errors do you
get (missing classes, of course, but what major packages are missing)?
j2ee.jar sounds like an uber-jar with "everything we need in it" without
any specificity. You should replace that with modern, separate libraries
that support your application.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
