String class can't find split method: wrong java version?

[Tim Holloway]

Oh yeah. One other thing.

Stop tomcat. Delete the following:

1. warname directory under TOMCAT_HOME/work/catalina/localhost. Actually, you can probably safely delete everything under TOMCAT_HOME/work.

2. Everything under TOMCAT_HOME/temp

3. If you're deploying a ".war" file, delete the directory with the same name as the warfile (minus the ".war") from under the TOMCAT_HOME/webapps directory.

If you have leftover chunder in any of these places, it will get in the way.

[Steve Luke]

Tim Holloway wrote:... download and install a known good JDK .... Then set JAVA_HOME and run the catlalina.bat file so that the runtime environment is a known good setup. From there it should be possible to work towards the fancier stuff.

Julia - just to point it out - the order here is important
1) Install JDK
2) Set JAVA_HOME
3) run the catalina.bat

If you just change the JAVA_HOME then it is not guaranteed that the server will see that change after it has been installed and run.

[Tim Holloway]

Also one other thing. I had to dig for this one. Check TOMCAT_HOME/web.xml. You should NOT have anything with the word "compiler" in in set in the init-params for the servlet named "jsp". If you do, they'll override the defaults. If you copied over an old tomcat config, you might have gotten some stale stuff in there.

[Julia Shreiber]

Tim, Steve,
Thank you! Sorry for delay - I've not received notifications about your answers.

I've set JAVA_HOME and JRE_HOME, CLASSPATH, CATALINA_HOME, and _RUNJAVA, _RUNJAVAC, _RUNJAVAW;
deleted all under work and temp;
runned catalina.bat...

After that runned jsp page - and already 30 minutes waiting for response.

I'll post update here when it will give me something...

[Julia Shreiber]

After cleaning of work and temp directories, pages previously gave error now not found at all. Reinstalled Java - exception is thrown again, as it was.

Tim,
There is no web.xml in TOMCAT_HOME - in is in TOMCAT_HOME/conf; and there is no "compiler" in jsp servlet.

   
     <servlet>
        <servlet-name>jsp</servlet-name>
        <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
        <init-param>
            <param-name>fork</param-name>
            <param-value>false</param-value>
        </init-param>
        <init-param>
            <param-name>xpoweredBy</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>3</load-on-startup>
    </servlet>

[Tim Holloway]

Sorry about that. You are correct.

After all this, I do have do wonder if that machine isn't horribly corrupted in some way or other. You're talking about a basic low-level essential functionality that flat-out consistently malfunctions.

I know of no one else who has ever had a problem like that. And while it's possible that were I logged into the box itself I could find something simple and obvious to fix, you might just find it less trouble and expense to wipe the whole system and start all over again.

[David Newton]

Is there a system-level path setting? Have you done a find of, say, java*.eve, from the root level?

[Tim Holloway]

David Newton wrote:Is there a system-level path setting? Have you done a find of, say, java*.eve, from the root level?

There are 2 separate environments for Windows. One at the global level and one at the user level which can be set via the Control Panel/System applet. You can (and I do) set JAVA_HOME in one of them. However, if Tomcat is being run as a service - especially in a wrapper - there may be an entirely different place that it gets its JDK location from. For that, I'll have to recommend the old RTFM approach. I only remember the options imperfectly, as I don't run production servers on Windows myself. I suspect that the nation of Iran may be wishing they didn't either right now.

[Julia Shreiber]

Tim Holloway wrote:
I know of no one else who has ever had a problem like that. And while it's possible that were I logged into the box itself I could find something simple and obvious to fix, you might just find it less trouble and expense to wipe the whole system and start all over again.

Tim , thank you very much!!! Are you really can? If yes, I'll send you instructions in private message, well?

I added one more output: added into the code line:
out.println(System.getProperty("java.vm.version"));

the result is: 17.0-b17

It matches the following:

C:\Documents and Settings\julia>java -version
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b07)
Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing)

I.e., the jsp code works with right java version...

[Julia Shreiber]

We made here interesting test: put problem jsp file to "examples@ directory. Split works there! Now trying understand what's the difference...

[Julia Shreiber]

The problem is resolved: there was java40.jar file in lib directory. After removing it, split method works well. Thanks to Uri Saranga.

[Tim Holloway]

Julia Shreiber wrote:The problem is resolved: there was java40.jar file in lib directory. After removing it, split method works well. Thanks to Uri Saranga.

¡Ay! Just as well. In answer to your question, I can leap tall buildings with a single bound. But unlike Superman, I can't work for free. Still trying to make the "crush coal into diamonds" thing to work. In the mean time, I charge rates I consider appropriate for the expertise required, and that means it's usually cheaper to just nuke everything and start over these days. Tracking down a problem like that would take a few hours, too, since trusted components weren't trustworthy.

Glad to see you're finally online!

[Julia Shreiber]

Tim and team,
Thank you very very much for your help! I was not offline, just tried to collect more info during investigations... It was quite interesting. And I hope it will help to somebody in the future.