tomcat on mac os 10 with virtual PC

[Girish Baxi <gb...@digitalconcepts.com>]

hi

was wondering if anyone has tried installinbg tomcat on mac os 10 with
virtual PC .... i have been having hard time doing it .....

any inputs are most welcome

thanx in advance

Re: tomcat on mac os 10 with virtual PC

[Gary W Propp <Ga...@syntegra.com>]

Tomcat runs fine on OS X. Unless you have lots of memory and a fast 
machine virtual PC is slow on OS X.

Girish Baxi wrote:

> hi
> 
> was wondering if anyone has tried installinbg tomcat on mac os 10 with
> virtual PC .... i have been having hard time doing it .....
> 
> any inputs are most welcome
> 
> thanx in advance

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Erik Weber at eweber@cimedia.com wrote:
> 
> Pier, nice solution. Sort of a Servlet implementation of the adapter pattern.

And it works on ALL servlet engines :)

> So you're saying just make the service() method throw an exception, no
> questions asked?

Or use a filter that is not bound to any URL pattern (but that's only
available on servlet 2.0). Check out the servlet spec (2.2 or 2.3, depending
on what platform you need to need to deploy your app on).

> Also, you were quick to fire off about portability, and I agree, but when you
> work in a WebLogic shop . . . Well, it has some nice features. :)

That's why you go off to a shop and but WebLogic for a few thousand $$$. :)

> I hope to 
> discover Tomcat's strengths as well in the near future, now that my company
> plans to use it in a limited production role as well.

Tomcat is the R.I.. A very good one. Concerning API functionalities, Tomcat
will provides few things (interceptors, valves). Other features are
available and will be built in the future, but just remember the tradeoff of
building on top of that, despite of relying on what's provided you by the
platform (those APIs implemented by all vendors)

> All, I would still be interested in hearing any other ideas on the "startup
> class" problem.

    Pier

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Erik Weber at eweber@cimedia.com wrote:

> This is a good discussion.

Indeed...

> I would like to introduce the question: How much work is it to undo the
> platform dependency, and is it worth the liability to take advantage of a nice
> feature of the server?

Depends on what you need to do... If all you need to do is create instances
of objects for your web app, that's the way to go... If you're building a
web app to control your servlet-container, DOH! you need to build around its
APIs :)

A wise approach when designing a web application is examine your
requirements and see, wether it's worth to tie your app down to a container,
or abstract above it... Every problem is different...

> Specifically, would the interceptor approach offer significant benefits over
> the Servlet adapter approach? And how much work would it involve (potentially)
> to adapt the interceptor approach to some other unnamed platform if needed?

Dunno much about interceptors and TC3x...

Re: Such a thing as server startup class?

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 6 Aug 2001, Erik Weber wrote:

> This is a good discussion.
> 
> I would like to introduce the question: How much work is it to undo
> the platform dependency,

How does one do this without insisting that all containers implement the
same APIs with the same behavior?

Oh, yeah, it's already been done in 2.3 with application event
listeners.  :-)

> and is it worth the liability to take
> advantage of a nice feature of the server?
> 

That's always a "risk versus reward" tradeoff.  If I were a malicious
platform vendor, I'd do everything I could to encourage you to utilize my
platform specific stuff and get locked in.

On the other hand, I might be very customer-sensitive and want to provide
you a bunch of cool features above and beyond the spec so that you can be
productive ... but they only work on my platform.

Whether it's worth the risk or not is totally up to you ... there's no pat
answer.

> Specifically, would the interceptor approach offer significant
> benefits over the Servlet adapter approach? And how much work would it
> involve (potentially) to adapt the interceptor approach to some other
> unnamed platform if needed?
> 

If the "unnamed platform" is open source, you could theoretically do this.  
If not, are you planning to decompile the bytecodes so that you see how it
works, and then figure out how to hack the insides to use your additional
functions?

The only way to rely on a platform-independent feature is to have it in
the spec.

> -Erik
> 

Craig


> 
> 
> "Pier P. Fumagalli" wrote:
> 
> > Filip Hanik at mail@filip.net wrote:
> >
> > > For Tomcat 3.x, you can create an interceptor to act as a startup class.
> > > you can just configure it using the server.xml file, read more about this in
> > > http://www.filip.net/tomcatbook/TomcatInterceptors.html
> >
> > Again, this would be unportable to other containers... My reasoning is that
> > Erik needs some functionality for a web application that will allow his code
> > to be 100% portable on all possible servlet containers.
> >
> > Using tomcat interceptors is exactly like using Weblogic's startup classes,
> > unportable. That's why I'm not a fan of interceptors (or valves in Tomcat
> > 4.0), or ANY other unportable feature.
> >
> >     Pier
> 
> 

Re: Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

This is a good discussion.

I would like to introduce the question: How much work is it to undo the platform
dependency, and is it worth the liability to take advantage of a nice feature of
the server?

Specifically, would the interceptor approach offer significant benefits over the
Servlet adapter approach? And how much work would it involve (potentially) to
adapt the interceptor approach to some other unnamed platform if needed?

-Erik



"Pier P. Fumagalli" wrote:

> Filip Hanik at mail@filip.net wrote:
>
> > For Tomcat 3.x, you can create an interceptor to act as a startup class.
> > you can just configure it using the server.xml file, read more about this in
> > http://www.filip.net/tomcatbook/TomcatInterceptors.html
>
> Again, this would be unportable to other containers... My reasoning is that
> Erik needs some functionality for a web application that will allow his code
> to be 100% portable on all possible servlet containers.
>
> Using tomcat interceptors is exactly like using Weblogic's startup classes,
> unportable. That's why I'm not a fan of interceptors (or valves in Tomcat
> 4.0), or ANY other unportable feature.
>
>     Pier

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Filip Hanik at mail@filip.net wrote:

> For Tomcat 3.x, you can create an interceptor to act as a startup class.
> you can just configure it using the server.xml file, read more about this in
> http://www.filip.net/tomcatbook/TomcatInterceptors.html

Again, this would be unportable to other containers... My reasoning is that
Erik needs some functionality for a web application that will allow his code
to be 100% portable on all possible servlet containers.

Using tomcat interceptors is exactly like using Weblogic's startup classes,
unportable. That's why I'm not a fan of interceptors (or valves in Tomcat
4.0), or ANY other unportable feature.

    Pier

RE: Such a thing as server startup class?

[Filip Hanik <ma...@filip.net>]

For Tomcat 3.x, you can create an interceptor to act as a startup class.
you can just configure it using the server.xml file, read more about this in
http://www.filip.net/tomcatbook/TomcatInterceptors.html

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
filip@filip.net
www.filip.net

>-----Original Message-----
>From: eweber@mail.cimedia.com [mailto:eweber@mail.cimedia.com]On Behalf
>Of Erik Weber
>Sent: Monday, August 06, 2001 4:24 PM
>To: tomcat-user@jakarta.apache.org
>Subject: Re: Such a thing as server startup class?
>
>
>Pier, nice solution. Sort of a Servlet implementation of the
>adapter pattern. So
>you're saying just make the service() method throw an exception,
>no questions
>asked?
>
>Also, you were quick to fire off about portability, and I agree,
>but when you work
>in a WebLogic shop . . . Well, it has some nice features. :) I
>hope to discover
>Tomcat's strengths as well in the near future, now that my company
>plans to use it
>in a limited production role as well.
>
>All, I would still be interested in hearing any other ideas on the
>"startup class"
>problem.
>
>-Erik
>
>
>
>"Pier P. Fumagalli" wrote:
>
>> Erik Weber at eweber@cimedia.com wrote:
>>
>> > Hello all.
>> >
>> > I have minimal experience with Tomcat, and didn't see any
>mention of this in
>> > looking over the docs.
>> >
>> > I am used to developing in WebLogic. WebLogic supports what
>are called startup
>> > classes. You register the name of the class in the server's
>properties file,
>> > and when the server starts, it instantiates that class with
>arguments included
>> > in the properties file.
>> >
>> > I have found this is a nice way to start up asynchronous
>subscribers to a
>> > messaging queue. Upon instantiation, which again is automatic,
>the various
>> > subscribers, in their constructors, simply register themselves
>as listeners
>> > with the queue.
>> >
>> > I was wondering if Tomcat supports a similar construct as this (startup
>> > classes). If not, perhaps I could implement my queue
>subscribers as Servlets,
>> > but this seems strange, considering mulitple threads should
>not be running
>> > through a single subscriber.
>> >
>> > Any thoughts or advice on this?
>>
>> That's what you get when you rely on features specific to a
>specific Servlet
>> container... My advice would be to use all your object as is, and have a
>> servlet overriding the service() method throwing an HTTP error,
>and so use
>> the init() and destroy() methods in that servlets to instantiate all your
>> objects... You can use servlet properties to provide the class names and
>> mimic the behavior of Weblogic, but then your web application will be
>> portable to any compliant servlet container.
>>
>> Oh, and, of course, remember to initialize the servlet at startup :)
>>
>> Being "the" reference implementation, I wouldn't want to
>populate Tomcat's
>> core with unportable features. If it runs under Tomcat, it runs
>everywhere
>> :)
>>
>>     Pier
>
>

Re: Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

Pier, nice solution. Sort of a Servlet implementation of the adapter pattern. So
you're saying just make the service() method throw an exception, no questions
asked?

Also, you were quick to fire off about portability, and I agree, but when you work
in a WebLogic shop . . . Well, it has some nice features. :) I hope to discover
Tomcat's strengths as well in the near future, now that my company plans to use it
in a limited production role as well.

All, I would still be interested in hearing any other ideas on the "startup class"
problem.

-Erik



"Pier P. Fumagalli" wrote:

> Erik Weber at eweber@cimedia.com wrote:
>
> > Hello all.
> >
> > I have minimal experience with Tomcat, and didn't see any mention of this in
> > looking over the docs.
> >
> > I am used to developing in WebLogic. WebLogic supports what are called startup
> > classes. You register the name of the class in the server's properties file,
> > and when the server starts, it instantiates that class with arguments included
> > in the properties file.
> >
> > I have found this is a nice way to start up asynchronous subscribers to a
> > messaging queue. Upon instantiation, which again is automatic, the various
> > subscribers, in their constructors, simply register themselves as listeners
> > with the queue.
> >
> > I was wondering if Tomcat supports a similar construct as this (startup
> > classes). If not, perhaps I could implement my queue subscribers as Servlets,
> > but this seems strange, considering mulitple threads should not be running
> > through a single subscriber.
> >
> > Any thoughts or advice on this?
>
> That's what you get when you rely on features specific to a specific Servlet
> container... My advice would be to use all your object as is, and have a
> servlet overriding the service() method throwing an HTTP error, and so use
> the init() and destroy() methods in that servlets to instantiate all your
> objects... You can use servlet properties to provide the class names and
> mimic the behavior of Weblogic, but then your web application will be
> portable to any compliant servlet container.
>
> Oh, and, of course, remember to initialize the servlet at startup :)
>
> Being "the" reference implementation, I wouldn't want to populate Tomcat's
> core with unportable features. If it runs under Tomcat, it runs everywhere
> :)
>
>     Pier

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Erik Weber at eweber@cimedia.com wrote:

> Hello all.
> 
> I have minimal experience with Tomcat, and didn't see any mention of this in
> looking over the docs.
> 
> I am used to developing in WebLogic. WebLogic supports what are called startup
> classes. You register the name of the class in the server's properties file,
> and when the server starts, it instantiates that class with arguments included
> in the properties file.
> 
> I have found this is a nice way to start up asynchronous subscribers to a
> messaging queue. Upon instantiation, which again is automatic, the various
> subscribers, in their constructors, simply register themselves as listeners
> with the queue.
> 
> I was wondering if Tomcat supports a similar construct as this (startup
> classes). If not, perhaps I could implement my queue subscribers as Servlets,
> but this seems strange, considering mulitple threads should not be running
> through a single subscriber.
> 
> Any thoughts or advice on this?

That's what you get when you rely on features specific to a specific Servlet
container... My advice would be to use all your object as is, and have a
servlet overriding the service() method throwing an HTTP error, and so use
the init() and destroy() methods in that servlets to instantiate all your
objects... You can use servlet properties to provide the class names and
mimic the behavior of Weblogic, but then your web application will be
portable to any compliant servlet container.

Oh, and, of course, remember to initialize the servlet at startup :)

Being "the" reference implementation, I wouldn't want to populate Tomcat's
core with unportable features. If it runs under Tomcat, it runs everywhere
:)

    Pier

Re: Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

Thank you for all the thoughtful suggestions.

I may or may not be able to talk my engineers into trying 4.0. :)

-Erik

"Pier P. Fumagalli" wrote:

> Erik Weber at eweber@cimedia.com wrote:
> >
> > The upshot of this is, that it might make the interceptor (startup class)
> > solution more appealing, even though it isn't platform independent. That is,
> > until Servlet 2.3 implementations are stable.
> >
> > Any thoughts?
>
> Well... You have to trust me on this one... But the Servlet 2.3 reference
> implementation _is_ very stable :) (AKA, Tomcat 4.0! :) And so is the spec.
>
> Just consider it as a hint from a very close friend who has some insight
> information :)
>
>     Pier

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Erik Weber at eweber@cimedia.com wrote:
> 
> The upshot of this is, that it might make the interceptor (startup class)
> solution more appealing, even though it isn't platform independent. That is,
> until Servlet 2.3 implementations are stable.
> 
> Any thoughts?

Well... You have to trust me on this one... But the Servlet 2.3 reference
implementation _is_ very stable :) (AKA, Tomcat 4.0! :) And so is the spec.

Just consider it as a hint from a very close friend who has some insight
information :)

    Pier

Re: Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

> Sounds like time for my favorite URL reference - where to get the spec so
> you can look stuff like this up for yourself :-)
>
>   http://java.sun.com/products/servlet/download.html
>
> On this particular issue, there is no such platform-independent API.  In
> fact, the 2.2 and 2.3 specs explicitly remind you that you *cannot* rely
> on "servlet will stay loaded" behavior in a portable application.  The
> container is free (as far as the spec is concerned) to unload a loaded
> servlet any time it feels like doing so.
>
> That was one of the primary reasons that application event listeners were
> added in 2.3 -- to give apps a portable mechanism that does not rely on
> non-guaranteed assumptions about servlet lifetime, or on container
> specific implementation features.
>
> Craig

Indeed, I need to read the spec. (Hey, I've read JDBC and EJB at least :) Thanks
for the help, though.

The upshot of this is, that it might make the interceptor (startup class)
solution more appealing, even though it isn't platform independent. That is,
until Servlet 2.3 implementations are stable.

Any thoughts?

-Erik

Re: Such a thing as server startup class?

["Pier P. Fumagalli" <pi...@betaversion.org>]

Greg Trasuk at stratuscom@on.aibn.com wrote:

> Hi all:
> 
> Yes, a good discussion.
> 
> I puzzled over this for an application I wrote a while ago.  After many
> hours contemplating the servlet spec (2.2), I finally decided that if I
> created an object and dropped it into the application context, it was
> guaranteed to live as long as the servlet container.  My logic was this:
> - The servlet container can load/unload servlets at its pleasure
> - A servlet marked "Load-on-startup" will be loaded and have its init()
> method called when the container starts, even if its not mapped to a URL.
> - Java won't finalize an instance so long as another instance or class has
> a reference to it.
> - The application context will maintain a reference to the instance.
> - If the servlet container destroys the application context, it's probably
> a sign that I should reinitialize everything anyway.
> 
> Could some of the folks who are more familiar with the specs and
> implementation comment on whether this logic is correct and portable to all
> containers?  It worked for the application under Tomcat 3.x, but I've always
> had nagging doubts.

All YES but the last two... You cannot be guaranteed that the container will
maintain a reference until it dies... BUT at the same time, I haven't seen
anyone doing the contrary...


    Pier

RE: Such a thing as server startup class?

[Greg Trasuk <st...@on.aibn.com>]

Hi all:

	Yes, a good discussion.

	I puzzled over this for an application I wrote a while ago.  After many
hours contemplating the servlet spec (2.2), I finally decided that if I
created an object and dropped it into the application context, it was
guaranteed to live as long as the servlet container.  My logic was this:
	- The servlet container can load/unload servlets at its pleasure
	- A servlet marked "Load-on-startup" will be loaded and have its init()
method called when the container starts, even if its not mapped to a URL.
	- Java won't finalize an instance so long as another instance or class has
a reference to it.
	- The application context will maintain a reference to the instance.
	- If the servlet container destroys the application context, it's probably
a sign that I should reinitialize everything anyway.

	Could some of the folks who are more familiar with the specs and
implementation comment on whether this logic is correct and portable to all
containers?  It worked for the application under Tomcat 3.x, but I've always
had nagging doubts.

Thanks,

Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.ca

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> Sent: Monday, August 06, 2001 8:51 PM
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Such a thing as server startup class?
>
>
>
>
> On Mon, 6 Aug 2001, Erik Weber wrote:
>
> > > In a servlet 2.2 world, what most people do is declare a
> servlet to be
> > > <load-on-startup> and initialize things in the init()
> method of that
> > > servlet.  This is relying on the container to never
> unload that servlet
> > > for the lifetime of the app (Tomcat doesn't unload
> anything until shutdown
> > > time), but it basically works.
> > >
> > > Craig McClanahan
> >
> > Good point. If the Servlet were to be unloaded, another
> instance would
> > need to be loaded right away. Is there any
> (platform-independent) way
> > to guarantee that at least one instance of a Servlet will always be
> > loaded, even if it's not set up to handle HTTP requests?
> >
>
> Sounds like time for my favorite URL reference - where to get
> the spec so
> you can look stuff like this up for yourself :-)
>
>   http://java.sun.com/products/servlet/download.html
>
> On this particular issue, there is no such
> platform-independent API.  In
> fact, the 2.2 and 2.3 specs explicitly remind you that you
> *cannot* rely
> on "servlet will stay loaded" behavior in a portable application.  The
> container is free (as far as the spec is concerned) to unload a loaded
> servlet any time it feels like doing so.
>
> That was one of the primary reasons that application event
> listeners were
> added in 2.3 -- to give apps a portable mechanism that does
> not rely on
> non-guaranteed assumptions about servlet lifetime, or on container
> specific implementation features.
>
> > -Erik
> >
> >
>
> Craig
>
>

Re: Such a thing as server startup class?

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 6 Aug 2001, Erik Weber wrote:

> > In a servlet 2.2 world, what most people do is declare a servlet to be
> > <load-on-startup> and initialize things in the init() method of that
> > servlet.  This is relying on the container to never unload that servlet
> > for the lifetime of the app (Tomcat doesn't unload anything until shutdown
> > time), but it basically works.
> >
> > Craig McClanahan
> 
> Good point. If the Servlet were to be unloaded, another instance would
> need to be loaded right away. Is there any (platform-independent) way
> to guarantee that at least one instance of a Servlet will always be
> loaded, even if it's not set up to handle HTTP requests?
> 

Sounds like time for my favorite URL reference - where to get the spec so
you can look stuff like this up for yourself :-)

  http://java.sun.com/products/servlet/download.html

On this particular issue, there is no such platform-independent API.  In
fact, the 2.2 and 2.3 specs explicitly remind you that you *cannot* rely
on "servlet will stay loaded" behavior in a portable application.  The
container is free (as far as the spec is concerned) to unload a loaded
servlet any time it feels like doing so.

That was one of the primary reasons that application event listeners were
added in 2.3 -- to give apps a portable mechanism that does not rely on
non-guaranteed assumptions about servlet lifetime, or on container
specific implementation features.

> -Erik
> 
> 

Craig

Re: Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

> In a servlet 2.2 world, what most people do is declare a servlet to be
> <load-on-startup> and initialize things in the init() method of that
> servlet.  This is relying on the container to never unload that servlet
> for the lifetime of the app (Tomcat doesn't unload anything until shutdown
> time), but it basically works.
>
> Craig McClanahan

Good point. If the Servlet were to be unloaded, another instance would need to be
loaded right away. Is there any (platform-independent) way to guarantee that at
least one instance of a Servlet will always be loaded, even if it's not set up to
handle HTTP requests?

-Erik

Re: Such a thing as server startup class?

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 6 Aug 2001, Erik Weber wrote:

> Hello all.
> 
> I have minimal experience with Tomcat, and didn't see any mention of this in
> looking over the docs.
> 
> I am used to developing in WebLogic. WebLogic supports what are called startup
> classes. You register the name of the class in the server's properties file,
> and when the server starts, it instantiates that class with arguments included
> in the properties file.
> 
> I have found this is a nice way to start up asynchronous subscribers to a
> messaging queue. Upon instantiation, which again is automatic, the various
> subscribers, in their constructors, simply register themselves as listeners
> with the queue.
> 
> I was wondering if Tomcat supports a similar construct as this (startup
> classes). If not, perhaps I could implement my queue subscribers as Servlets,
> but this seems strange, considering mulitple threads should not be running
> through a single subscriber.
> 
> Any thoughts or advice on this?
> 

The servlet 2.3 spec (and, therefore, Tomcat 4) supports a portable
mechanism for this kind of thing called "application event
listeners".  Using this, you can register (in web.xml) listeners that are
notified when the application is started and shut down -- quite helpful
for this sort of thing.

In a servlet 2.2 world, what most people do is declare a servlet to be
<load-on-startup> and initialize things in the init() method of that
servlet.  This is relying on the container to never unload that servlet
for the lifetime of the app (Tomcat doesn't unload anything until shutdown
time), but it basically works.

> -Erik
> 
> 

Craig McClanahan

Such a thing as server startup class?

[Erik Weber <ew...@cimedia.com>]

Hello all.

I have minimal experience with Tomcat, and didn't see any mention of this in
looking over the docs.

I am used to developing in WebLogic. WebLogic supports what are called startup
classes. You register the name of the class in the server's properties file,
and when the server starts, it instantiates that class with arguments included
in the properties file.

I have found this is a nice way to start up asynchronous subscribers to a
messaging queue. Upon instantiation, which again is automatic, the various
subscribers, in their constructors, simply register themselves as listeners
with the queue.

I was wondering if Tomcat supports a similar construct as this (startup
classes). If not, perhaps I could implement my queue subscribers as Servlets,
but this seems strange, considering mulitple threads should not be running
through a single subscriber.

Any thoughts or advice on this?

-Erik

Re: tomcat on mac os 10 with virtual PC

["Pier P. Fumagalli" <pi...@betaversion.org>]

Adam Wildavsky at adam@tameware.cnchost.com wrote:

>>> I did have to chmod 755 the *.sh scripts after installation.
>> 
>> ? Using a zip?
> 
> Doh! Yes, I used the zip downloaded from the Tomcat page, but I
> allowed StuffIt Expander to extract the files. Next time I'll use
> "unzip" from the command line.

Nah, download the .tar.gz one and use gnutar -zxvf. The .ZIP format doesn't
contain information such as file permissions (the ones changed by chmod)

    Pier

Re: tomcat on mac os 10 with virtual PC

[Adam Wildavsky <ad...@tameware.cnchost.com>]

At 8:28 AM +0100 8/7/01, Pier P. Fumagalli wrote:
>Adam Wildavsky at adam@tameware.cnchost.com wrote:
>>
>>  I couldn't figure out what to set JAVA_HOME to, so I didn't set it,
>>  and all seems well.
>
>/System/Library/Frameworks/JavaVM.framework/Home

Thanks! That will come in handy.

>  > I did have to chmod 755 the *.sh scripts after installation.
>
>? Using a zip?

Doh! Yes, I used the zip downloaded from the Tomcat page, but I 
allowed StuffIt Expander to extract the files. Next time I'll use 
"unzip" from the command line.

AW

Re: tomcat on mac os 10 with virtual PC

["Pier P. Fumagalli" <pi...@betaversion.org>]

Adam Wildavsky at adam@tameware.cnchost.com wrote:
> 
> I couldn't figure out what to set JAVA_HOME to, so I didn't set it,
> and all seems well.

/System/Library/Frameworks/JavaVM.framework/Home

> I did have to chmod 755 the *.sh scripts after installation.

? Using a zip?

> I found that I could run the scripts as a user if I wanted to listen
> on port 8080, but I had to use sudo when I changed the configuration
> file to listen on port 80. I expect the same is true on other
> platforms.

All unix based platforms.

> One puzzling aspect occurred after I first installed Tomcat on the
> default port. Internet Explorer [v5.1b1 (3408)] crashed when I tried
> to access http://localhost:8080. Changing this to
> http://localhost:8080/index.html worked, as did using the OmniWeb
> browser. Moving Tomcat to port 80 eliminated the crash entirely.

3408 doesn't give me any problem on port 80/8080/800 or whatever... Must be
some kind of weird header 3.2.3 sets and that 4.0 doesn't.

    Pier

Re: tomcat on mac os 10 with virtual PC

[Adam Wildavsky <ad...@tameware.cnchost.com>]

At 11:04 PM +0100 8/6/01, Pier P. Fumagalli wrote:
>I don't know anything about VirtualPC, but TC4.0 runs just fine on OS/X
>10.0.4 and 10.1 alpha (those are my primary development environments, so :)
>
>     Pier

As does Tomcat 3.2.3. I'm new to Tomcat, but I had no trouble 
installing it. My biggest decision was where to put it! (I decided on 
/Users/Shared, for no particular reason.)

I couldn't figure out what to set JAVA_HOME to, so I didn't set it, 
and all seems well.

I did have to chmod 755 the *.sh scripts after installation.

I found that I could run the scripts as a user if I wanted to listen 
on port 8080, but I had to use sudo when I changed the configuration 
file to listen on port 80. I expect the same is true on other 
platforms.

One puzzling aspect occurred after I first installed Tomcat on the 
default port. Internet Explorer [v5.1b1 (3408)] crashed when I tried 
to access http://localhost:8080. Changing this to 
http://localhost:8080/index.html worked, as did using the OmniWeb 
browser. Moving Tomcat to port 80 eliminated the crash entirely.

AW

Re: tomcat on mac os 10 with virtual PC

["Pier P. Fumagalli" <pi...@betaversion.org>]

Girish Baxi at gbaxi@digitalconcepts.com wrote:

> hi
> 
> was wondering if anyone has tried installinbg tomcat on mac os 10 with
> virtual PC .... i have been having hard time doing it .....
> 
> any inputs are most welcome

I don't know anything about VirtualPC, but TC4.0 runs just fine on OS/X
10.0.4 and 10.1 alpha (those are my primary development environments, so :)

    Pier