This week's book giveaways are in the Cloud and AI/ML forums.
We're giving away four copies each of Cloud Native Patterns and Natural Language Processing and have the authors on-line!
See this thread and this one for details.
Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!

Jim J Anderson

Greenhorn
+ Follow
since Jul 15, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jim J Anderson


For some reason, the compiler/translator thinks that JSONObject is a package, not a class.



I thought this was a strange message, which led to my speculation. You are probably correct, but I'm not 100% convinced. I'm also guessing that the error is created during the translation from JSP to java. But again, just a guess.

Why is this code not in a servlet where it would be easier to debug? Putting Java code into a JSP is a bad practice that's been obsolete for over 16 years.



I have been working with JSP on and off for maybe 3 or 4 years now. Mostly experimenting and learning by trial and error. I was using an older text about JSP that has a lot of information and, logically, is probably organized pretty well.  But frankly, it never gave a good explanation on how to develop software using java and JSP. I bought another text a few weeks ago and from a tutorial point of view the new text is better. I would not recommend either text. I have not finished it yet, but I have already seen that writing servlets in java is the direction that I want to move. I could go on and on about how poorly JSP is documented, but I won't.

Anyway, thank you for your comment. It truly reinforces my thoughts about moving to servlets. I had not even thought about servlets making debugging easier. Since I work almost entirely on my own, improved debugging is VERY important to me. I spend far too much time debuggying, not developing. Historically, I'm a C/C++ and java developer and debugging software was never a major problem for me. Debugging in web site development is truly a different ball game. I'm going to start re-writing my examples, including this example, using servlets.

I am going to leave this thread open. Hopefully, after the weekend, I will return to close the issue, or to provide a re-written testcase.

Regards,
Jim
11 months ago
JSP
I am experimenting with JQuery ajax and $.get() methods. I have created a few examples, but the example I am currently working on is giving me an "internal error" message in my browser console window. I am using firefox 61.0.2, Tomcat 8  and jquery-3.3.1.js.

When I run this example, the console log prints out the request URL before giving the "internal error" message. If I enter that URL to my browser, the broswer gives the following error message:

HTTP Status 500 - Unable to compile class for JSP:

type Exception report

message Unable to compile class for JSP:

description The server encountered an internal error that prevented it from fulfilling this request.

exception

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: [14] in the generated java file: [/usr/share/apache-tomcat-8.0.50/work/Catalina/localhost/jjaora/org/apache/jsp/jja_005fexamples/result4_jsp.java]
Only a type can be imported. org.json.simple.JSONObject resolves to a package

An error occurred at line: 8 in the jsp file: /jja_examples/result4.jsp
JSONObject cannot be resolved to a type
5: <%
6:  String name = request.getParameter("name");
7:  String age = request.getParameter("age");
8:     JSONObject json = new JSONObject();



I believe this error is being caused because the jar file json_simple-1.1.jar is not being found. The jar file is being stored in /jjaora/WEB-INF/lib, where /jjaora is the context root for my example website. I have done some reading and my understanding is that if json-simple-1.1.jar is in the .../WEB-INF/lib directory, Tomcat should find and load it.

Assuming that not finding the jar file is my problem, can someone explain how I can coax Tomcat to find the file?

Here is the full result4.jsp file:



11 months ago
I'm sorry to take so long to respond, but that worked. Thank you!!

Is there a may to make this issue as 'resolved'?
11 months ago
I have be looking at this issue on and off for the past day and need some help. This is not a show stopper, just annoying.

I'm developing a web app using tomcat 8.0.50 and Eclipse oxygen. Eclipse is giving me the error message:



I get numerous error messages like the one above and I would like to turn off the caching, or enlarge the cache area to a large enough space that all the caching can be handled.

I looked at https://serverfault.com/questions/644415/tomcat-8-org-apache-catalina-webresources-cache-getresource and added:



to /usr/share/apache-tomcat-8.0.50/conf/context.xml.

Can someone help me with turning off the cache? Or enlarging it to handle the extra caching?
1 year ago

@Norm and Knute

Thanks for your input. As I mentioned, I was experimenting. My intent was to evaluate if there is any performance advantage to using applets vs other styles. The fact that the technology is fading away is a good reason to drop this experiment now. Throw in the security risks and it is even a better reason to stop here.

I will close this issue.

Jim
1 year ago

Hi,

I have been away from java for a few years, but I have been back to it for a few months now. I'm working on putting together a web site and I'm at the point where I'm experimenting with using Java applets in a web page. I spent many hours trying to get my own code working with applets, but no luck there. So, I decided to back up and go to examples that I knew, or at least I thought I knew, would work.

I dug out an example from Core Java Volume 1, edition 8, by Hortsmann and Cornell. The example is from chapter 2 of that book and is called 'WelcomeApplet'. There are 2 files, WelcomeApplet.java and WelcomeApplet.html. I compile the java file first. I then run 'appletviewer Welcome.html'. The html code is not displayed, but the applet comes up and displays as expected, meaning that a window pops up, the title is displayed, and two buttons with labels appear.

When I go to my browser (I tried using firefox and chrome), the applet comes up, but only the html is processed. The applet itself does not get processed. Thus, in the browser, I only see the html, but no buttons from the applet class.

I'm having the same problem with the example that I am having with my own code: I cannot get an applet tag in my html file to be processed by the browsers. I'm baffled and I figure I must be missing something obvious. It appears that when the applet tag is read by the browser, it is not finding the WelcomeApplet.class file, but that is a guess. My understanding is that with the html file and class file in the same directory, the class should be found.

I got the example code doing the following:

1) Go to http://horstmann.com/corejava.html
2) scroll down the page to the "Further Information" section
3) At the 2nd bullet item "Download Code:", click on "8th Edition" and download the zip file
4) unzip the downloaded file
5) change director to the v1ch02/WelcomeApplet directory from the unzipped code
6) The files WelcomeApplet.html and WelcomeApplet.java are there to be viewed

Comments and suggestions are most welcome.

Jim Anderson

1 year ago

User error!

In my script, I referred to my jar file as "Path.jar" and it should have been "Pack.jar", which is the name of the jar file. When I fixed that my test case ran as expected.
1 year ago

Thank you for taking the time to look, but I don't think I can re-create the problem for a Windows environment.
I wrote up 2 shell scripts today that illustrate the problem, but they need to be run on Linux/Unix.

Jim
1 year ago

Yes, I have tried that and it does not work for me. When I use the CLASSPATH environment variable things work like expect. When I use the -classpath option it does not work. I am questioning if there is a bug in jdk1.8 with the -classpath option.

Jim
1 year ago
When I run:

jar -tf Pack.jar



I get:

META-INF/
META-INF/MANIFEST.MF
george/washington/Pack.class



which looks correct to me.

Jim
1 year ago

Here is the package statement from Pack.java:

package george.washington;



I believe this should be the correct package statement, but that is one of the things I am trying to establish by building my test cases. My understanding is that to reference the class in the jar file, the path in the package statement,

george.washington

should match the path where it is stored in the jar file,

./george/washington

, where "." is the root of the jar file.

Jim
1 year ago
I have been away from my java project for about 4 years and I'm back working on it. I had forgotten a lot of java, but it is coming back pretty well. Anyway, I'm working to get Eclipse working with my code again and I have a number of errors in Eclipse having to do with not being able to find classes in my jar files. It all used to work, so I know I did it correctly once. In my development I have created a number of packages with path names, where the package statement might look like



All my java files in the 'MyXYZClass' are stored in a directory name "myxyzclass" and all java files in the directory contain the same package statement. I then package up the directory in a jar file named 'myxyzclass.jar'. So there is a one-to-one-to-one mapping of directories to packages to jar files.

So I'm battling with Eclipse to get it all correct again and after a number of tries, I decided I better try creating some simple test cases to try to isolate what works and what doesn't. The first test case when well and confirm that I was getting my mapping correct with package names and mapping the packages in the file system, w/o using jar files. In the 2nd test case, I introduced jar files and I think I have learned enough that I will be able to get my code working in Eclipse. My tact going back to Eclipse will be to rely on the environment variable CLASSPATH being set properly. But using the -classpath option of the 'java' command would be much more flexible.

I tried to attach my test case as a tar file and tried again as a zip file, but the system would not allow me to attach these files. I was surprised when I was not allowed to attach my README file either, so I'm going to past the README file in this message. If anyone would like the test case, let me know and I can provide it.

README:

I am using jdk1.8.0_152 downloaded from Oracle.

The description of what I did follows, but putting the cart before the horse, my questions are as follows:

   1) As near as I can tell, the -classpath option works with 'javac', but not with 'java'.
       Historically, it worked with both commands. Interestingly, when I look at the
       man page for java 1.8, the '-classpath' option is not documented. This is
       strange. When I look at other documentation for 1.8, it looks like the
       -classpath option is still part of 'java'. Is '-classpath' supported as a java option?
   2) In step 10, the classpath is set correctly in the environment and on the command line.
       I would expect this to run, but it does not. The program correctly prints out
       the CLASSPATH value, but setting -classpath on the command line upsets the
       apple cart. This seems to be a bug.  Can anyone explain this behavior?
   3) In step 12, the CLASSPATH environment variable is not set, but the command
       line -classpath option is set. I expect this to work, but as I mentioned above
       '-classpath' does not appear in the manpage. I consider this a bug also, but maybe I
       don't understand enough.
And a comment:
   I have had problems getting a handle on defining java packages and then inserting
   and using them in jar files. I wrote this simple example to try to get a better
   understanding. In the past, I have mostly used '-classpath' on the command line.
   It makes me wonder if this was a mistake. From this simple example, I am leaning
   toward never using the 'java' classpath option and setting and using the CLASSPATH
   environment variable, which seems to work and seems to be consistent with
   documentation. I have more experimenting to do to confirm this.



On Linux using bourne shell, I ran a shell script 'run' which calls java on a class name 'Caller'.

1) 2) 3) blah, blah, blah
4)  $ CLASSPATH=Pack.jar:. ### In the shell set the CLASSPATH environment variable:
   $ export CLASSPATH
5)  $ run   ### execute the 'run' command

       The output should be:

               Running: java Caller ### NOTE: classpath is not set on the command line
               classpath = Pack.jar:.
               Hello George

       The program ran correctly.

6)  $ CLASSPATH=""  ### In the shell, set CLASSPATH to an empty string
7)  $ run   ### execute the 'run' command

       The output is:
               Running: java Caller ### NOTE: classpath is not set on the command line
               classpath =
               Exception in thread "main" java.lang.NoClassDefFoundError: george/washington/Pack
                       at Caller.main(Caller.java:10)
               Caused by: java.lang.ClassNotFoundException: george.washington.Pack
                       at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
                       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
                       ... 1 more

       NOTE: The program ran as expected because the classpath was not set.

8) edit the 'run' command in the jarCaller directory and change it by adding '-classpath Pack.jar:.' to the java command line.

       The original version looks like this:

               #! /bin/sh

               echo Running: java Caller  ### NOTE: classpath is not set on the command line
               java Caller

               # echo Running java -classpath .:Path.jar Caller
               # java -classpath .:Path.jar Caller

       and the new version is:

               #! /bin/sh

               # echo Running: java Caller  ### NOTE: classpath is not set on the command line
               # java Caller

               echo Running java -classpath .:Path.jar Caller
               java -classpath .:Path.jar Caller
9)  $ CLASSPATH=Pack.jar:.  ### In the bourne shell reset the classpath
10) $ run   ### execute the 'run' command

       The output is:

               Running java -classpath Path.jar:. Caller
               classpath = Pack.jar:.
               Exception in thread "main" java.lang.NoClassDefFoundError: george/washington/Pack
                       at Caller.main(Caller.java:10)
               Caused by: java.lang.ClassNotFoundException: george.washington.Pack
                       at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
                       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
                       ... 1 more

               NOTE: The program did not run as expected. The program echoed the classpath as
                   'Pack.jar:.', but the program could not find the class

11) $ CLASSPATH=""  ### In the bourne shell reset the classpath to a null string:

12) $ run   ### execute the 'run' command

       The output is:
               Running java -classpath Path.jar:. Caller
               classpath =
               Exception in thread "main" java.lang.NoClassDefFoundError: george/washington/Pack
                       at Caller.main(Caller.java:10)
               Caused by: java.lang.ClassNotFoundException: george.washington.Pack
                       at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
                       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
                       at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
                       ... 1 more

               NOTE: The program did not run as expected. The program echoed the classpath
                       as a null string. I think this is correct because it is echoing the
                       value of environment variable CLASSPATH, which is indeed the null
                       string. However, the classpath argument is supposed to override
                       the environment variable, yet, the program still does not find
                       the class in the Pack.jar file.
1 year ago

OK, I got my test case working with my debugger (Eclipse). I wanted to document what worked and document why my test case was not working.

First what worked, assuming that I am starting with my test case, 'StuckLoop.java', and that it has been compiled with the javac debug option, '-g'.

1) Import the source code for the test case so that is viewable with the debugger. Set a break point at line 10 of the example.

2) Create a run configuration in the debugger. In Eclipse, this means select 'Run --> Debug Configurations' and filling out the form that pops up.
The entries that I used were:
name: stuck (the name could be anything)
project: stuckProject (the name could be anything)
Connection type: Standard (Socket Listen)
Connection Properties:
Port: 8787
Allow termination of remote VM (I left this unchecked)

3) After the information in step 2 is entered, click on the 'Debug' button. If you are in the Eclipse debug perspective, the upper left panel will
display that a thread has started and it will show that it is in the wait state (waiting for the remote JVM on port 8787).

4) Run the StuckLoop class with the following command:

/usr/share/java8/jdk1.8.0_20/bin/java -agentlib:jdwp=transport=dt_socket,address=8787,server=n,suspend=n,timeout=10 my.example.StuckLoop



NOTE: The above line assumes that StuckLoop.java has a package statement showing StuckLoop is in the 'my.example' package. This is package statement
is not included in the example provided.

Taking these steps, I was able to run the command in step 4 and the debugger stopped the program at the right place. It took a bit of time, maybe a minute or two,
to hit the break point since bebuggers are generally slow.


Why was my test case not working originally?

Well, I skipped step 3 and received the error message shown in my original post. My expectation was that when I ran the command, the program would run and
make a connection with the debugger when the debugger thread became available. That is how I would have implemented the connection, if I had written the
code, but it is what it is. I was confused by the message 'connection refused', which was not the case at all. The error message should have said 'debugger connector is
not available'.
4 years ago
@Gamini

Thanks for the suggestion, but I am running this on an internal network and there is not firewall between the machines.

I am running on an old o/s that needs to be upgraded. I'm going to upgrade and see what happens. I will try running it on another PC too.

Jim
4 years ago
Hi,

I use Eclipse for debugging. My real problem is that I would like to debug the server side java code of a web application that is running in Tomcat. I have been trying for a week or more to get that to work, but without success. But that is on hold because I saw that the tomcat Catalina log file is showing errors when I specify debug JVM options.

Before tackling that problem, I decided to create a simple test case that I can run on a remote server and then connect Eclipse from my local host to the remote server. I wrote a simple test class, 'StuckLoop.java', which runs just fine when I start it without debugging. However, when I try to run the test class so that it can be debugged, the jvm will not start and gives the following error message:

ERROR: transport error 202: recv failed during handshake: Connection refused
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [debugInit.c:750]
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
Abort



Here is my test class:



I run:

$JAVA_HOME/bin/javac StuckLoop.java

and then:

$JAVA_HOME/bin/java StuckLoop

where $JAVA_HOME is: /usr/share/java8/jdk1.8.0_20 and the program runs ok.

If I run:

$JAVA_HOME/bin/java -agentlib:jdwp=transport=dt_socket,address=8787,server=n,suspend=n,timeout=10 StuckLoop

then I get the error messages shown above. Note, that the command line options are those that I picked up off the internet. I have done a reasonable about of reading, and it looks like these options should work, but I am no expert and I'm looking to find out if my command line is formed correctly or if there are possible problems causing me error.

My first question is whether anyone else gets the same results that I do?

Assuming, the answer to my first question is yes, my second question is why does it fail and what can I do to fix it?

Jim A.


4 years ago