You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Patrick Coleman <pa...@bluedog.net> on 2007/10/18 19:36:35 UTC
Hiding :8080 port in URL
Hi,
I'm using liferay with Tomcat. I don't want the :8080 port to show up in the
URL.
I can prevent this using apache ProxyPass & ProxyPassReverse
The problem is that once inside Liferay all the tab reference the :8080
again and
so it show back up in the URL.
I've read that mod_proxy_html & mod_proxy_http can take care of this but
from what I've
read they are not available in Apache 1.3.3 (we will be upgrading soon)
Does anyone know how I can get this to work.
Thanks.
Pat.
--
View this message in context: http://www.nabble.com/Hiding-%3A8080-port-in-URL-tf4648550.html#a13279691
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: removing :xxxx port requirement in URL [update]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dale,
BuildSmart wrote:
> It looks like my current solution only works with Tomcat 4.1 (I didn't
> try anything older).
>
> I'm wondering how to resolve this, I doubt they'd make changes in the
> source to allow the ability to modify the docroot without affecting
> other directory designations because I need it for my module.
Maybe they would. Feel free to start another thread (I don't think
anyone else is reading this one anymore) asking that question (maybe
even on the dev list instead of the user list). Another option is to
file a bug report (enhancement request) that asks for a way to do what
you need to do.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHH0pC9CaO5/Lv0PARAgiUAJ9bHq8a1ZBtl6a18c1c8gdqPTCxUACfXuZd
l+jKiGw06W40nmBkw7Ekvnw=
=sJB4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: removing :xxxx port requirement in URL [update]
Posted by BuildSmart <bu...@daleenterprise.com>.
I was beginning to be happy with the results of my work and was
enjoying the ability to have apache serve the .jsp files from any of
it's virtualhost document roots and not the Tomcat docroot and only
having one Tomcat virtualhost defined allowed me to design an admin
interface on the defined Tomcat port.
I was thinking it was time to start planning out a release package
when I decided to try using Tomcat 5 instead of Tomcat 4 (which is
vendor supplied) and I'm disappointed to find out that the changes in
the class files have combined the docroot, work and scratch dir
variable initialization so changing docroot dynamically on the fly
doesn't work cause it then complains about no WEB-INF and no work dir
and exits with a 500 error msg.
I thought to be safe I'd try Tomcat 6 (forced me to use JSDK 1.5) and
it exhibits the same issue.
It looks like my current solution only works with Tomcat 4.1 (I
didn't try anything older).
I'm wondering how to resolve this, I doubt they'd make changes in the
source to allow the ability to modify the docroot without affecting
other directory designations because I need it for my module.
Maybe using Tomcat was a poor choice based on the current available
config state or maybe there is another method in the newer Tomcat's
to achieve the docroot change without disrupting the others or maybe
I should consider dropping it as a possible method of implementation?
-- Dale
Re: Hiding :8080 port in URL [attention mod_jk devs]
Posted by BuildSmart <bu...@daleenterprise.com>.
On Oct 19, 2007, at 17:05:58, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dale,
>
> BuildSmart wrote:
>> Yes, for the purpose of my project I then added a native debug
>> interface
>> and significant amount of debugging features so that I could walk an
>> entire transaction from start to finish and see what's going on
>> and to
>> change the expected behavior my modification of the transaction
>> and the
>> environment variables.
>
> Did you modify the native mod_jk module for Apache httpd or did you
> modify the Java-based connector in Tomcat?
I use a the same unmodified connector but I have an additional class
that add/extends functionality, the module passes all the environment
variables (whether the script uses them or not) so that I can get the
DOCUMENT_ROOT and swap it for the docroot, then process the script
which Tomcat believes is in it's document root.
>
> If the former, would you care to share some of your work with the
> mod_jk
> folks?
As I said, when I'm done I'll be happy to release a package, the
mod_jk group can pick through the code and borrow whatever they like
or they can just use my module instead of hacking theirs.
The end package might not be ajp13 compliant/compatible and I wont
know until I have the end product but we'll see how it goes.
>
>> It is my intention with the help of this module to create a new
>> module
>> that will allow execution from the apache document root rather than
>> deployed from within Tomcat.
>
> I'm not sure I get it... you want to run Tomcat from inside Apache's
> DocumentRoot? What's stopping you from doing that, now (aside from the
> fact that it's not a very good idea)?
>
>> I have another version that doesn't use the workers.properties file
>
> workers.properties is not necessary with mod_jk: you can use
> directives
> to set up everything if you wish.
>
>> and
>> a modified Ajp13Servlet class to allow serving the scripts from
>> apache
>> 1.3.33 virtualhost document roots and it does work with basic scripts
>> that I have been testing with which brings me to the point where I
>> am no
>> longer serving the pages from within Tomcat, only making the
>> deployment
>> environment native to apache.
>
> I think I still don't get it. What scripts are you talking about?
> JSPs?
>
>> What I have so far is the following, a smithcf-1.3b4.war in Tomcat
>> 4.1,
>> apache serving java and coldfusion scripts from the apache
>> virtualhost
>> document roots but using the war to compile and process the
>> scripts as
>> if they were native to the war by environment modification.
>
> Aah... you are using Tomcat in the same way that mod_php (for
> instance)
> handles PHP pages by handing-off processing to the php binary.
> Interesting. Sort of a "mod_java". How do you handle JSPs that require
> support libraries? Or those that use includes?
The process works in the same way that php does, when a file is
included it is loaded from the apache document root (because I modify
the docroot) so it's not an issue.
In my WAR I have the smithcf engine and it appears to process those
scripts in the same manner and the includes is working with those as
well.
Basically I wanna do what mod_jrun and Adobe CF or mod_servletexec
and BlueDragon does with Smith CF (a free CF engine) but both
bod_jrun and mod_servletexec aren't free to use in a production
environment and I couldn't find any free software that achieves this
task hence my project.
While I started with a modified mod_jk, I'm also looking at the older
mod_jserv as a possible alternative if I can achieve the same results
without having to do any special classes to make it work then I might
look at utilizing it.
>
>> It's kinda like enabling php in apache 1.3.33, I can add my .jsp and
>> .cfm scripts to the virtualhost document roots and they work just
>> like
>> adding .php scripts.
>
> I think you might run into problems when the JSPs require more
> support,
> or if you want to run servlets. Perhaps you don't care about those
> situations (because you can always use full-blown Tomcat with webapps,
> etc.).
>
>> Actually, I haven't done anything special to the Tomcat configuration
>> except to enable ajp13 on localhost only on port 8079 and for it to
>> listen on localhost only on port 9079 and the war never physically
>> sees
>> any of the scripts.
>
> Do you mean that the WAR file does not /contain/ any scripts, or
> that no
> code deployed in the WAR file processes the scripts? I would imagine
> that you'd have to load and process the scripts in order to evaluate
> them and produce content...
The WAR contains the smithcf engine and the administration interface
(as an embedded servlet) and a helloworld.jsp and helloworld.cfm
script but no other script content, the engine loads and processes
the scripts based on the URI but instead of grabbing the scripts from
the Tomcat document root it changes the document root to the apache
document root for the virtualhost executing the URI.
>
>> Currently I've dropped Tomcat to work with jetty 6.1.5 without any
>> special modification aside from adding a custom jar file with my
>> extra
>> servlet classes in attempt to achieve the same results so that my
>> module
>> will work with any deployment method by the inclusion of these
>> additional classes.
>
> Jetty might actually offer a better target because (last I checked,
> don't flame me if I'm wrong) Jetty only supports one deployed
> webapp per
> instance, and you don't need the ability to deploy more than one
> webapp,
> so you can save yourself a lot of complexity: you get a leaner, meaner
> script processing machine.
I believe (starting with) jetty 6.1.5 supports contexts so multiple
webapps can be deployed.
>
>> When I get it refined enough to offer a public release I'll
>> post something to this list since I know that others would like to
>> achieve the same results of configuring Tomcat for one virtualhost
>> and
>> forget it (so you can gain access to the deployment environment) and
>> then they only have to work with the apache virtualhosts and the
>> scripts
>> reside within the apache virtualhosts making deployment that much
>> cleaner and easier to manage.
>
> Interesting.
>
> - -chris
I'm looking for an easy to implement solution where I don't have to
configure anything more than apache virtual hosts to achieve a
useable solution.
I'll be the first to admit that I know next to nothing about
configuring mod_jk and Tomcat but if I have 1000 apache virtual hosts
I certainly don't want to have to configure Tomcat for every one of
them.
I'm also not the greatest java programmer (most of what I have java
related has been done with the help of a friend who's much better
than I), I use snoop.jsp and a self-written snooper.jsp to tell me
stuff but even then I can't see all of the variables that apply to
what I'm doing (cause I don't have a cheat sheet that tells what
calls will give me the info I want to see).
Now, someone else says my concept can be implemented strictly by a
class file that scans apache config files and changes the docroot
with the apache DOCUMENT_ROOT based on the virtualhost being accessed
but I couldn't figure this out myself and the person who claims it's
possible states it's a tried and tested POC but couldn't offer any
evidence to back the claim.
In any event, I should have something publicly releasable before the
end of the year.
-- Dale
Re: Hiding :8080 port in URL [attention mod_jk devs]
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dale,
BuildSmart wrote:
> Yes, for the purpose of my project I then added a native debug interface
> and significant amount of debugging features so that I could walk an
> entire transaction from start to finish and see what's going on and to
> change the expected behavior my modification of the transaction and the
> environment variables.
Did you modify the native mod_jk module for Apache httpd or did you
modify the Java-based connector in Tomcat?
If the former, would you care to share some of your work with the mod_jk
folks?
> It is my intention with the help of this module to create a new module
> that will allow execution from the apache document root rather than
> deployed from within Tomcat.
I'm not sure I get it... you want to run Tomcat from inside Apache's
DocumentRoot? What's stopping you from doing that, now (aside from the
fact that it's not a very good idea)?
> I have another version that doesn't use the workers.properties file
workers.properties is not necessary with mod_jk: you can use directives
to set up everything if you wish.
> and
> a modified Ajp13Servlet class to allow serving the scripts from apache
> 1.3.33 virtualhost document roots and it does work with basic scripts
> that I have been testing with which brings me to the point where I am no
> longer serving the pages from within Tomcat, only making the deployment
> environment native to apache.
I think I still don't get it. What scripts are you talking about? JSPs?
> What I have so far is the following, a smithcf-1.3b4.war in Tomcat 4.1,
> apache serving java and coldfusion scripts from the apache virtualhost
> document roots but using the war to compile and process the scripts as
> if they were native to the war by environment modification.
Aah... you are using Tomcat in the same way that mod_php (for instance)
handles PHP pages by handing-off processing to the php binary.
Interesting. Sort of a "mod_java". How do you handle JSPs that require
support libraries? Or those that use includes?
> It's kinda like enabling php in apache 1.3.33, I can add my .jsp and
> .cfm scripts to the virtualhost document roots and they work just like
> adding .php scripts.
I think you might run into problems when the JSPs require more support,
or if you want to run servlets. Perhaps you don't care about those
situations (because you can always use full-blown Tomcat with webapps,
etc.).
> Actually, I haven't done anything special to the Tomcat configuration
> except to enable ajp13 on localhost only on port 8079 and for it to
> listen on localhost only on port 9079 and the war never physically sees
> any of the scripts.
Do you mean that the WAR file does not /contain/ any scripts, or that no
code deployed in the WAR file processes the scripts? I would imagine
that you'd have to load and process the scripts in order to evaluate
them and produce content...
> Currently I've dropped Tomcat to work with jetty 6.1.5 without any
> special modification aside from adding a custom jar file with my extra
> servlet classes in attempt to achieve the same results so that my module
> will work with any deployment method by the inclusion of these
> additional classes.
Jetty might actually offer a better target because (last I checked,
don't flame me if I'm wrong) Jetty only supports one deployed webapp per
instance, and you don't need the ability to deploy more than one webapp,
so you can save yourself a lot of complexity: you get a leaner, meaner
script processing machine.
> When I get it refined enough to offer a public release I'll
> post something to this list since I know that others would like to
> achieve the same results of configuring Tomcat for one virtualhost and
> forget it (so you can gain access to the deployment environment) and
> then they only have to work with the apache virtualhosts and the scripts
> reside within the apache virtualhosts making deployment that much
> cleaner and easier to manage.
Interesting.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGRw29CaO5/Lv0PARAhMTAJ9oxN1z09uBFmJ+5Ukb3pBprwwj6gCdFMQJ
ArbvG2jww1Dav9lCyFVQntc=
=VYBX
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Hiding :8080 port in URL
Posted by BuildSmart <bu...@daleenterprise.com>.
On Oct 19, 2007, at 15:10:10, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> BS,
>
> BuildSmart wrote:
>> Use mod_jk to resolve this, also, if you want to try a module that is
>> specific to ajp13, I created the following
>> mod_ajp13 (http://amavis-stats.com/downloads/mod_ajp13.tar.gz - with
>> load balance support), it's basically a stripped down mod_jk that
>> only
>> contains the ajp13 related code so I can write a new module that will
>> allow the integration to apache for virtualhosts so that the pages
>> can
>> be served by apache from the virtualhost document roots and not
>> stored
>> in the Tomcat document roots so that configuration only requires
>> configuring apache virtualhosts.
>
> What is this all about? I think the only thing you've done is
> reduce the
> size of the shared library. Is that really useful?
Yes, for the purpose of my project I then added a native debug
interface and significant amount of debugging features so that I
could walk an entire transaction from start to finish and see what's
going on and to change the expected behavior my modification of the
transaction and the environment variables.
It is my intention with the help of this module to create a new
module that will allow execution from the apache document root rather
than deployed from within Tomcat.
I have another version that doesn't use the workers.properties file
and a modified Ajp13Servlet class to allow serving the scripts from
apache 1.3.33 virtualhost document roots and it does work with basic
scripts that I have been testing with which brings me to the point
where I am no longer serving the pages from within Tomcat, only
making the deployment environment native to apache.
What I have so far is the following, a smithcf-1.3b4.war in Tomcat
4.1, apache serving java and coldfusion scripts from the apache
virtualhost document roots but using the war to compile and process
the scripts as if they were native to the war by environment
modification.
The advantage here is that I don't have to define additional roots
per virtualhosts or do proxy work whenever I add/modify/remove an
apache virtualhost, I don't have to do anything with Tomcat other
than deploy my war and then configure apache as needed.
Let me try again.
If you can't see the advantages here try adding 100 apache
virtualhosts and give them each an index.jsp file in the apache
virtualhost document root which are all different physical locations
and each has different content (but all are named index.jsp), create
only one virtualhost in Tomcat and the deployed war does not have any
scripts, start Tomcat and apache, process the index.jsp scripts per
virtualhost if you can (all on port 80).
In my war, I have an index.jsp that outputs "Welcome to my engine"
and does nothing else, it's never executed from apache, every apache
virtualhost has in it's document root an index.jsp file that is
specific/unique to it's virtualhost and it's processed as if it was
in the war and I'm not using mod_rewrite or mod_proxy or any weird
stuff in the war.
It's kinda like enabling php in apache 1.3.33, I can add my .jsp
and .cfm scripts to the virtualhost document roots and they work just
like adding .php scripts.
Actually, I haven't done anything special to the Tomcat configuration
except to enable ajp13 on localhost only on port 8079 and for it to
listen on localhost only on port 9079 and the war never physically
sees any of the scripts.
Currently I've dropped Tomcat to work with jetty 6.1.5 without any
special modification aside from adding a custom jar file with my
extra servlet classes in attempt to achieve the same results so that
my module will work with any deployment method by the inclusion of
these additional classes.
Actually I'm finding that jetty is much easier to work with than
Tomcat from a deployment standpoint but that's only because it's a
simple to configure server.
When I get it refined enough to offer a public release I'll post
something to this list since I know that others would like to achieve
the same results of configuring Tomcat for one virtualhost and forget
it (so you can gain access to the deployment environment) and then
they only have to work with the apache virtualhosts and the scripts
reside within the apache virtualhosts making deployment that much
cleaner and easier to manage.
>
> - -chris
-- Dale
Re: Hiding :8080 port in URL
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
BS,
BuildSmart wrote:
> Use mod_jk to resolve this, also, if you want to try a module that is
> specific to ajp13, I created the following
> mod_ajp13 (http://amavis-stats.com/downloads/mod_ajp13.tar.gz - with
> load balance support), it's basically a stripped down mod_jk that only
> contains the ajp13 related code so I can write a new module that will
> allow the integration to apache for virtualhosts so that the pages can
> be served by apache from the virtualhost document roots and not stored
> in the Tomcat document roots so that configuration only requires
> configuring apache virtualhosts.
What is this all about? I think the only thing you've done is reduce the
size of the shared library. Is that really useful?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGQES9CaO5/Lv0PARAldRAKCwO4TzkMG/6PG0I1lAyOIuTb5FhwCeMZtH
G5apHZtPLkziiYZRC9XJUlo=
=pvQI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Hiding :8080 port in URL
Posted by BuildSmart <bu...@daleenterprise.com>.
On Oct 18, 2007, at 13:36:35, Patrick Coleman wrote:
>
> Hi,
>
> I'm using liferay with Tomcat. I don't want the :8080 port to show
> up in the
> URL.
> I can prevent this using apache ProxyPass & ProxyPassReverse
>
> The problem is that once inside Liferay all the tab reference the :
> 8080
> again and
> so it show back up in the URL.
>
> I've read that mod_proxy_html & mod_proxy_http can take care of
> this but
> from what I've
> read they are not available in Apache 1.3.3 (we will be upgrading
> soon)
>
>
> Does anyone know how I can get this to work.
Use mod_jk to resolve this, also, if you want to try a module that is
specific to ajp13, I created the following mod_ajp13 (http://amavis-
stats.com/downloads/mod_ajp13.tar.gz - with load balance support),
it's basically a stripped down mod_jk that only contains the ajp13
related code so I can write a new module that will allow the
integration to apache for virtualhosts so that the pages can be
served by apache from the virtualhost document roots and not stored
in the Tomcat document roots so that configuration only requires
configuring apache virtualhosts.
>
> Thanks.
>
> Pat.
> --
> View this message in context: http://www.nabble.com/Hiding-%3A8080-
> port-in-URL-tf4648550.html#a13279691
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
-- Dale
Re: Hiding :8080 port in URL
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Patrick Coleman wrote:
> Hi,
>
> I'm using liferay with Tomcat. I don't want the :8080 port to show up in the
> URL.
> I can prevent this using apache ProxyPass & ProxyPassReverse
>
correct
> The problem is that once inside Liferay all the tab reference the :8080
> again and
> so it show back up in the URL.
>
that is because you didn't set the proxyPort="80" on the tomcat side
Filip
> I've read that mod_proxy_html & mod_proxy_http can take care of this but
> from what I've
> read they are not available in Apache 1.3.3 (we will be upgrading soon)
>
>
> Does anyone know how I can get this to work.
>
> Thanks.
>
> Pat.
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Hiding :8080 port in URL
Posted by Alberto Rodriguez Galdo <ar...@gmail.com>.
Maybe Apache in port 80 with mod_jk will sufice and is available for
1.3.xversion
On 10/18/07, Patrick Coleman <pa...@bluedog.net> wrote:
>
>
> Hi,
>
> I'm using liferay with Tomcat. I don't want the :8080 port to show up in
> the
> URL.
> I can prevent this using apache ProxyPass & ProxyPassReverse
>
> The problem is that once inside Liferay all the tab reference the :8080
> again and
> so it show back up in the URL.
>
> I've read that mod_proxy_html & mod_proxy_http can take care of this but
> from what I've
> read they are not available in Apache 1.3.3 (we will be upgrading soon)
>
>
> Does anyone know how I can get this to work.
>
> Thanks.
>
> Pat.
> --
> View this message in context:
> http://www.nabble.com/Hiding-%3A8080-port-in-URL-tf4648550.html#a13279691
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Alberto Rodriguez Galdo
argaldo@gmail.com