4:10 p.m.
Hi,
In AS 5 (I believe), we added the capability to deploy a webapp to
multiple vhosts. While nice in practice, this causes the need for a
hack where one webapp can be deployed multiple times to each specified
vhost, as well as automagic vhost creation. I've never liked this
behavior (I think vhost creation should require some administrator
intervention), and this hack is now causing problems with the new
naming. It should be possible to drop this feature to a large extent.
Instead, what could happen is that the list of specified vhosts would
now need to either point to one single existing host (any non existing
vhosts would be added as aliases to that vhost). If nothing exists,
they would be added as aliases to the default host.
This should actually cover most reasonable use cases.
Rémy
10:41 p.m.
On 8/27/10 9:10 AM, Remy Maucherat wrote:
Hi,
In AS 5 (I believe), we added the capability to deploy a webapp to
multiple vhosts. While nice in practice, this causes the need for a
hack where one webapp can be deployed multiple times to each specified
vhost, as well as automagic vhost creation. I've never liked this
behavior (I think vhost creation should require some administrator
intervention), and this hack is now causing problems with the new
naming. It should be possible to drop this feature to a large extent.
I have to agree that vhost configs really should be configured by
admins. When you have auto vhost creation it's hard to differentiate
between an error (type-o in the host) and a legitimate new vhost.
Instead, what could happen is that the list of specified vhosts
would
now need to either point to one single existing host (any non existing
vhosts would be added as aliases to that vhost). If nothing exists,
they would be added as aliases to the default host.
This should actually cover most reasonable use cases.
Sounds more reasonable to me. Although, what was the reason behind the
auto vhost generation? Was it to avoid restarting the server?
--
Jason T. Greene
JBoss, a division of Red Hat
11:38 p.m.
On Fri, Aug 27, 2010 at 10:41 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
Sounds more reasonable to me. Although, what was the reason behind
the
auto vhost generation? Was it to avoid restarting the server?
Scott added it due to customer demand, I believe, because it was
indeed hard to do anything without restarting at the time (you could
have used JMX possibly, and that was it; now, I think the admin
console should be able to do it). (Maybe it was also to be able to
deploy a webapp to all vhosts, but it's less likely)
So a trimmed down feature (focusing only on aliases) could be enough for AS 6.
AS 7 has host (ahem, virtual-server) configuration in the domain
model, which should be fully dynamic.
Rémy
1:17 p.m.
Am 27.08.2010 um 23:38 schrieb Remy Maucherat:
On Fri, Aug 27, 2010 at 10:41 PM, Jason T. Greene
<jason.greene(a)redhat.com> wrote:
> Sounds more reasonable to me. Although, what was the reason behind the
> auto vhost generation? Was it to avoid restarting the server?
Scott added it due to customer demand, I believe, because it was
indeed hard to do anything without restarting at the time (you could
have used JMX possibly, and that was it; now, I think the admin
console should be able to do it). (Maybe it was also to be able to
deploy a webapp to all vhosts, but it's less likely)
Please make sure, management methods for the vhosts
are present as well.
In previous AS versions, one had to parse MBean names
to 'guess' the vhosts.
We have/had huge issues in JON when writing the response time
gathering, as there is no way to get the vhost a request is targeted
to from the web container.
Heiko
1:28 p.m.
On Thu, Sep 16, 2010 at 1:17 PM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
Please make sure, management methods for the vhosts
are present as well.
Ok, let me know what you need and I can have a look.
In previous AS versions, one had to parse MBean names
to 'guess' the vhosts.
The object name does contain the vhost name, that's also something
which is used in the AS code.
We have/had huge issues in JON when writing the response time
gathering, as there is no way to get the vhost a request is targeted
to from the web container.
A webapp does not have a Request.getHost method. You could use a valve
rather than a filter to collect that information.
Rémy
4971
days inactive
4991
days old
jboss-development@lists.jboss.org
4 comments
3 participants
participants (3)
-
Heiko W.Rupp -
Jason T. Greene -
Remy Maucherat