Serlvet (Solaris --> Windows XP Pro)

[program worker]

I suspect that there is problem in the serlvet codes (developed by
external software house) which is being run in external ISP's Sun
Solaris platform. I would like to set up a testing platform using
Windows XP Pro or Windows 2000 server. Please advise the feasibility
and procedure. Do I need to recompile and / or change the program
code of the serlvet classes before they can be migrated from Solaris
to Windows platfrom? In the Windows XP/2000, I need to have IIS
ready, installed Tomcat and how about Apache?

Thanks

 

[program worker]

Sorry for wrong spelling: Servlet.

 

[Sudsy]

I suspect that there is problem in the serlvet codes (developed by
external software house) which is being run in external ISP's Sun
Solaris platform. I would like to set up a testing platform using
Windows XP Pro or Windows 2000 server. Please advise the feasibility
and procedure. Do I need to recompile and / or change the program
code of the serlvet classes before they can be migrated from Solaris
to Windows platfrom? In the Windows XP/2000, I need to have IIS
ready, installed Tomcat and how about Apache?

I used to develop servlets on a Win95 (yes, you read that right!)
portable and run the class files on a SunSPARC 5 machine. No re-
compilation necessary at all. You just have to make sure that you
have any jar dependencies resolved.
As to your other question, Tomcat is all you need. It incorporates
a webserver which is enabled by default on port 8080.

 

[Juha Laiho]

(e-mail address removed) (program worker) said:

I suspect that there is problem in the serlvet codes (developed by
external software house) which is being run in external ISP's Sun
Solaris platform. I would like to set up a testing platform using
Windows XP Pro or Windows 2000 server. Please advise the feasibility
and procedure. Do I need to recompile and / or change the program
code of the serlvet classes before they can be migrated from Solaris
to Windows platfrom?

If the servlets read external files, there might be issues with path
separator characters (i.e. are path components separated by / or \).
Other than that, I don't foresee any great issues.

What you need are equivalent versions of Java environment and your
servlet engine (apparently Tomcat). Even a different servlet engine,
but just implementing the same version of servlet specification should
suffice, but if you can use the same servlet engine, things should be
a bit easier to set up. Be aware that the default character set and
thus the default encoding most probably are different on your production
and test systems, so unless you override this, you might see some
differences in behaviour.

In the Windows XP/2000, I need to have IIS ready, installed Tomcat and
how about Apache?

You should be able to get your test rig done just with Tomcat; no
absolute need for IIS or Apache in that set-up.

 

[program worker]

I'm already able to setup Tomcat in my Windows 98 SE machine. I'm
able to run both sample apps and copy & run the public website into
the Win98 machine. Since the public website's servlets are hardcoded
in http address, say, "http://www.amazon2.com/app/servlet/page2". I
need to resolve this. I have two approaches:
1) Modify the servlets, e.g., page1.java and change the address to
"http://192.168.0.101:8080/app/servlets/page2". Do the same for all
concerned servlets.
2) In my private network, create a /etc/hosts entry with 192.168.0.101
www.amazon2.com

I had tried method 2 and it seems okay. Please comment on this.
Moreover, please comment and suggest a good IDE debugger for servlet
development. Is Borland JBuilder an good option and how about IBM
Websphere?

 

[Sudsy]

program worker wrote:

2) In my private network, create a /etc/hosts entry with 192.168.0.101
www.amazon2.com

Just fine for your internal development.

I had tried method 2 and it seems okay. Please comment on this.
Moreover, please comment and suggest a good IDE debugger for servlet
development. Is Borland JBuilder an good option and how about IBM
Websphere?

Eclipse does a surprisingly good job of servlet debugging. I say
surprising as I didn't expect it to be able to handle the complexity
with such aplomb. You can say goodbye to System.err.println for
testing...