You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Costin Manolache <cm...@yahoo.com> on 2003/04/23 21:44:50 UTC
Re: TC5 JMX domain engine issue
Amy Roh wrote:
>>>Personally, here's what I would like:
>>>- 1 engine <-> 1 domain <-> 1 service
>>
>>
>> That provides the cleanest solution for tomcat, and I don't think it
>> hurts anything. We can still have as many engines as we want in the VM.
>
> The problem is that this doesn't follow jsr77. You should be able to
> have more than one server(engine) under one domain (see jsr77.3.2). If
> we treat engine's name as domain and not allow multiple engines under
> one domain we're skipping one level (j2eeserver) and problems occur.
Can you have more than one J2EE server under one domain ?
Is there anything in the J2EE spec that requires a J2EE server to support
more than one Servlet Engine ?
Please keep in mind that tomcat itself ( the Engine, connectors, etc ) are
_not_ constrainted by JSR77. Only the WebModule and Servlet are defined in
77.
>>>- An option to configure in which domain the JSR 77 beans go (the other
>>>parts of the appserver must have their stuff in the same domain I assume)
>>
>>
>> I'm leaning toward this option as well. I agree with Amy, registering
>> them in both tomcat and j2ee domain is hacky.
>
> Yeah, I don't think this is a good elegant long term solution. We don't
> want to have two mbeans registered in two different domains. When a
> user browses through WebModule & Servlet jsr77 mbeans, you'll see two
> registered in j2eedomain and tomcat each. Hacky.
There is no need to register them twice. The mapper receives notifications
for all domains.
You can register WebModules in any domain - all we need is an attribute (
not even part of the name ) that tells wich engine it needs to be
registered in.
>> Multiple Engines are not a bad thing, quite the contrary. But
>> they should be used in a clean way. JMX domains are a good way to
>> organize the info.
>
> I agree we should decide to use a clean way that follows the spec to
> achieve this goal.
+1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
be able to place them in the j2eeServer domain, and if multiple engines are
used each must use the same domain for webmodules ( as long as they are
part of the same j2eeServer ).
That doesn't impose any restrictions on the domain for tomcat.
We could as well use one domain for the Engine, Mapper and all
servlet-implementation components, and a separate domain for the connector.
( for a use case of having one connector used for multiple engines for
example.
Placing too many components in the same domain results in a mess. It may be
much better to not place non-JSR77 components ( like Engine or Connector )
in the jsr77 domain.
The only issue is that the components registered in jsr77 for WebModule
should be either StandardContext or a proxy/wrapper that exposes the info
and operations in StandardContext. Maybe with some changes ( for Statistics
for example ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@sun.com>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
>>it's in j2ee container and add "engineName" so it knows which engine,
>>correct? Since servlets use context's domain, I don't think we need
>>domain change code there.
>
>
> getDomain already exists ( in ContainerBase ).
I think we also need to add setDomain to set j2eeDomain in case
deployment isn't done using jmx.
> I'll add "engineName" attribute, if set it'll be used instead of the domain.
Cool.
> How do you deploy the contexts ? My prefference is:
> - create the mbean with whatever name you want ( in your favorite j2ee
> domain ), and the code o.a.c.core.StandardContext
> - set the attributes, including engineName
> - call init - which will look for the engine and register itself.
> - call start ( I think start calls init() if not already done, so in case
> you're using the jsr77 lifecycle - which doesn't have init - you're can
> call directly start )
Sounds good.
> You can still do it directly ( as server.xml does ), but it would help if we
> would settle on the jmx method for cases where tomcat is embeded in another
> app.
We can still keep this for backward compatibility.
>>I can revert the admin changes so it's working once again ;-).
>
>
> A lot of things depend on name stability.
>
> That is one of the reasons I would like tomcat to use JSR77 names whenever
> possible ( i.e. contexts/servlets ).
>
> I think it is probably the time ( i.e. after all this discussion ends ) to
> freeze all JMX names.
+1000000... I think we're getting there.
Once we settle JMX names, admin, and other issues(?) we can finally tag
5.0.2 hopefully.
Thanks,
Amy
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
> it's in j2ee container and add "engineName" so it knows which engine,
> correct? Since servlets use context's domain, I don't think we need
> domain change code there.
getDomain already exists ( in ContainerBase ).
I'll add "engineName" attribute, if set it'll be used instead of the domain.
How do you deploy the contexts ? My prefference is:
- create the mbean with whatever name you want ( in your favorite j2ee
domain ), and the code o.a.c.core.StandardContext
- set the attributes, including engineName
- call init - which will look for the engine and register itself.
- call start ( I think start calls init() if not already done, so in case
you're using the jsr77 lifecycle - which doesn't have init - you're can
call directly start )
You can still do it directly ( as server.xml does ), but it would help if we
would settle on the jmx method for cases where tomcat is embeded in another
app.
> I can revert the admin changes so it's working once again ;-).
A lot of things depend on name stability.
That is one of the reasons I would like tomcat to use JSR77 names whenever
possible ( i.e. contexts/servlets ).
I think it is probably the time ( i.e. after all this discussion ends ) to
freeze all JMX names.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>I don't know about having _all_ names in the same domain. However,
>>webmodules and servlets should be under the same domain as the
>>J2EEServer who's responsible for its deployment.
>
>
> Ok. As long as they are not _required_ to be in the same domain with
> the servlet engine internal components.
>
> It makes sense - if we consider that in this case the j2ee server is
> actually responsible for the webapps ( deployment, lifecycle ).
>
>
>
>>>If this is the case - the only option is to treat tomcat as a separate
>>>entity, in a separate domain from the webapps.
>>>
>>>We have 3 options:
>>>- Webapps registered once, in the jsr77Domain. Tomcat will listen for
>>>events and register them, but nothing else ( i.e. no contexts in the
>>>tomcat domain)
>>
>>+1. We can keep context mbeans under tomcat domain in tomcat standalone
>>case - keep it the way it is?
>
>
> Ok.
>
> Are you already working on this ? I can try a quick fix, it shouldn't be
> very difficult. ( probably this evening or tommorow night ).
OK. So we'll add get/setDomain for StandardContext to set j2eeDomain if
it's in j2ee container and add "engineName" so it knows which engine,
correct? Since servlets use context's domain, I don't think we need
domain change code there.
I can revert the admin changes so it's working once again ;-).
Thanks,
Amy
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
> I don't know about having _all_ names in the same domain. However,
> webmodules and servlets should be under the same domain as the
> J2EEServer who's responsible for its deployment.
Ok. As long as they are not _required_ to be in the same domain with
the servlet engine internal components.
It makes sense - if we consider that in this case the j2ee server is
actually responsible for the webapps ( deployment, lifecycle ).
>> If this is the case - the only option is to treat tomcat as a separate
>> entity, in a separate domain from the webapps.
>>
>> We have 3 options:
>> - Webapps registered once, in the jsr77Domain. Tomcat will listen for
>> events and register them, but nothing else ( i.e. no contexts in the
>> tomcat domain)
>
> +1. We can keep context mbeans under tomcat domain in tomcat standalone
> case - keep it the way it is?
Ok.
Are you already working on this ? I can try a quick fix, it shouldn't be
very difficult. ( probably this evening or tommorow night ).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@apache.org>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>>>Personally, here's what I would like:
>>>>>>- 1 engine <-> 1 domain <-> 1 service
>>>>>
>>>>>
>>>>>That provides the cleanest solution for tomcat, and I don't think it
>>>>>hurts anything. We can still have as many engines as we want in the VM.
>>>>
>>>>The problem is that this doesn't follow jsr77. You should be able to
>>>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>>>we treat engine's name as domain and not allow multiple engines under
>>>>one domain we're skipping one level (j2eeserver) and problems occur.
>>>
>>>
>>>Can you have more than one J2EE server under one domain ?
>>
>>Yes - JSR77.3.2.1.
>
>
> It seems my undersanding of JSR77 was completely off...
>
> I assumed that 77.3.2 and the servers[] reffer more to a cluster-like
> setup, not to have multiple J2EE server in the same VM.
>
> And the fact that all navigation is in terms of ObjectName[] missled me
> to think that you can have any object name - this is the first I hear the
> restriction that _all_ names need to be in the same domain.
I don't know about having _all_ names in the same domain. However,
webmodules and servlets should be under the same domain as the
J2EEServer who's responsible for its deployment.
> If this is the case - the only option is to treat tomcat as a separate
> entity, in a separate domain from the webapps.
>
> We have 3 options:
> - Webapps registered once, in the jsr77Domain. Tomcat will listen for events
> and register them, but nothing else ( i.e. no contexts in the tomcat
> domain)
+1. We can keep context mbeans under tomcat domain in tomcat standalone
case - keep it the way it is?
> - webapps registered twice, once in tomcat domain and once in the JSR77
> domain. That can use either the same (local) name, or we can use the name
> in tomcat4.1 ( but what would admin use ? IMO it should be the standard
> names ).
>
> - webapps registered once, in tomcat domain - and wrappers registered in
> the jsr77Domain.
>
>
>
>>>You can register WebModules in any domain - all we need is an attribute (
>>>not even part of the name ) that tells wich engine it needs to be
>>>registered in.
>>
>>I was under impression that WebModules have to be in the same domain as
>>engine in order for everything to work. If all we need is engineName,
>>then we won't have to register them twice. :-)
>
>
> I don't see any need.
>
> The do need to know the domain of the engine - but you can configure this
> as an attribute. The only need is to construct the engine name - so it can
> invoke the addContext() callback.
>
>
>
>
>>>>I agree we should decide to use a clean way that follows the spec to
>>>>achieve this goal.
>>>
>>>
>>>+1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
>>>be able to place them in the j2eeServer domain, and if multiple engines
>>>are used each must use the same domain for webmodules ( as long as they
>>>are part of the same j2eeServer ).
>>
>>I don't see how this can be achieved if we don't allow multiple engines
>>per domain. You're saying "if multiple engines are used, each must use
>>the same domain for webmodules." But we don't allow multiple engines to
>>share the same domain as for webmodules that are placed in the
>>j2eeServer domain. Doesn't it make sense to put the engines under the
>>same j2eeDomain in order for it to work?
>
>
> There is no reason to have the webapps and the engine in the same domain. It
> may be even cleaner if they are in separate domains.
> There is no reason to even have the connector in the same domain with the
> engine.
>
> All we need is that each component is able to find the other components it
> needs. That can be done by constructing it's name using the same domain,
> but it is easy to override it.
>
> Sorry - I allways was under the impression that JSR77 doesn't require that
> all components are in the same domain, and you can just navigate from root
> to any component using the ObjectNames.
>
>
> Costin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Costin Manolache <cm...@yahoo.com>.
Amy Roh wrote:
>>>>>Personally, here's what I would like:
>>>>>- 1 engine <-> 1 domain <-> 1 service
>>>>
>>>>
>>>>That provides the cleanest solution for tomcat, and I don't think it
>>>>hurts anything. We can still have as many engines as we want in the VM.
>>>
>>>The problem is that this doesn't follow jsr77. You should be able to
>>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>>we treat engine's name as domain and not allow multiple engines under
>>>one domain we're skipping one level (j2eeserver) and problems occur.
>>
>>
>> Can you have more than one J2EE server under one domain ?
>
> Yes - JSR77.3.2.1.
It seems my undersanding of JSR77 was completely off...
I assumed that 77.3.2 and the servers[] reffer more to a cluster-like
setup, not to have multiple J2EE server in the same VM.
And the fact that all navigation is in terms of ObjectName[] missled me
to think that you can have any object name - this is the first I hear the
restriction that _all_ names need to be in the same domain.
If this is the case - the only option is to treat tomcat as a separate
entity, in a separate domain from the webapps.
We have 3 options:
- Webapps registered once, in the jsr77Domain. Tomcat will listen for events
and register them, but nothing else ( i.e. no contexts in the tomcat
domain)
- webapps registered twice, once in tomcat domain and once in the JSR77
domain. That can use either the same (local) name, or we can use the name
in tomcat4.1 ( but what would admin use ? IMO it should be the standard
names ).
- webapps registered once, in tomcat domain - and wrappers registered in
the jsr77Domain.
>> You can register WebModules in any domain - all we need is an attribute (
>> not even part of the name ) that tells wich engine it needs to be
>> registered in.
>
> I was under impression that WebModules have to be in the same domain as
> engine in order for everything to work. If all we need is engineName,
> then we won't have to register them twice. :-)
I don't see any need.
The do need to know the domain of the engine - but you can configure this
as an attribute. The only need is to construct the engine name - so it can
invoke the addContext() callback.
>>>I agree we should decide to use a clean way that follows the spec to
>>>achieve this goal.
>>
>>
>> +1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
>> be able to place them in the j2eeServer domain, and if multiple engines
>> are used each must use the same domain for webmodules ( as long as they
>> are part of the same j2eeServer ).
>
> I don't see how this can be achieved if we don't allow multiple engines
> per domain. You're saying "if multiple engines are used, each must use
> the same domain for webmodules." But we don't allow multiple engines to
> share the same domain as for webmodules that are placed in the
> j2eeServer domain. Doesn't it make sense to put the engines under the
> same j2eeDomain in order for it to work?
There is no reason to have the webapps and the engine in the same domain. It
may be even cleaner if they are in separate domains.
There is no reason to even have the connector in the same domain with the
engine.
All we need is that each component is able to find the other components it
needs. That can be done by constructing it's name using the same domain,
but it is easy to override it.
Sorry - I allways was under the impression that JSR77 doesn't require that
all components are in the same domain, and you can just navigate from root
to any component using the ObjectNames.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: TC5 JMX domain engine issue
Posted by Amy Roh <am...@sun.com>.
Costin Manolache wrote:
> Amy Roh wrote:
>
>
>>>>Personally, here's what I would like:
>>>>- 1 engine <-> 1 domain <-> 1 service
>>>
>>>
>>>That provides the cleanest solution for tomcat, and I don't think it
>>>hurts anything. We can still have as many engines as we want in the VM.
>>
>>The problem is that this doesn't follow jsr77. You should be able to
>>have more than one server(engine) under one domain (see jsr77.3.2). If
>>we treat engine's name as domain and not allow multiple engines under
>>one domain we're skipping one level (j2eeserver) and problems occur.
>
>
> Can you have more than one J2EE server under one domain ?
Yes - JSR77.3.2.1.
> Is there anything in the J2EE spec that requires a J2EE server to support
> more than one Servlet Engine ?
Not sure.
>
> Please keep in mind that tomcat itself ( the Engine, connectors, etc ) are
> _not_ constrainted by JSR77. Only the WebModule and Servlet are defined in
> 77.
Right.
>>>>- An option to configure in which domain the JSR 77 beans go (the other
>>>>parts of the appserver must have their stuff in the same domain I assume)
>>>
>>>
>>>I'm leaning toward this option as well. I agree with Amy, registering
>>>them in both tomcat and j2ee domain is hacky.
>>
>>Yeah, I don't think this is a good elegant long term solution. We don't
>>want to have two mbeans registered in two different domains. When a
>>user browses through WebModule & Servlet jsr77 mbeans, you'll see two
>>registered in j2eedomain and tomcat each. Hacky.
>
>
> There is no need to register them twice. The mapper receives notifications
> for all domains.
Cool!
> You can register WebModules in any domain - all we need is an attribute (
> not even part of the name ) that tells wich engine it needs to be
> registered in.
I was under impression that WebModules have to be in the same domain as
engine in order for everything to work. If all we need is engineName,
then we won't have to register them twice. :-)
>
>>>Multiple Engines are not a bad thing, quite the contrary. But
>>>they should be used in a clean way. JMX domains are a good way to
>>>organize the info.
>>
>>I agree we should decide to use a clean way that follows the spec to
>>achieve this goal.
>
>
> +1 - if tomcat is to support JSR77 ( for contexts/servlets ), it needs to
> be able to place them in the j2eeServer domain, and if multiple engines are
> used each must use the same domain for webmodules ( as long as they are
> part of the same j2eeServer ).
I don't see how this can be achieved if we don't allow multiple engines
per domain. You're saying "if multiple engines are used, each must use
the same domain for webmodules." But we don't allow multiple engines to
share the same domain as for webmodules that are placed in the
j2eeServer domain. Doesn't it make sense to put the engines under the
same j2eeDomain in order for it to work?
> That doesn't impose any restrictions on the domain for tomcat.
>
> We could as well use one domain for the Engine, Mapper and all
> servlet-implementation components, and a separate domain for the connector.
> ( for a use case of having one connector used for multiple engines for
> example.
>
> Placing too many components in the same domain results in a mess. It may be
> much better to not place non-JSR77 components ( like Engine or Connector )
> in the jsr77 domain.
>
> The only issue is that the components registered in jsr77 for WebModule
> should be either StandardContext or a proxy/wrapper that exposes the info
> and operations in StandardContext. Maybe with some changes ( for Statistics
> for example ).
>
>
> Costin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org