Home » Language IDEs » ServerTools (WTP) » How to set up a virtual host website with Tomcat6
| How to set up a virtual host website with Tomcat6 [message #549493] |
Mon, 26 July 2010 20:48  |
 Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
Hi - Done a lot of searching for an answer, but no joy! Can anyone
tell me how one sets up a project for a static website that will be
configured for a virtual host? I can't even figure out how to associate
a static website with a Tomcat6 server, let alone figure out how to set
the virtual webapp deployment directory for it!
In the Tomcat directory, one normally has a basic webapp dir with a ROOT
subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
virtual hosted domains it will be something like
($CATALINA_HOME)->virtualDomain_webapps->ROOT
So how does one setup this sort of deployment within Eclipse? One
thought I had was to set up a second instance of a Tomcat server, and
give it a new deploy path, but I still do not see how to associate a
static website with it. And I don't want two different webprojects to
collide if both their context roots are set to ROOT
Also, one other question that has been nagging me, and a bit of a
headache... Why does Eclipse set the name of the default deployment
directory to wtpwebapps instead of simply webapps? That raises havoc
with a lot of projects and Tomcat has no idea what this root deployment
directory is... It is a PITA if I forget to reconfigure this and it is
not the normal default webapp directory that comes with a basic Tomcat
installation. (Particularly since many of my web apps use generated
absolute paths in things like servlets and JSP code) Inquiring minds are
curious! Wish I could find some good documentation on the models used
in Eclipse/WTP for project types, servers, deployment etc.... If there
is such, I am willing to read and grok on my own, but what I have found
so far is a far cry from getting me to being able to comprehend most of
the things I am being asked about, or want to configure!
Marc...
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #549507 is a reply to message #549493] |
Mon, 26 July 2010 22:41  |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 07/26/2010 01:48 PM, Marc Chamberlin wrote:
> Hi - Done a lot of searching for an answer, but no joy! Can anyone
> tell me how one sets up a project for a static website that will be
> configured for a virtual host? I can't even figure out how to associate
> a static website with a Tomcat6 server, let alone figure out how to set
> the virtual webapp deployment directory for it!
>
> In the Tomcat directory, one normally has a basic webapp dir with a ROOT
> subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
> virtual hosted domains it will be something like
> ($CATALINA_HOME)->virtualDomain_webapps->ROOT
> So how does one setup this sort of deployment within Eclipse? One
> thought I had was to set up a second instance of a Tomcat server, and
> give it a new deploy path, but I still do not see how to associate a
> static website with it. And I don't want two different webprojects to
> collide if both their context roots are set to ROOT
>
> Also, one other question that has been nagging me, and a bit of a
> headache... Why does Eclipse set the name of the default deployment
> directory to wtpwebapps instead of simply webapps? That raises havoc
> with a lot of projects and Tomcat has no idea what this root deployment
> directory is... It is a PITA if I forget to reconfigure this and it is
> not the normal default webapp directory that comes with a basic Tomcat
> installation. (Particularly since many of my web apps use generated
> absolute paths in things like servlets and JSP code) Inquiring minds are
> curious! Wish I could find some good documentation on the models used
> in Eclipse/WTP for project types, servers, deployment etc.... If there
> is such, I am willing to read and grok on my own, but what I have found
> so far is a far cry from getting me to being able to comprehend most of
> the things I am being asked about, or want to configure!
>
> Marc...
>
>
Nope! Cannot set up a second instance of Tomcat to solve the Virtual
Host problem... If this cannot be configured to deploy properly in the
local Eclipse workspace, then I hit too many other problems within our
servlets... So... I am lost! Anyone got any ideas? Thanks in advance for
advice and help...
Marc...
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #549685 is a reply to message #549507] |
Tue, 27 July 2010 14:33 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 7/26/2010 6:41 PM, Marc Chamberlin wrote:
> On 07/26/2010 01:48 PM, Marc Chamberlin wrote:
>> Hi - Done a lot of searching for an answer, but no joy! Can anyone
>> tell me how one sets up a project for a static website that will be
>> configured for a virtual host? I can't even figure out how to associate
>> a static website with a Tomcat6 server, let alone figure out how to set
>> the virtual webapp deployment directory for it!
>>
>> In the Tomcat directory, one normally has a basic webapp dir with a ROOT
>> subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
>> virtual hosted domains it will be something like
>> ($CATALINA_HOME)->virtualDomain_webapps->ROOT
>> So how does one setup this sort of deployment within Eclipse? One
>> thought I had was to set up a second instance of a Tomcat server, and
>> give it a new deploy path, but I still do not see how to associate a
>> static website with it. And I don't want two different webprojects to
>> collide if both their context roots are set to ROOT
>>
>> Also, one other question that has been nagging me, and a bit of a
>> headache... Why does Eclipse set the name of the default deployment
>> directory to wtpwebapps instead of simply webapps? That raises havoc
>> with a lot of projects and Tomcat has no idea what this root deployment
>> directory is... It is a PITA if I forget to reconfigure this and it is
>> not the normal default webapp directory that comes with a basic Tomcat
>> installation. (Particularly since many of my web apps use generated
>> absolute paths in things like servlets and JSP code) Inquiring minds are
>> curious! Wish I could find some good documentation on the models used
>> in Eclipse/WTP for project types, servers, deployment etc.... If there
>> is such, I am willing to read and grok on my own, but what I have found
>> so far is a far cry from getting me to being able to comprehend most of
>> the things I am being asked about, or want to configure!
>>
>> Marc...
>>
>>
> Nope! Cannot set up a second instance of Tomcat to solve the Virtual
> Host problem... If this cannot be configured to deploy properly in the
> local Eclipse workspace, then I hit too many other problems within our
> servlets... So... I am lost! Anyone got any ideas? Thanks in advance for
> advice and help...
>
> Marc...
>
See if the Tomcat FAQ[1] helps with addressing these issues.
Note that a Static Web Project isn't deployable to a Tomcat server
because the Tomcat only supports Dynamic Web Projects. You could create
a Dynamic Web Project and only put static content in it. The fact that
later versions of the servlet spec would allow a Static Web Project to
pretend to be a Dynamic Web Project doesn't currently help.
The reason for using "wtpwebapps" is to deliberately avoid the
auto-deployment features typically associated with "webapps". For
example, if you switch to using "webapps" and you change a project's
"Context root" to something different from the project name, you will
get two copies of the project served. One using the desired context
root, and an auto-served one using the project's name. Using just
<Context> elements to declare the WTP projects to be served provides
much better control over the server.
Cheers,
Larry
[1] http://wiki.eclipse.org/WTP_Tomcat_FAQ
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #549781 is a reply to message #549685] |
Tue, 27 July 2010 22:07 |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 7/27/2010 7:33 AM, Larry Isaacs wrote:
> On 7/26/2010 6:41 PM, Marc Chamberlin wrote:
>> On 07/26/2010 01:48 PM, Marc Chamberlin wrote:
>>> Hi - Done a lot of searching for an answer, but no joy! Can anyone
>>> tell me how one sets up a project for a static website that will be
>>> configured for a virtual host? I can't even figure out how to associate
>>> a static website with a Tomcat6 server, let alone figure out how to set
>>> the virtual webapp deployment directory for it!
>>>
>>> In the Tomcat directory, one normally has a basic webapp dir with a ROOT
>>> subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
>>> virtual hosted domains it will be something like
>>> ($CATALINA_HOME)->virtualDomain_webapps->ROOT
>>> So how does one setup this sort of deployment within Eclipse? One
>>> thought I had was to set up a second instance of a Tomcat server, and
>>> give it a new deploy path, but I still do not see how to associate a
>>> static website with it. And I don't want two different webprojects to
>>> collide if both their context roots are set to ROOT
>>>
>>> Also, one other question that has been nagging me, and a bit of a
>>> headache... Why does Eclipse set the name of the default deployment
>>> directory to wtpwebapps instead of simply webapps? That raises havoc
>>> with a lot of projects and Tomcat has no idea what this root deployment
>>> directory is... It is a PITA if I forget to reconfigure this and it is
>>> not the normal default webapp directory that comes with a basic Tomcat
>>> installation. (Particularly since many of my web apps use generated
>>> absolute paths in things like servlets and JSP code) Inquiring minds are
>>> curious! Wish I could find some good documentation on the models used
>>> in Eclipse/WTP for project types, servers, deployment etc.... If there
>>> is such, I am willing to read and grok on my own, but what I have found
>>> so far is a far cry from getting me to being able to comprehend most of
>>> the things I am being asked about, or want to configure!
>>>
>>> Marc...
>>>
>>>
>> Nope! Cannot set up a second instance of Tomcat to solve the Virtual
>> Host problem... If this cannot be configured to deploy properly in the
>> local Eclipse workspace, then I hit too many other problems within our
>> servlets... So... I am lost! Anyone got any ideas? Thanks in advance for
>> advice and help...
>>
>> Marc...
>>
>
> See if the Tomcat FAQ[1] helps with addressing these issues.
>
Thanks Larry for replying, appreciate it! No, no joy in the FAQs. When I
create a new web project in Eclipse, and associate it with a Tomcat
server, Eclipse picks up and makes a copy of the server.xml file from
the systems Tomcat installation. This is where virtual hosts are
defined. The trouble is I cannot figure out how to set up, or tell
Eclipse to set up, the new "appBase" that is configured for each virtual
host defined within the server.xml file. So, when the Eclipse instance
of the Tomcat server starts up, it crashes, because these appBases are
not defined/created within the Eclipse Tomcat instance version of its
webapps directories. (I could create these, I think, by hand, but that
still does not properly set up Eclipse so it will deploy a particular
web app to the right appBase directory, for which it is suppose to run
under.)
The only thing close, that I have found, is the fact that when a new
Tomcat server instance is defined, one is allowed to create a single
"Deploy Path" name for that instance. That appears to me to be the
equivalent of the appBase for a default Tomcat server installation, but
as I said, for virtual hosts I need one of these for EACH virtual host...
Let me try to boil down my confusion about webapps and ask the questions
that I seek and answer to more directly. To define a context for a
webapp, Tomcat requires up to 4 attributes to be defined, "host name",
"appBase", "docBase", and "path". For a virtual host we need to define
what the "host name" URL is for that virtual host. This is so that
Tomcat can map this to an "appBase" which is the second of these 4
attributes that must be defined. To deploy a webapp to a virtual host,
Eclipse is going to have to understand this mapping as well and somehow
allow the user to define the appBase for each webapp so that the
deployment of that webapp project can take place properly. I don't see
how to do that. For the default appBase, of Tomcat, this simply is
"webapps" or in Eclipse's model it seems to be "wtpwebapps". In the
server settings, I find that I can define a single "Deploy path" for any
given server which by default is "wtpwebapps" so I presume the "appBase"
and "Deploy path" are somewhat synonymous, BUT for virtual hosts I need
to be able to define multiple "Deploy path"s / "appBase"s....
The 3rd attribute of a context that needs to be defined is the "docBase"
for a given webapp. I understand that Eclipse uses the Project name
itself for the "docBase" attribute, but the one question I have then, is
how do I map a webapp project to the "ROOT" docBase? Give the Project a
name of ROOT? And if I have virtual hosts, that will not work as I am
likely to have multiple apps that will want to reside in their
respective "ROOT" directories. I must be missing something simple here,
this is to obvious of a requirement!
The 4th attribute of a context to be defined is "path" which defines the
mapping from, for lack of a better way to say this, the extended portion
of a URL (not the URL's host name portion) to a particular docBase.
(for example, in "www.name.com/someApp, the base is "www.name.com" and
is mapped via "host name" to the "appBase" and "/someApp" is the
extended portion and mapped by "path" to "docBase") I figured out how
to set the "path" attribute, by trial and error, in the Eclipse GUI, but
will argue that Eclipse is using terminology that is in conflict with
what is used in the Apache Tomcat documentation. In Eclipse, one sets
the "path" attribute by bringing up the properties for a webapp, and
going to the Web Project Settings, and filling in a field labeled
"Context root" According to the Apache Tomcat documentation the "Context
root" is referring to the "docBase" attribute, not the "path" attribute.
I think that will be confusing to a lot of users, not just me... (see
the description for the "docBase" attribute at
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html# Common_Attributes
)
I also tried to set the "Context root" / "path" attribute to empty, or
"" but the GUI would not allow me to do so. I was thinking that perhaps
Eclipse would then infer that the deployment of the webapp would be to
the ROOT docBase directory. According to the Tomcat documentation, if
the "path" attribute is set to "" or the empty string, then that context
is defining the default web application for it's associated host. So
again, I do not understand how to define the default web application.
So, simply put, how does one define the attributes of "host name",
"appBase", "docBase" and "path" for a dynamic web app so that Eclipse
will understand how to deploy projects correctly? Hard for me to believe
that Eclipse/WTP does not support virtual hosts, more likely I think is
that I just don't understand how to do it... (I am still learning the
ropes!) But, if not, my last two comments/questions about the "docBase"
and "path" attributes remain valid....
> Note that a Static Web Project isn't deployable to a Tomcat server
> because the Tomcat only supports Dynamic Web Projects. You could create
> a Dynamic Web Project and only put static content in it. The fact that
> later versions of the servlet spec would allow a Static Web Project to
> pretend to be a Dynamic Web Project doesn't currently help.
Yes, I am headed in this direction already. The reason I was hesitant
to use Dynamic Web Projects is that I deploy some of the web sites for
virtual hosts via WAR files, and others are simply set up directly by
users, and I am a bit reluctant about changing the structure of these
sites out from under the way they were originally set up by their users.
I wanted to be able to associate them with a Tomcat server however, so
as to be able to help debug problems that arise, such as can happen when
they use some of our hooks for SSI (server side includes), Javascripts,
etc. But I have a workaround, I think, and can use an outside tool
(Beyond Compare) to put back changes I make, while debugging these
applications as Dynamic Web Projects, instead of creating for example, a
new WAR file.... More manual/labor intensive however, sigh, and it means
having to remove any original WAR files from the systems Tomcat
directory, otherwise my changes will get overwritten....
>
> The reason for using "wtpwebapps" is to deliberately avoid the
> auto-deployment features typically associated with "webapps". For
> example, if you switch to using "webapps" and you change a project's
> "Context root" to something different from the project name, you will
> get two copies of the project served. One using the desired context
> root, and an auto-served one using the project's name. Using just
> <Context> elements to declare the WTP projects to be served provides
> much better control over the server.
Aw, now there is a bit of interesting inside information about the model
used, by Eclipse, for the deployment of webapps that I could not find
anywhere! I am not following you though, what "auto-deployment features"
are you referring to?
Eclipse uses the term "Context root" to refer to the "path" attribute of
a context, but I presume you are using it to refer to the "docBase"
attribute? I had no idea that the "Context root" and the project name
should be the same, but now I see there IS a connection between the
project name and the "docBase" attribute of the context associated with
a webapp deployed by Eclipse. And like I asked earlier, what does one do
about a webapp project that is to be deployed to the ROOT "docBase"?
I poked around with this and I don't see how a double deployment of a
project can happen. I cannot find a way to even set the "docBase"
attribute of a project's context, via the Eclipse GUI, let alone do it
in such a way that Eclipse would get confused. (Tomcat would, if I set
it directly in the server.xml file, but that is because the "docBase"
directory would not exist since, as far as I can tell, Eclipse does not
READ the server.xml file to figure out where to deploy apps to.) How can
it deploy to a directory with the projects name as well as to a
separate/different "docBase" / "Context root" directory? Nor do I follow
why using an "appBase" of "webapps" or "wtpwebapps" should affect
anything unless Eclipse is treating them differently. Tomcat certainly
does not care, it just wants to know where the "appBase" is and defaults
to assume "webapps" So I am not grokking you here..
Marc..
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #549795 is a reply to message #549781] |
Wed, 28 July 2010 00:35 |
Steve Blass
Messages: 276
Registered: July 2009 |
Senior Member |
|
|
Marc Chamberlin wrote:
> On 7/27/2010 7:33 AM, Larry Isaacs wrote:
>> On 7/26/2010 6:41 PM, Marc Chamberlin wrote:
>>> On 07/26/2010 01:48 PM, Marc Chamberlin wrote:
>>>> Hi - Done a lot of searching for an answer, but no joy! Can anyone
>>>> tell me how one sets up a project for a static website that will be
>>>> configured for a virtual host? I can't even figure out how to associate
>>>> a static website with a Tomcat6 server, let alone figure out how to set
>>>> the virtual webapp deployment directory for it!
>>>>
>>>> In the Tomcat directory, one normally has a basic webapp dir with a
>>>> ROOT
>>>> subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
>>>> virtual hosted domains it will be something like
>>>> ($CATALINA_HOME)->virtualDomain_webapps->ROOT
>>>> So how does one setup this sort of deployment within Eclipse? One
>>>> thought I had was to set up a second instance of a Tomcat server, and
>>>> give it a new deploy path, but I still do not see how to associate a
>>>> static website with it. And I don't want two different webprojects to
>>>> collide if both their context roots are set to ROOT
>>>>
>>>> Also, one other question that has been nagging me, and a bit of a
>>>> headache... Why does Eclipse set the name of the default deployment
>>>> directory to wtpwebapps instead of simply webapps? That raises havoc
>>>> with a lot of projects and Tomcat has no idea what this root deployment
>>>> directory is... It is a PITA if I forget to reconfigure this and it is
>>>> not the normal default webapp directory that comes with a basic Tomcat
>>>> installation. (Particularly since many of my web apps use generated
>>>> absolute paths in things like servlets and JSP code) Inquiring minds
>>>> are
>>>> curious! Wish I could find some good documentation on the models used
>>>> in Eclipse/WTP for project types, servers, deployment etc.... If there
>>>> is such, I am willing to read and grok on my own, but what I have found
>>>> so far is a far cry from getting me to being able to comprehend most of
>>>> the things I am being asked about, or want to configure!
>>>>
>>>> Marc...
>>>>
>>>>
>>> Nope! Cannot set up a second instance of Tomcat to solve the Virtual
>>> Host problem... If this cannot be configured to deploy properly in the
>>> local Eclipse workspace, then I hit too many other problems within our
>>> servlets... So... I am lost! Anyone got any ideas? Thanks in advance for
>>> advice and help...
>>>
>>> Marc...
>>>
>>
>> See if the Tomcat FAQ[1] helps with addressing these issues.
>>
>
> Thanks Larry for replying, appreciate it! No, no joy in the FAQs. When I
> create a new web project in Eclipse, and associate it with a Tomcat
> server, Eclipse picks up and makes a copy of the server.xml file from
> the systems Tomcat installation. This is where virtual hosts are
> defined. The trouble is I cannot figure out how to set up, or tell
> Eclipse to set up, the new "appBase" that is configured for each virtual
> host defined within the server.xml file. So, when the Eclipse instance
> of the Tomcat server starts up, it crashes, because these appBases are
> not defined/created within the Eclipse Tomcat instance version of its
> webapps directories. (I could create these, I think, by hand, but that
> still does not properly set up Eclipse so it will deploy a particular
> web app to the right appBase directory, for which it is suppose to run
> under.)
>
> The only thing close, that I have found, is the fact that when a new
> Tomcat server instance is defined, one is allowed to create a single
> "Deploy Path" name for that instance. That appears to me to be the
> equivalent of the appBase for a default Tomcat server installation, but
> as I said, for virtual hosts I need one of these for EACH virtual host...
>
> Let me try to boil down my confusion about webapps and ask the questions
> that I seek and answer to more directly. To define a context for a
> webapp, Tomcat requires up to 4 attributes to be defined, "host name",
> "appBase", "docBase", and "path". For a virtual host we need to define
> what the "host name" URL is for that virtual host. This is so that
> Tomcat can map this to an "appBase" which is the second of these 4
> attributes that must be defined. To deploy a webapp to a virtual host,
> Eclipse is going to have to understand this mapping as well and somehow
> allow the user to define the appBase for each webapp so that the
> deployment of that webapp project can take place properly. I don't see
> how to do that. For the default appBase, of Tomcat, this simply is
> "webapps" or in Eclipse's model it seems to be "wtpwebapps". In the
> server settings, I find that I can define a single "Deploy path" for any
> given server which by default is "wtpwebapps" so I presume the "appBase"
> and "Deploy path" are somewhat synonymous, BUT for virtual hosts I need
> to be able to define multiple "Deploy path"s / "appBase"s....
>
> The 3rd attribute of a context that needs to be defined is the "docBase"
> for a given webapp. I understand that Eclipse uses the Project name
> itself for the "docBase" attribute, but the one question I have then, is
> how do I map a webapp project to the "ROOT" docBase? Give the Project a
> name of ROOT? And if I have virtual hosts, that will not work as I am
> likely to have multiple apps that will want to reside in their
> respective "ROOT" directories. I must be missing something simple here,
> this is to obvious of a requirement!
>
> The 4th attribute of a context to be defined is "path" which defines the
> mapping from, for lack of a better way to say this, the extended portion
> of a URL (not the URL's host name portion) to a particular docBase.
> (for example, in "www.name.com/someApp, the base is "www.name.com" and
> is mapped via "host name" to the "appBase" and "/someApp" is the
> extended portion and mapped by "path" to "docBase") I figured out how
> to set the "path" attribute, by trial and error, in the Eclipse GUI, but
> will argue that Eclipse is using terminology that is in conflict with
> what is used in the Apache Tomcat documentation. In Eclipse, one sets
> the "path" attribute by bringing up the properties for a webapp, and
> going to the Web Project Settings, and filling in a field labeled
> "Context root" According to the Apache Tomcat documentation the "Context
> root" is referring to the "docBase" attribute, not the "path" attribute.
> I think that will be confusing to a lot of users, not just me... (see
> the description for the "docBase" attribute at
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html# Common_Attributes
> )
>
> I also tried to set the "Context root" / "path" attribute to empty, or
> "" but the GUI would not allow me to do so. I was thinking that perhaps
> Eclipse would then infer that the deployment of the webapp would be to
> the ROOT docBase directory. According to the Tomcat documentation, if
> the "path" attribute is set to "" or the empty string, then that context
> is defining the default web application for it's associated host. So
> again, I do not understand how to define the default web application.
>
> So, simply put, how does one define the attributes of "host name",
> "appBase", "docBase" and "path" for a dynamic web app so that Eclipse
> will understand how to deploy projects correctly? Hard for me to believe
> that Eclipse/WTP does not support virtual hosts, more likely I think is
> that I just don't understand how to do it... (I am still learning the
> ropes!) But, if not, my last two comments/questions about the "docBase"
> and "path" attributes remain valid....
>
>> Note that a Static Web Project isn't deployable to a Tomcat server
>> because the Tomcat only supports Dynamic Web Projects. You could create
>> a Dynamic Web Project and only put static content in it. The fact that
>> later versions of the servlet spec would allow a Static Web Project to
>> pretend to be a Dynamic Web Project doesn't currently help.
>
> Yes, I am headed in this direction already. The reason I was hesitant
> to use Dynamic Web Projects is that I deploy some of the web sites for
> virtual hosts via WAR files, and others are simply set up directly by
> users, and I am a bit reluctant about changing the structure of these
> sites out from under the way they were originally set up by their users.
> I wanted to be able to associate them with a Tomcat server however, so
> as to be able to help debug problems that arise, such as can happen when
> they use some of our hooks for SSI (server side includes), Javascripts,
> etc. But I have a workaround, I think, and can use an outside tool
> (Beyond Compare) to put back changes I make, while debugging these
> applications as Dynamic Web Projects, instead of creating for example, a
> new WAR file.... More manual/labor intensive however, sigh, and it means
> having to remove any original WAR files from the systems Tomcat
> directory, otherwise my changes will get overwritten....
>
>>
>> The reason for using "wtpwebapps" is to deliberately avoid the
>> auto-deployment features typically associated with "webapps". For
>> example, if you switch to using "webapps" and you change a project's
>> "Context root" to something different from the project name, you will
>> get two copies of the project served. One using the desired context
>> root, and an auto-served one using the project's name. Using just
>> <Context> elements to declare the WTP projects to be served provides
>> much better control over the server.
>
> Aw, now there is a bit of interesting inside information about the model
> used, by Eclipse, for the deployment of webapps that I could not find
> anywhere! I am not following you though, what "auto-deployment features"
> are you referring to?
>
> Eclipse uses the term "Context root" to refer to the "path" attribute of
> a context, but I presume you are using it to refer to the "docBase"
> attribute? I had no idea that the "Context root" and the project name
> should be the same, but now I see there IS a connection between the
> project name and the "docBase" attribute of the context associated with
> a webapp deployed by Eclipse. And like I asked earlier, what does one do
> about a webapp project that is to be deployed to the ROOT "docBase"?
>
> I poked around with this and I don't see how a double deployment of a
> project can happen. I cannot find a way to even set the "docBase"
> attribute of a project's context, via the Eclipse GUI, let alone do it
> in such a way that Eclipse would get confused. (Tomcat would, if I set
> it directly in the server.xml file, but that is because the "docBase"
> directory would not exist since, as far as I can tell, Eclipse does not
> READ the server.xml file to figure out where to deploy apps to.) How can
> it deploy to a directory with the projects name as well as to a
> separate/different "docBase" / "Context root" directory? Nor do I follow
> why using an "appBase" of "webapps" or "wtpwebapps" should affect
> anything unless Eclipse is treating them differently. Tomcat certainly
> does not care, it just wants to know where the "appBase" is and defaults
> to assume "webapps" So I am not grokking you here..
>
> Marc..
The deploy directory set in the GUI from the Servers View when you
doubleclick on the server and other launch parameters can be found if
you dig down into the 'Open launch configuration' link in the general
information section of the Server Editor.
When you set up a Dynamic Web Project you should see a Servers project
in your workspace too. The server.xml listed in that project can be
seasoned to taste. It may start out the same as the default tomcat
server.xml but it is not the same file. And some things like the webapps
directory are overriden by the arguments specified in the launch
configuration. The server.xml file gets copied down into the guts of
..metadata/.plugins/org.eclipse.wst.server.core/tmp0/conf folder next to
where the wtpwebapps deployment folder lives in your workspace. the
server.xml file seems to get published once so you have to Clean the
tomcat work folders from the context menu of the Servers View to get new
edits to server.xml published. You can have all sorts of fun with
contexts though. Keep backup copies of the text in your custom contexts
& etc. so that if you undeploy your app and redeploy you don't have to
conjure up the incantations from scratch again.
HTH
p.s. If you can use Tomcat under JBoss, Eclipse launches JBoss by the
book using the standard JBoss launch scripts without being anywhere near
as clever as it is when launching Tomcat.
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #549801 is a reply to message #549795] |
Wed, 28 July 2010 01:47 |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 07/27/2010 05:35 PM, Steve Blass wrote:
..... previous stuff removed....
> The deploy directory set in the GUI from the Servers View when you
> doubleclick on the server and other launch parameters can be found if
> you dig down into the 'Open launch configuration' link in the general
> information section of the Server Editor.
Thanks Steve for replying.. Hmmm perhaps we have a different version of
Eclipse? For me, when I doubleclick on a server, in the Servers View, I
get the Server Editor ok, but the Deploy Path is found immediately in
the Server Editor under a section titled "Server Locations" Not in the
popup dialog from the 'Open launch configuration' link.
>
> When you set up a Dynamic Web Project you should see a Servers project
> in your workspace too. The server.xml listed in that project can be
> seasoned to taste. It may start out the same as the default tomcat
> server.xml but it is not the same file. And some things like the webapps
> directory are overriden by the arguments specified in the launch
> configuration. The server.xml file gets copied down into the guts of
> .metadata/.plugins/org.eclipse.wst.server.core/tmp0/conf folder next to
> where the wtpwebapps deployment folder lives in your workspace. the
> server.xml file seems to get published once so you have to Clean the
> tomcat work folders from the context menu of the Servers View to get new
> edits to server.xml published. You can have all sorts of fun with
> contexts though. Keep backup copies of the text in your custom contexts
> & etc. so that if you undeploy your app and redeploy you don't have to
> conjure up the incantations from scratch again.
>
I think perhaps you are missing my point? I am trying to figure out how
to configure Eclipse to handle webapp projects that have to be deployed
to a VIRTUAL host, and not to the default host. I understand what
happens to the server.xml file, and I understand where the Eclipse
instance of Tomcat gets it's copies of webapps and configuration data.
BUT here is the issue, even if I were to go directly to
..metadata/.plugins/org.eclipse.wst.server.core/tmp0/ and create the
virtualHosts-webapp directories, and even perhaps populate them by hand,
I cannot figure out how to instruct Eclipse to work with and/or deploy a
webapp project to one of these virtual hosts based webapp directories.
It appears that Eclipse only allows a single deployment directory to be
configured for a server. But virtual hosting requires a separate
deployment directory for EACH virtual host configured to run, and they
all must run on a SINGLE Tomcat server. These are defined by a "host
name" and "appBase" attribute for the context of each virtual host.
My server.xml file has these defined, and as I said I could manually,
outside of Eclipse, set these up so that the Eclipse Tomcat instance
won't crash when it is started. BUT what good is that, if I cannot get
Eclipse to understand how to deploy webapps to virtual hosts? I can't
debug them, and I can't even create or load webapps that belong to a
virtual host, if Eclipse does not understand how they are to be deployed!
Almost every ISP that uses Tomcat servers, will configure their servers
to work with virtual hosts. That allows the ISP to use the same IP
address for multiple domains. It certainly ought to be possible, and not
difficult to figure out how to configure Eclipse to deploy webapps to
virtual hosts, and not just to the default host. But I don't grok the way...
> HTH
>
No, but thanks for trying!
> p.s. If you can use Tomcat under JBoss, Eclipse launches JBoss by the
> book using the standard JBoss launch scripts without being anywhere near
> as clever as it is when launching Tomcat.
Hmmm, no I am not using JBoss, and I am not familiar with it either. I
will go look at it, but not sure what it could bring to the table as far
as supporting virtual hosts in Eclipse is concerned. Eclipse is going to
have to understand how to fetch data from and deploy data to the virtual
hosts appBase (NOT just the default webapp/wtpwebapp and docBase!!!)
directories....
I am beginning to get a grim feeling that Eclipse/WTP has not been
designed to support virtual hosting??? If so, why haven't ISP's
complained or asked for it? Like I said, virtual hosting is very common,
but perhaps integrated virtual hosting/testing/support is not so common...
Marc....
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #550007 is a reply to message #549781] |
Wed, 28 July 2010 17:19 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 7/27/2010 6:07 PM, Marc Chamberlin wrote:
> On 7/27/2010 7:33 AM, Larry Isaacs wrote:
>> On 7/26/2010 6:41 PM, Marc Chamberlin wrote:
>>> On 07/26/2010 01:48 PM, Marc Chamberlin wrote:
>>>> Hi - Done a lot of searching for an answer, but no joy! Can anyone
>>>> tell me how one sets up a project for a static website that will be
>>>> configured for a virtual host? I can't even figure out how to associate
>>>> a static website with a Tomcat6 server, let alone figure out how to set
>>>> the virtual webapp deployment directory for it!
>>>>
>>>> In the Tomcat directory, one normally has a basic webapp dir with a
>>>> ROOT
>>>> subdir for the main website. ($CATALINA_HOME)->webapps->ROOT but for
>>>> virtual hosted domains it will be something like
>>>> ($CATALINA_HOME)->virtualDomain_webapps->ROOT
>>>> So how does one setup this sort of deployment within Eclipse? One
>>>> thought I had was to set up a second instance of a Tomcat server, and
>>>> give it a new deploy path, but I still do not see how to associate a
>>>> static website with it. And I don't want two different webprojects to
>>>> collide if both their context roots are set to ROOT
>>>>
>>>> Also, one other question that has been nagging me, and a bit of a
>>>> headache... Why does Eclipse set the name of the default deployment
>>>> directory to wtpwebapps instead of simply webapps? That raises havoc
>>>> with a lot of projects and Tomcat has no idea what this root deployment
>>>> directory is... It is a PITA if I forget to reconfigure this and it is
>>>> not the normal default webapp directory that comes with a basic Tomcat
>>>> installation. (Particularly since many of my web apps use generated
>>>> absolute paths in things like servlets and JSP code) Inquiring minds
>>>> are
>>>> curious! Wish I could find some good documentation on the models used
>>>> in Eclipse/WTP for project types, servers, deployment etc.... If there
>>>> is such, I am willing to read and grok on my own, but what I have found
>>>> so far is a far cry from getting me to being able to comprehend most of
>>>> the things I am being asked about, or want to configure!
>>>>
>>>> Marc...
>>>>
>>>>
>>> Nope! Cannot set up a second instance of Tomcat to solve the Virtual
>>> Host problem... If this cannot be configured to deploy properly in the
>>> local Eclipse workspace, then I hit too many other problems within our
>>> servlets... So... I am lost! Anyone got any ideas? Thanks in advance for
>>> advice and help...
>>>
>>> Marc...
>>>
>>
>> See if the Tomcat FAQ[1] helps with addressing these issues.
>>
>
> Thanks Larry for replying, appreciate it! No, no joy in the FAQs. When I
> create a new web project in Eclipse, and associate it with a Tomcat
> server, Eclipse picks up and makes a copy of the server.xml file from
> the systems Tomcat installation. This is where virtual hosts are
> defined. The trouble is I cannot figure out how to set up, or tell
> Eclipse to set up, the new "appBase" that is configured for each virtual
> host defined within the server.xml file. So, when the Eclipse instance
> of the Tomcat server starts up, it crashes, because these appBases are
> not defined/created within the Eclipse Tomcat instance version of its
> webapps directories. (I could create these, I think, by hand, but that
> still does not properly set up Eclipse so it will deploy a particular
> web app to the right appBase directory, for which it is suppose to run
> under.)
>
> The only thing close, that I have found, is the fact that when a new
> Tomcat server instance is defined, one is allowed to create a single
> "Deploy Path" name for that instance. That appears to me to be the
> equivalent of the appBase for a default Tomcat server installation, but
> as I said, for virtual hosts I need one of these for EACH virtual host...
>
> Let me try to boil down my confusion about webapps and ask the questions
> that I seek and answer to more directly. To define a context for a
> webapp, Tomcat requires up to 4 attributes to be defined, "host name",
> "appBase", "docBase", and "path". For a virtual host we need to define
> what the "host name" URL is for that virtual host. This is so that
> Tomcat can map this to an "appBase" which is the second of these 4
> attributes that must be defined. To deploy a webapp to a virtual host,
> Eclipse is going to have to understand this mapping as well and somehow
> allow the user to define the appBase for each webapp so that the
> deployment of that webapp project can take place properly. I don't see
> how to do that. For the default appBase, of Tomcat, this simply is
> "webapps" or in Eclipse's model it seems to be "wtpwebapps". In the
> server settings, I find that I can define a single "Deploy path" for any
> given server which by default is "wtpwebapps" so I presume the "appBase"
> and "Deploy path" are somewhat synonymous, BUT for virtual hosts I need
> to be able to define multiple "Deploy path"s / "appBase"s....
>
> The 3rd attribute of a context that needs to be defined is the "docBase"
> for a given webapp. I understand that Eclipse uses the Project name
> itself for the "docBase" attribute, but the one question I have then, is
> how do I map a webapp project to the "ROOT" docBase? Give the Project a
> name of ROOT? And if I have virtual hosts, that will not work as I am
> likely to have multiple apps that will want to reside in their
> respective "ROOT" directories. I must be missing something simple here,
> this is to obvious of a requirement!
>
> The 4th attribute of a context to be defined is "path" which defines the
> mapping from, for lack of a better way to say this, the extended portion
> of a URL (not the URL's host name portion) to a particular docBase. (for
> example, in "www.name.com/someApp, the base is "www.name.com" and is
> mapped via "host name" to the "appBase" and "/someApp" is the extended
> portion and mapped by "path" to "docBase") I figured out how to set the
> "path" attribute, by trial and error, in the Eclipse GUI, but will argue
> that Eclipse is using terminology that is in conflict with what is used
> in the Apache Tomcat documentation. In Eclipse, one sets the "path"
> attribute by bringing up the properties for a webapp, and going to the
> Web Project Settings, and filling in a field labeled "Context root"
> According to the Apache Tomcat documentation the "Context root" is
> referring to the "docBase" attribute, not the "path" attribute. I think
> that will be confusing to a lot of users, not just me... (see the
> description for the "docBase" attribute at
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html# Common_Attributes
> )
The servlet spec uses "context root" and "Context Path" to refer to the
same thing. The spec doesn't have anything about where webapps live, so
the "Context Root" mentioned in the Tomcat documentation for docBase is
something specific to Tomcat or is a mistake if it is mean to reference
the servlet spec.
>
> I also tried to set the "Context root" / "path" attribute to empty, or
> "" but the GUI would not allow me to do so. I was thinking that perhaps
> Eclipse would then infer that the deployment of the webapp would be to
> the ROOT docBase directory. According to the Tomcat documentation, if
> the "path" attribute is set to "" or the empty string, then that context
> is defining the default web application for it's associated host. So
> again, I do not understand how to define the default web application.
It's a bug that it won't accept an empty string. You can modify the
".settings/org.eclipse.wst.common.component" file in the project to set
the "context-root" property to a blank string. The next server publish
will update the server.xml file. The docBase can be what ever it needs
to be (i.e. where WTP published your project). If you enable "Publish
module contexts as separate XML files", the the WTP Tomcat support is
smart enough to name the context file ROOT.xml if the "Context root" is
blank. If you have this enabled, you can leave the "Context root" set
to "/". The Tomcat support will write the same context file as it would
for "". I'm not sure there is a way to write a context file for "/", so
this seemed the best alternative.
>
> So, simply put, how does one define the attributes of "host name",
> "appBase", "docBase" and "path" for a dynamic web app so that Eclipse
> will understand how to deploy projects correctly? Hard for me to believe
> that Eclipse/WTP does not support virtual hosts, more likely I think is
> that I just don't understand how to do it... (I am still learning the
> ropes!) But, if not, my last two comments/questions about the "docBase"
> and "path" attributes remain valid....
>
I think the fundamental problem here is that what WTP offers is some
integrated testing using various servers. This is all that is offered
in the case of Tomcat. What isn't currently offered in the WTP Tomcat
support is full Admin like control over the server. For example, when
you add and remove projects from the server, it will and remove
<Context> elements for those projects in a single <Host>. You don't get
to choose. This <Host> is selected using the following logic.
1. The <Service> named "Catalina" or "Tomcat-Standalone" is located. If
not found, the first <Service> is used.
2. Under that <Service> the <Engine> is located.
3. The <Host> that matches the <Engine>'s "defaultHost" is used. If
"defaultHost" is not specified, the <Host> named "localhost" is used.
If that host is not found, your Tomcat configuration is toast.
By using <Context> elements, the "host" is specified by where you
"place" the <Context> and "appBase" is irrelevant since auto deployment
is not being used. In the case of separate context XML files, placement
is controlled by the names used for the folders and XML file. Assuming
the logic above doesn't fit your need, then if the <Host> selected above
could be treated as a "dummy" host, you could copy the <Context> found
there for a web project to another <Host> configured as you see fit and
both would be served. As long as the <Context> in the "dummy" host
remains so the project gets published properly, the other <Context>
should work. This isn't something I've tested however.
>> Note that a Static Web Project isn't deployable to a Tomcat server
>> because the Tomcat only supports Dynamic Web Projects. You could create
>> a Dynamic Web Project and only put static content in it. The fact that
>> later versions of the servlet spec would allow a Static Web Project to
>> pretend to be a Dynamic Web Project doesn't currently help.
>
> Yes, I am headed in this direction already. The reason I was hesitant to
> use Dynamic Web Projects is that I deploy some of the web sites for
> virtual hosts via WAR files, and others are simply set up directly by
> users, and I am a bit reluctant about changing the structure of these
> sites out from under the way they were originally set up by their users.
> I wanted to be able to associate them with a Tomcat server however, so
> as to be able to help debug problems that arise, such as can happen when
> they use some of our hooks for SSI (server side includes), Javascripts,
> etc. But I have a workaround, I think, and can use an outside tool
> (Beyond Compare) to put back changes I make, while debugging these
> applications as Dynamic Web Projects, instead of creating for example, a
> new WAR file.... More manual/labor intensive however, sigh, and it means
> having to remove any original WAR files from the systems Tomcat
> directory, otherwise my changes will get overwritten....
It is possible to create a project folder in Eclipse that links to an
external folder. This could allow you to "include" external resources
in the project without exposing the external resources to the Dynamic
Web Project overhead. This would mean that the "Serve modules without
publishing" option could not be used because Tomcat won't be able to
duplicate that linking which only the Eclipse workspace knows about.
>
>>
>> The reason for using "wtpwebapps" is to deliberately avoid the
>> auto-deployment features typically associated with "webapps". For
>> example, if you switch to using "webapps" and you change a project's
>> "Context root" to something different from the project name, you will
>> get two copies of the project served. One using the desired context
>> root, and an auto-served one using the project's name. Using just
>> <Context> elements to declare the WTP projects to be served provides
>> much better control over the server.
>
> Aw, now there is a bit of interesting inside information about the model
> used, by Eclipse, for the deployment of webapps that I could not find
> anywhere! I am not following you though, what "auto-deployment features"
> are you referring to?
This would be the feature of Tomcat that auto-deploys folders and WAR
files found under the "appBase" folder.
>
> Eclipse uses the term "Context root" to refer to the "path" attribute of
> a context, but I presume you are using it to refer to the "docBase"
> attribute?
Eclipse is using the the servlet spec version of "Context root", which
disagrees with how Tomcat has used it when associating it with "docBase".
> I had no idea that the "Context root" and the project name
> should be the same, but now I see there IS a connection between the
> project name and the "docBase" attribute of the context associated with
> a webapp deployed by Eclipse. And like I asked earlier, what does one do
> about a webapp project that is to be deployed to the ROOT "docBase"?
Setting to "Context root" to blank (by manually editing the
".settings/org.eclipse.wst.common.component" file) or setting it to "/"
and enabling "Publish module contexts as separate XML files".
>
> I poked around with this and I don't see how a double deployment of a
> project can happen. I cannot find a way to even set the "docBase"
> attribute of a project's context, via the Eclipse GUI, let alone do it
> in such a way that Eclipse would get confused. (Tomcat would, if I set
> it directly in the server.xml file, but that is because the "docBase"
> directory would not exist since, as far as I can tell, Eclipse does not
> READ the server.xml file to figure out where to deploy apps to.) How can
> it deploy to a directory with the projects name as well as to a
> separate/different "docBase" / "Context root" directory? Nor do I follow
> why using an "appBase" of "webapps" or "wtpwebapps" should affect
> anything unless Eclipse is treating them differently. Tomcat certainly
> does not care, it just wants to know where the "appBase" is and defaults
> to assume "webapps" So I am not grokking you here..
>
> Marc..
I've covered some of the questions above and hope it covers most of what
you have asked about. Let me know what questions remain.
Cheers,
Larry
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #550310 is a reply to message #550007] |
Thu, 29 July 2010 20:57 |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 7/28/2010 10:19 AM, Larry Isaacs wrote:
stuff deleted....
>
> It's a bug that it won't accept an empty string. You can modify the
> ".settings/org.eclipse.wst.common.component" file in the project to set
> the "context-root" property to a blank string. The next server publish
> will update the server.xml file. The docBase can be what ever it needs
> to be (i.e. where WTP published your project). If you enable "Publish
> module contexts as separate XML files", the the WTP Tomcat support is
> smart enough to name the context file ROOT.xml if the "Context root" is
> blank. If you have this enabled, you can leave the "Context root" set to
> "/". The Tomcat support will write the same context file as it would for
> "". I'm not sure there is a way to write a context file for "/", so this
> seemed the best alternative.
>
Thanks so much Larry for being patient with me. I have experimented with
the "Publish module contexts as separate XML files" and found that if I
do NOT enable it, then yes, I can map the paths "/" or "" to a docBase
other than ROOT, and that works OK since Eclipse wants to publish a
project to a context/directory where the directory is set to the name of
the Eclipse project.
BUT IF I enable the "Publish module contexts as separate XML files" then
the ROOT context fails. (other contexts work ok) From what I can figure
out, the WTP Tomcat support is creating a ROOT.xml file BUT it is
setting the docBase attribute inside it. I think Tomcat only deploys web
applications base on the name of these context files. In fact, reading
the Tomcat documentation on Automatic Application Deployment, it pretty
much seems to say so, especially when the Host attribute of
"DeployOnStartup" is true (the default). In other words, when the
context files are published separately, the docBase attribute can only
be set in them if the docBase is outside of the host's appBase. This
indicates to me, that Tomcat is not going to ever honor the docBase
attribute setting, that Eclipse is producing inside of these module
context files, and thus one cannot remap a context to a different
docBase. Instead, Tomcat is going to use the name of the xml file, to
automatically set the docBase attribute for a particular context. So, in
order to use this feature of "Publish module contexts as separate XML
files." Eclipse is going to have to publish the webapp for the ROOT
context to the webApps/ROOT directory, and not to the
webApps/eclipseProjectName directory. As far as I can tell, that is not
happening, and I don't see how one can tell Eclipse to publish to a
specific directory.
I dunno if your response will be that this is a Tomcat bug, but I would
like to push back on Eclipse and say that if Eclipse would allow users
more control over where projects are published to, i.e. allow the user
to explicitly specify that myEclipseProjectName should be published to
($ECLIPSE_CATALINA_BASE)/webapps/ROOT instead of
/webapps/myEclipseProjectName then not only could the user get around
this particular Tomcat issue, but Eclipse could also support virtual
hosts as well, i.e allow the user to publish the project to
($ECLIPSE_CATALINA_BASE)/virtualHost_webapps/ROOT.
For now, I will not enable the "Publish module contexts as separate XML
files." since it does not seem to work for the ROOT context.
> I think the fundamental problem here is that what WTP offers is some
> integrated testing using various servers. This is all that is offered in
> the case of Tomcat. What isn't currently offered in the WTP Tomcat
> support is full Admin like control over the server. For example, when
> you add and remove projects from the server, it will and remove
> <Context> elements for those projects in a single <Host>. You don't get
> to choose. This <Host> is selected using the following logic.
>
> 1. The <Service> named "Catalina" or "Tomcat-Standalone" is located. If
> not found, the first <Service> is used.
> 2. Under that <Service> the <Engine> is located.
> 3. The <Host> that matches the <Engine>'s "defaultHost" is used. If
> "defaultHost" is not specified, the <Host> named "localhost" is used.
> If that host is not found, your Tomcat configuration is toast.
>
> By using <Context> elements, the "host" is specified by where you
> "place" the <Context> and "appBase" is irrelevant since auto deployment
> is not being used. In the case of separate context XML files, placement
> is controlled by the names used for the folders and XML file. Assuming
> the logic above doesn't fit your need, then if the <Host> selected above
> could be treated as a "dummy" host, you could copy the <Context> found
> there for a web project to another <Host> configured as you see fit and
> both would be served. As long as the <Context> in the "dummy" host
> remains so the project gets published properly, the other <Context>
> should work. This isn't something I've tested however.
If one is going to try an use Eclipse to debug and support webapps for
virtual hosts, I don't think you can get around the requirement of
needing to have separate appBase definitions for each virtual host. It
comes back to the issue of, for example, having to define a default/ROOT
context for each virtual host. If each of the virtual host's ROOT
context webapp is published to a directory within the default hosts
appBase, then how can you specify that there are multiple webapps which
want a ROOT context using "/" or "" for the path attribute? Eclipse
chokes on it, if you try, and won't allow it. If I specify within the
server.xml file that the virtual hosts are to use the same appBase
(webapps) as the default host, then Tomcat chokes when it sees two
contexts within that default appBase that are both defining the same
value for their path attribute.
I am a little uneasy, in any event, with trying to juggle context
definitions for webapps, so as to fit them within the server model that
Eclipse supports. My goal is to develop/support/debug webapps in the
context and organization that my production Tomcat server uses. One
advantage of having separate appBase definitions for each virtual host,
is to be able to chroot users to their own website. Another is that we
can deploy webapps with the same name to different virtual hosts
(configuring parameters only, as appropriate) and if Eclipse could
support virtual hosts and user definable deployment specifications (as
described above) then there would not be an issue with webapp name space
collisions.
Should I submit a bug report and request virtual host support in Eclipse
as an enhancement? I might be able to forge ahead, for now, by using
some external scripts to handle publication processes for virtual host
appBases, does Eclipse have any built in hooks to allow me to attach a
script to it's publication process? I don't know if Tomcat has, but I do
have access to it's launch scripts so perhaps I can hack something in
there...
Marc Chamberlin, JPrise Inc....
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #550480 is a reply to message #550310] |
Fri, 30 July 2010 14:00 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 7/29/2010 4:57 PM, Marc Chamberlin wrote:
> On 7/28/2010 10:19 AM, Larry Isaacs wrote:
>
> stuff deleted....
>
>>
>> It's a bug that it won't accept an empty string. You can modify the
>> ".settings/org.eclipse.wst.common.component" file in the project to set
>> the "context-root" property to a blank string. The next server publish
>> will update the server.xml file. The docBase can be what ever it needs
>> to be (i.e. where WTP published your project). If you enable "Publish
>> module contexts as separate XML files", the the WTP Tomcat support is
>> smart enough to name the context file ROOT.xml if the "Context root" is
>> blank. If you have this enabled, you can leave the "Context root" set to
>> "/". The Tomcat support will write the same context file as it would for
>> "". I'm not sure there is a way to write a context file for "/", so this
>> seemed the best alternative.
>>
>
> Thanks so much Larry for being patient with me. I have experimented with
> the "Publish module contexts as separate XML files" and found that if I
> do NOT enable it, then yes, I can map the paths "/" or "" to a docBase
> other than ROOT, and that works OK since Eclipse wants to publish a
> project to a context/directory where the directory is set to the name of
> the Eclipse project.
>
> BUT IF I enable the "Publish module contexts as separate XML files" then
> the ROOT context fails.
I'm not sure what you mean by fails. A project with a "Context root" of
"", or "/" with the option, becomes the default (i.e. ROOT) context, at
least it does for me.
> (other contexts work ok) From what I can figure
> out, the WTP Tomcat support is creating a ROOT.xml file BUT it is
> setting the docBase attribute inside it.
This is the correct behavior.
> I think Tomcat only deploys web
> applications base on the name of these context files.
Correct. The name of the context file is used to provide the path value
for the context, with the file name "ROOT" being a special alias for a
path value of "".
> In fact, reading
> the Tomcat documentation on Automatic Application Deployment, it pretty
> much seems to say so, especially when the Host attribute of
> "DeployOnStartup" is true (the default). In other words, when the
> context files are published separately, the docBase attribute can only
> be set in them if the docBase is outside of the host's appBase.
This is not correct. The docBase can specify a relative path in
addition to an absolute one. If relative, it is relative to the
"appBase" folder. A context XML file whose docBase is relative
overrides auto-deployment. Only folders under the appBase directory who
don't already have contexts defined by <Context>s in server.xml or
context XML files will be auto-deployed. This allows you to add
additional context configuration to the context file to be applied to
the webapp, which it wouldn't otherwise get if it just auto-deployed.
However, when such additional context configuration is desired, it is
more common to add a file named "context.xml" to the webapp's META-INF
folder. It is in this context XML file that a "docBase", as well as
"path", must not be set.
> This
> indicates to me, that Tomcat is not going to ever honor the docBase
> attribute setting, that Eclipse is producing inside of these module
> context files, and thus one cannot remap a context to a different
> docBase. Instead, Tomcat is going to use the name of the xml file, to
> automatically set the docBase attribute for a particular context.
This is not correct. The context file's name only affect the "path" value.
> So, in
> order to use this feature of "Publish module contexts as separate XML
> files." Eclipse is going to have to publish the webapp for the ROOT
> context to the webApps/ROOT directory, and not to the
> webApps/eclipseProjectName directory.
A context XML file named ROOT.xml will override the auto-deployment of
the "webapps/ROOT" webapp. Unfortunately, if the docBase in that
ROOT.xml points to "webapps/eclipseProjectName" and there is no
"eclipseProjectName.xml" context XML file, then Tomcat will auto-deploy
a second copy of that webapp with a context path of
"/eclipseProjectName". This is why Eclipse publishes the projects to
the "wtpwebapps" folder. It avoids auto-deploying the second copy
because the folder name under "webapps" doesn't match the intended
context path value.
> As far as I can tell, that is not
> happening, and I don't see how one can tell Eclipse to publish to a
> specific directory.
Eclipse knows how to specify the docBase appropriately, so supplying a
"specific directly" is not necessary.
> I dunno if your response will be that this is a Tomcat bug, but I would
> like to push back on Eclipse and say that if Eclipse would allow users
> more control over where projects are published to, i.e. allow the user
> to explicitly specify that myEclipseProjectName should be published to
> ($ECLIPSE_CATALINA_BASE)/webapps/ROOT instead of
> /webapps/myEclipseProjectName then not only could the user get around
> this particular Tomcat issue, but Eclipse could also support virtual
> hosts as well, i.e allow the user to publish the project to
> ($ECLIPSE_CATALINA_BASE)/virtualHost_webapps/ROOT.
>
> For now, I will not enable the "Publish module contexts as separate XML
> files." since it does not seem to work for the ROOT context.
It's not clear what is not working other than how Tomcat publishing is
doing it differs from what you expect. But it's what you expect that
isn't correct. It's hard to tell if this is a side effect of what you
are trying to accomplish with multiple virtual hosts, which currently is
beyond what the Tomcat plug-ins are designed to support.
>
>
>> I think the fundamental problem here is that what WTP offers is some
>> integrated testing using various servers. This is all that is offered in
>> the case of Tomcat. What isn't currently offered in the WTP Tomcat
>> support is full Admin like control over the server. For example, when
>> you add and remove projects from the server, it will and remove
>> <Context> elements for those projects in a single <Host>. You don't get
>> to choose. This <Host> is selected using the following logic.
>>
>> 1. The <Service> named "Catalina" or "Tomcat-Standalone" is located. If
>> not found, the first <Service> is used.
>> 2. Under that <Service> the <Engine> is located.
>> 3. The <Host> that matches the <Engine>'s "defaultHost" is used. If
>> "defaultHost" is not specified, the <Host> named "localhost" is used.
>> If that host is not found, your Tomcat configuration is toast.
>>
>> By using <Context> elements, the "host" is specified by where you
>> "place" the <Context> and "appBase" is irrelevant since auto deployment
>> is not being used. In the case of separate context XML files, placement
>> is controlled by the names used for the folders and XML file. Assuming
>> the logic above doesn't fit your need, then if the <Host> selected above
>> could be treated as a "dummy" host, you could copy the <Context> found
>> there for a web project to another <Host> configured as you see fit and
>> both would be served. As long as the <Context> in the "dummy" host
>> remains so the project gets published properly, the other <Context>
>> should work. This isn't something I've tested however.
>
> If one is going to try an use Eclipse to debug and support webapps for
> virtual hosts,
Unfortunately, supporting more than one host will likely be a major
piece of work. Given the few cycles my day job leaves me to work on the
Tomcat plug-ins, this isn't likely to happen any time soon. As far as I
know, the default/ROOT webapp handling works as designed for the one
host that Tomcat publishing supports.
> I don't think you can get around the requirement of
> needing to have separate appBase definitions for each virtual host. It
> comes back to the issue of, for example, having to define a default/ROOT
> context for each virtual host. If each of the virtual host's ROOT
> context webapp is published to a directory within the default hosts
> appBase, then how can you specify that there are multiple webapps which
> want a ROOT context using "/" or "" for the path attribute? Eclipse
> chokes on it, if you try, and won't allow it. If I specify within the
> server.xml file that the virtual hosts are to use the same appBase
> (webapps) as the default host, then Tomcat chokes when it sees two
> contexts within that default appBase that are both defining the same
> value for their path attribute.
The Tomcat plug-ins don't use appBase for serving published projects.
The problem is that it doesn't support publishing to more than one host,
virtual or not. So you can't publish more that one project with the
same "Context root" to Tomcat server because they have to publish to the
same host.
>
> I am a little uneasy, in any event, with trying to juggle context
> definitions for webapps, so as to fit them within the server model that
> Eclipse supports. My goal is to develop/support/debug webapps in the
> context and organization that my production Tomcat server uses. One
> advantage of having separate appBase definitions for each virtual host,
> is to be able to chroot users to their own website. Another is that we
> can deploy webapps with the same name to different virtual hosts
> (configuring parameters only, as appropriate) and if Eclipse could
> support virtual hosts and user definable deployment specifications (as
> described above) then there would not be an issue with webapp name space
> collisions.
>
> Should I submit a bug report and request virtual host support in Eclipse
> as an enhancement?
I would think that you could publish to one virtual host now. You are
welcome to file an enhancement request to support more that one host,
but as mentioned above, I wouldn't hold your breath.
> I might be able to forge ahead, for now, by using
> some external scripts to handle publication processes for virtual host
> appBases, does Eclipse have any built in hooks to allow me to attach a
> script to it's publication process? I don't know if Tomcat has, but I do
> have access to it's launch scripts so perhaps I can hack something in
> there...
The publishing is handled primarily within each server's plug-ins. I'm
not aware of any "hooks" in any of the WTP supplied server plug-ins. You
would have to modify code to alter the publishing behavior.
For multiple virtual hosts, I still think publishing to a "dummy" host
and manually copying <Context>s to other hosts would work. You would
have to have unique "Context-roots" for the projects so they could be
published to the "dummy" host without conflict. You could alter the
path as desired when copying the <Context> to the appropriate virtual
host. Since Run As -> Run on Server will give you a URL using the
"dummy" host, you will have to manually provide the URL in the browser
to the desired virtual host.
Cheers,
Larry
>
> Marc Chamberlin, JPrise Inc....
>
>
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #550561 is a reply to message #550480] |
Fri, 30 July 2010 19:29 |
Marc Chamberlin
Messages: 27
Registered: July 2009 |
Junior Member |
|
|
On 7/30/2010 7:00 AM, Larry Isaacs wrote:
> On 7/29/2010 4:57 PM, Marc Chamberlin wrote:
>> On 7/28/2010 10:19 AM, Larry Isaacs wrote:
>>
stuff deleted....
>>
>> Thanks so much Larry for being patient with me. I have experimented with
>> the "Publish module contexts as separate XML files" and found that if I
>> do NOT enable it, then yes, I can map the paths "/" or "" to a docBase
>> other than ROOT, and that works OK since Eclipse wants to publish a
>> project to a context/directory where the directory is set to the name of
>> the Eclipse project.
>>
>> BUT IF I enable the "Publish module contexts as separate XML files" then
>> the ROOT context fails.
>
> I'm not sure what you mean by fails. A project with a "Context root" of
> "", or "/" with the option, becomes the default (i.e. ROOT) context, at
> least it does for me.
By fail, I mean if I have eclipse create the ROOT.xml file, via the
"Publish module contests as separate XML files" then starting Tomcat
(Eclipse instance) and going to the URL - localhost:8086 I get an error
such as -
Jul 29, 2010 11:03:57 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3386 ms
Jul 29, 2010 11:09:07 AM org.apache.catalina.startup.HostConfig
deployDescriptor
SEVERE: Error deploying configuration descriptor .#ROOT.xml
java.io.FileNotFoundException:
/home/marc/eclipse/workspace/.metadata/.plugins/org.eclipse. wst.server.core/tmp0/conf/Catalina/localhost/.#ROOT.xml
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.apache.tomcat.util.digester.Digester.parse(Digester.java :1626)
at
org.apache.catalina.startup.HostConfig.deployDescriptor(Host Config.java:593)
at
org.apache.catalina.startup.HostConfig.deployDescriptors(Hos tConfig.java:563)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig .java:498)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java :1326)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostCo nfig.java:303)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119)
at
org.apache.catalina.core.ContainerBase.backgroundProcess(Con tainerBase.java:1337)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.processChildren(ContainerBase.java:1601)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.processChildren(ContainerBase.java:1610)
at
org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
Jul 29, 2010 11:09:17 AM org.apache.catalina.startup.HostConfig
checkResources
INFO: Undeploying context []
and the browser says -
type Status report
message /
description The requested resource (/) is not available.
hmmm The name of the xml files as reported by the stack walkback seems
odd - .#ROOT.xml I have no idea what/where the preceding .# comes from,
but would guess that some sort of temporary file should have been
created....
This is what is in ROOT.xml -
marc@bigbang :~/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.serv er.core/tmp0/conf/Catalina/localhost >
cat ROOT.xml
<?xml version="1.0" encoding="UTF-8"?>
<Context docBase="MarcsWebSite" reloadable="true"
source="org.eclipse.jst.jee.server:MarcsWebSite"/>
....
>> In fact, reading
>> the Tomcat documentation on Automatic Application Deployment, it pretty
>> much seems to say so, especially when the Host attribute of
>> "DeployOnStartup" is true (the default). In other words, when the
>> context files are published separately, the docBase attribute can only
>> be set in them if the docBase is outside of the host's appBase.
>
> This is not correct.
OK... but can I refer you to this URL -
http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Aut omatic%20Application%20Deployment
The first bullet says -
"Any XML file in $CATALINA_BASE/conf/[engine_name]/[host_name] is
assumed to be a context XML descriptor containing a Context element (and
its associated sub-elements) for a single web application. The web
applications associated with each of these context XML descriptor files
will be deployed first.
The docBase attribute of this <Context> element must only be set if the
docBase is outside the Host's appBase. For web applications located
inside the Host's appBase, the docBase will be the name of the XML file
with ".xml" replaced with ".war" for a web application archive or the
name of the XML file with ".xml" removed for a directory."
Is the Tomcat6 documentation wrong? If not, how am I misreading it?
The docBase can specify a relative path in addition
> to an absolute one. If relative, it is relative to the "appBase" folder.
> A context XML file whose docBase is relative overrides auto-deployment.
> Only folders under the appBase directory who don't already have contexts
> defined by <Context>s in server.xml or context XML files will be
> auto-deployed. This allows you to add additional context configuration
> to the context file to be applied to the webapp, which it wouldn't
> otherwise get if it just auto-deployed. However, when such additional
> context configuration is desired, it is more common to add a file named
> "context.xml" to the webapp's META-INF folder. It is in this context XML
> file that a "docBase", as well as "path", must not be set.
Yes, I agree with all of this as well, and this is stated else where in
the Tomcat documentation. But the part above is what is confusing me!
You and the Tomcat doc seem to be saying two different things....
>
>> This
>> indicates to me, that Tomcat is not going to ever honor the docBase
>> attribute setting, that Eclipse is producing inside of these module
>> context files, and thus one cannot remap a context to a different
>> docBase. Instead, Tomcat is going to use the name of the xml file, to
>> automatically set the docBase attribute for a particular context.
>
> This is not correct. The context file's name only affect the "path" value.
Well that makes sense to me also, and it seems right that the context
file's name should be reflected by the "path" and not by the "docBase"
But from experimenting with it, and from Tomcat's documentation that I
pointed out above, this does not seem to be reflected in the behavior of
Tomcat... Something is fishy here or I am just not groking what is going
on....
>
>> So, in
>> order to use this feature of "Publish module contexts as separate XML
>> files." Eclipse is going to have to publish the webapp for the ROOT
>> context to the webApps/ROOT directory, and not to the
>> webApps/eclipseProjectName directory.
>
> A context XML file named ROOT.xml will override the auto-deployment of
> the "webapps/ROOT" webapp. Unfortunately, if the docBase in that
> ROOT.xml points to "webapps/eclipseProjectName" and there is no
> "eclipseProjectName.xml" context XML file, then Tomcat will auto-deploy
> a second copy of that webapp with a context path of
> "/eclipseProjectName". This is why Eclipse publishes the projects to the
> "wtpwebapps" folder. It avoids auto-deploying the second copy because
> the folder name under "webapps" doesn't match the intended context path
> value.
Yes, because I am deploying to the "webapps" folder and not to
"wtpwebapps", I would expect that both of these URL's would work for the
ROOT context, if typed into a browser -
localhost:8086/
and
localhost:8086/eclipseProjectName
essentially giving me the same document in the browser. For my
situation, the first MUST work, and I don't really care if the second
also works. I am deploying to and using the "webapps" folder because I
have servlets that are dependent on the absolute path to a docBase and
they have the "webapp" folder embedded in their internal path
designations via code that I cannot touch. (I can handle this in my
Eclipse debug environment, with some workarounds, and yes this probably
should be handled differently, but it wasn't and I have to live with it
for now.. It would be a mess to clean it all up in a more robust
fashion, for our production environment, where these absolute paths
should be discovered at runtime rather than explicitly set at compile
time...)
Anywise, as I previously stated, when I configure Eclipse to create the
ROOT.xml context file, the first URL pattern fails (as described above),
the second works but is unsuitable.
>
>> As far as I can tell, that is not
>> happening, and I don't see how one can tell Eclipse to publish to a
>> specific directory.
>
> Eclipse knows how to specify the docBase appropriately, so supplying a
> "specific directly" is not necessary.
>
>> I dunno if your response will be that this is a Tomcat bug, but I would
>> like to push back on Eclipse and say that if Eclipse would allow users
>> more control over where projects are published to, i.e. allow the user
>> to explicitly specify that myEclipseProjectName should be published to
>> ($ECLIPSE_CATALINA_BASE)/webapps/ROOT instead of
>> /webapps/myEclipseProjectName then not only could the user get around
>> this particular Tomcat issue, but Eclipse could also support virtual
>> hosts as well, i.e allow the user to publish the project to
>> ($ECLIPSE_CATALINA_BASE)/virtualHost_webapps/ROOT.
>>
>> For now, I will not enable the "Publish module contexts as separate XML
>> files." since it does not seem to work for the ROOT context.
>
> It's not clear what is not working other than how Tomcat publishing is
> doing it differs from what you expect. But it's what you expect that
> isn't correct. It's hard to tell if this is a side effect of what you
> are trying to accomplish with multiple virtual hosts, which currently is
> beyond what the Tomcat plug-ins are designed to support.
Yeah, set aside the multiple virtual host issue for now. I was just
trying to point out that trying to "Publish module contexts as separate
XMLfiles." failed for me when it came to the ROOT context. I tried to
research why, and explain what I discovered, since I think it will be of
interest to you, the WTP team, and possibly other users. There seems to
be a disconnect or bug somewhere. As I said also, if I don't publish the
module contexts as separate XMLfiles, then the context definitions, as
defined in the server.xml file that Eclipse creates, do work properly
for the ROOT context.
>
stuff deleted...
> Unfortunately, supporting more than one host will likely be a major
> piece of work. Given the few cycles my day job leaves me to work on the
> Tomcat plug-ins, this isn't likely to happen any time soon.
Don't I KNOW IT!!! I got the same few cycles... Understood...
more stuff deleted..
>
> I would think that you could publish to one virtual host now. You are
> welcome to file an enhancement request to support more that one host,
> but as mentioned above, I wouldn't hold your breath.
Your call... Doesn't sound like you have had other requests for handling
virtual hosts, and I am probably the first to come along and try and use
Eclipse in an environment where virtual hosts are more tightly
integrated/coupled than what is normally found, with cross coupled
servlets and common SSI scripts being used. (these deploy information
and tools across multiple virtual host's webapps)
>
> The publishing is handled primarily within each server's plug-ins. I'm
> not aware of any "hooks" in any of the WTP supplied server plug-ins. You
> would have to modify code to alter the publishing behavior.
That is too bad, would have made things a bit easier in our development
environment to be able to automate some of the additional publication
that is going to be necessary...
>
> For multiple virtual hosts, I still think publishing to a "dummy" host
> and manually copying <Context>s to other hosts would work. You would
> have to have unique "Context-roots" for the projects so they could be
> published to the "dummy" host without conflict. You could alter the path
> as desired when copying the <Context> to the appropriate virtual host.
> Since Run As -> Run on Server will give you a URL using the "dummy"
> host, you will have to manually provide the URL in the browser to the
> desired virtual host.
For some parts of our application, you are possibly right, but as I
mention, the snag is that ultimately the architecture of the directories
in the Eclipse environment must mimic the architecture of the
directories in the production environment.
Thanks again so much for your time Larry, and explanations...
Marc Chamberlin, JPrise Inc....
|
|
|
| Re: How to set up a virtual host website with Tomcat6 [message #550590 is a reply to message #550561] |
Sat, 31 July 2010 00:23 |
Larry Isaacs
Messages: 1354
Registered: July 2009 |
Senior Member |
|
|
On 7/30/2010 3:29 PM, Marc Chamberlin wrote:
> On 7/30/2010 7:00 AM, Larry Isaacs wrote:
>> On 7/29/2010 4:57 PM, Marc Chamberlin wrote:
>>> On 7/28/2010 10:19 AM, Larry Isaacs wrote:
>>>
<snip/>
>
> By fail, I mean if I have eclipse create the ROOT.xml file, via the
> "Publish module contests as separate XML files" then starting Tomcat
> (Eclipse instance) and going to the URL - localhost:8086 I get an error
> such as -
>
> Jul 29, 2010 11:03:57 AM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 3386 ms
> Jul 29, 2010 11:09:07 AM org.apache.catalina.startup.HostConfig
> deployDescriptor
> SEVERE: Error deploying configuration descriptor .#ROOT.xml
> java.io.FileNotFoundException:
> /home/marc/eclipse/workspace/.metadata/.plugins/org.eclipse. wst.server.core/tmp0/conf/Catalina/localhost/.#ROOT.xml
> (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:106)
> at org.apache.tomcat.util.digester.Digester.parse(Digester.java :1626)
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(Host Config.java:593)
>
> at
> org.apache.catalina.startup.HostConfig.deployDescriptors(Hos tConfig.java:563)
>
> at org.apache.catalina.startup.HostConfig.deployApps(HostConfig .java:498)
> at org.apache.catalina.startup.HostConfig.check(HostConfig.java :1326)
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostCo nfig.java:303)
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent (LifecycleSupport.java:119)
>
> at
> org.apache.catalina.core.ContainerBase.backgroundProcess(Con tainerBase.java:1337)
>
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.processChildren(ContainerBase.java:1601)
>
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.processChildren(ContainerBase.java:1610)
>
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundPr ocessor.run(ContainerBase.java:1590)
>
> at java.lang.Thread.run(Thread.java:619)
> Jul 29, 2010 11:09:17 AM org.apache.catalina.startup.HostConfig
> checkResources
> INFO: Undeploying context []
>
> and the browser says -
>
> type Status report
> message /
> description The requested resource (/) is not available.
>
>
> hmmm The name of the xml files as reported by the stack walkback seems
> odd - .#ROOT.xml I have no idea what/where the preceding .# comes from,
> but would guess that some sort of temporary file should have been
> created....
Tomcat supports multi-level paths, i.e. you could specify a path like
"app/subapp" and you would access it with
"http://host:port/app/subapp/..". The "/" in the path is represented
by "#" in the context file name, i.e. app#subapp.xml would be the name
for the context file. A bogus file or folder named ".#ROOT.xml"
probably exists, but may be hidden from normal viewing due to the
beginning period. My guess is that the "Publish module contexts to
separate XML files" option managed not to handle something correctly may
have caused this. It may be something that only happens on *nix
systems. I'll investigate further.
By the way, I'm incorrect about "Publish module contexts to separate XML
files" being required if the "Context root" is "/". It turns out that
the server.xml under the Servers project in your workspace will contain
path="/", but this is changed to path="" when the server.xml is
published to the "conf" folder.
>
> This is what is in ROOT.xml -
>
> marc@bigbang :~/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.serv er.core/tmp0/conf/Catalina/localhost >
> cat ROOT.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <Context docBase="MarcsWebSite" reloadable="true"
> source="org.eclipse.jst.jee.server:MarcsWebSite"/>
>
>
Okay, I'm in error about the context file name applying only to path.
If a docBase is present and is a relative value, it is required to agree
with the path. Thus the docBase in the above ROOT.xml would be required
be "ROOT" to work. I forget when Tomcat added this requirement, but it
helps avoid unintended deployments. The ROOT.xml above would imply a
"MarcsWebSite" would be auto-deployed as "/MarcsWebSite".
> ...
>
>>> In fact, reading
>>> the Tomcat documentation on Automatic Application Deployment, it pretty
>>> much seems to say so, especially when the Host attribute of
>>> "DeployOnStartup" is true (the default). In other words, when the
>>> context files are published separately, the docBase attribute can only
>>> be set in them if the docBase is outside of the host's appBase.
>>
>> This is not correct.
>
> OK... but can I refer you to this URL -
>
> http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#Aut omatic%20Application%20Deployment
>
>
> The first bullet says -
>
> "Any XML file in $CATALINA_BASE/conf/[engine_name]/[host_name] is
> assumed to be a context XML descriptor containing a Context element (and
> its associated sub-elements) for a single web application. The web
> applications associated with each of these context XML descriptor files
> will be deployed first.
> The docBase attribute of this <Context> element must only be set if the
> docBase is outside the Host's appBase. For web applications located
> inside the Host's appBase, the docBase will be the name of the XML file
> with ".xml" replaced with ".war" for a web application archive or the
> name of the XML file with ".xml" removed for a directory."
>
> Is the Tomcat6 documentation wrong? If not, how am I misreading it?
The "must only be set if" is technically not accurate, but doesn't hurt.
If you specify a docBase and it's value is the same as what Tomcat
would have required based on the context file's name, then Tomcat will
let it pass.
>
> The docBase can specify a relative path in addition
>> to an absolute one. If relative, it is relative to the "appBase" folder.
>> A context XML file whose docBase is relative overrides auto-deployment.
>> Only folders under the appBase directory who don't already have contexts
>> defined by <Context>s in server.xml or context XML files will be
>> auto-deployed. This allows you to add additional context configuration
>> to the context file to be applied to the webapp, which it wouldn't
>> otherwise get if it just auto-deployed. However, when such additional
>> context configuration is desired, it is more common to add a file named
>> "context.xml" to the webapp's META-INF folder. It is in this context XML
>> file that a "docBase", as well as "path", must not be set.
>
> Yes, I agree with all of this as well, and this is stated else where in
> the Tomcat documentation. But the part above is what is confusing me!
> You and the Tomcat doc seem to be saying two different things....
>
> Well that makes sense to me also, and it seems right that the context
> file's name should be reflected by the "path" and not by the "docBase"
> But from experimenting with it, and from Tomcat's documentation that I
> pointed out above, this does not seem to be reflected in the behavior of
> Tomcat... Something is fishy here or I am just not groking what is going
> on....
>
My error. See above.
<snip/>
> Yes, because I am deploying to the "webapps" folder and not to
> "wtpwebapps", I would expect that both of these URL's would work for the
> ROOT context, if typed into a browser -
>
> localhost:8086/
>
> and
>
> localhost:8086/eclipseProjectName
>
> essentially giving me the same document in the browser. For my
> situation, the first MUST work, and I don't really care if the second
> also works.
Publishing to "webapps" (i.e. the appBase directory) and enabling
"Publish module contexts to separate XML files" is going to have
problems. Fortunately, I was wrong about needing this option if the
"Context root" is set to "/".
> I am deploying to and using the "webapps" folder because I
> have servlets that are dependent on the absolute path to a docBase and
> they have the "webapp" folder embedded in their internal path
> designations via code that I cannot touch.
Ouch! I guess the Tomcat developers should feel complemented that
someone would hardcode use of their server into the software.
> (I can handle this in my
> Eclipse debug environment, with some workarounds, and yes this probably
> should be handled differently, but it wasn't and I have to live with it
> for now.. It would be a mess to clean it all up in a more robust
> fashion, for our production environment, where these absolute paths
> should be discovered at runtime rather than explicitly set at compile
> time...)
>
> Anywise, as I previously stated, when I configure Eclipse to create the
> ROOT.xml context file, the first URL pattern fails (as described above),
> the second works but is unsuitable.
>
You could create a "dummy" directory under
".metadata/.plugins/org.eclipse.wst.server.core/tmp0" and set appBase to
point to "dummy". That would avoid the appBase issues and allow
"webapps" to function the same as "wtpwebapps". I believe this would
get your "ROOT" URL working.
<snip/>
>
> Yeah, set aside the multiple virtual host issue for now. I was just
> trying to point out that trying to "Publish module contexts as separate
> XMLfiles." failed for me when it came to the ROOT context. I tried to
> research why, and explain what I discovered, since I think it will be of
> interest to you, the WTP team, and possibly other users. There seems to
> be a disconnect or bug somewhere. As I said also, if I don't publish the
> module contexts as separate XMLfiles, then the context definitions, as
> defined in the server.xml file that Eclipse creates, do work properly
> for the ROOT context.
As mentioned above, this option may has a *nix related bug that I'll
look into and isn't required for "Context root" set to "/".
<snip/>
>>
>> For multiple virtual hosts, I still think publishing to a "dummy" host
>> and manually copying <Context>s to other hosts would work. You would
>> have to have unique "Context-roots" for the projects so they could be
>> published to the "dummy" host without conflict. You could alter the path
>> as desired when copying the <Context> to the appropriate virtual host.
>> Since Run As -> Run on Server will give you a URL using the "dummy"
>> host, you will have to manually provide the URL in the browser to the
>> desired virtual host.
>
> For some parts of our application, you are possibly right, but as I
> mention, the snag is that ultimately the architecture of the directories
> in the Eclipse environment must mimic the architecture of the
> directories in the production environment.
You might want to consider changing the server location from "Use
workspace metadata..." to "Use custom location..." and point to a folder
inside a Simple project in your workspace. This would give you easy
access to the "conf" directory. You could publish each project to the
"localhost" host with "webapps" as the "Deploy path" with
non-conflicting "Context root" values in the projects. Then within your
workspace you could manually create the context files for the virtual
hosts, specifying an absolute docBase to the appropriate folder under
"webapps", and whatever path you need. The only requirement is that the
appBase values for the various hosts point to some other directory than
the "webapps" folder.
Cheers,
Larry
>
> Thanks again so much for your time Larry, and explanations...
>
> Marc Chamberlin, JPrise Inc....
>
|
|
|
Goto Forum:
Current Time: Thu Apr 18 12:36:44 GMT 2024
Powered by FUDForum. Page generated in 0.04000 seconds |
] 
Search
Help
Register
Login
Home
