You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@coredevelopers.net> on 2003/12/26 07:03:26 UTC
Lets finish conversion to GeronimoMBean, or, no more code rot.
There are still at least two generations of component code in current
geronimo cvs: the original(?) version requiring fairly explicit
container/containee management and the much simpler and more automated
GeronimoMBean version. I would like to get this cleaned up in the next
few days. If the original authors (or someone else) wants to do this,
please speak up, otherwise I will start on it soon.
I think it would be better if more people than Dain and I become
familiar with the GeronimoMBean code, so I encourage others to work on
this.
The areas I am particularly aware of are:
Security framework. I see that some of the container/containee
management is based on the class of the containee. This could be
converted to rely on object name patterns to fit in the current
GeronimoMBean structure or perhaps the GeronimoMBean could be extended
to deal with endpoints filtered by class rather than object name. In
the absence of better understanding I'd move to object name patterns.
Also, I believe that the thread-based mbean server lookup in
GeronimoLoginConfiguration is misguided and unnecessary. I think we
can assume that there will be only one mbean server per vm used for
geronimo management. Other mbean servers in a vm might be used for
other purposes, but I see no need for more than one "Geronimo" mbean
server per vm. If anyone disagrees, please supply a convincing use
case. Alan, sorry I didn't speak up about this when you originally
asked.
Web framework. Along with converting to use GeronimoMBeans, the
functionality of the web deployer should be separated from the web
container to match the architecture of the other deployer/container
frameworks.
There may be other places needing similar work, these are the ones I
have encountered recently.
Thanks
david jencks
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by Greg Wilkins <gr...@mortbay.com>.
Jeremy Boynes wrote:
>
> Is it enough just to have deployer specific vendor DDs e.g.
> geronimo-jetty.xml and geronimo-tomcat.xml? This would seem like an easy
> way to separate them out - if you have both DDs and both deployers then
> the container arbitrarily chooses one.
Nope - firstly it is our intent that 99% of deployments will not
need any geronimo-jetty.xml or geronimo-tomcat.xml files. The configuration
should be the same for both and the user should not know which implementation
is being used.
Also, the more common usage of this will not be to run a tomcat and a jetty.
The use-case to think about is and administration interface. If you want an
admin webapp to only be available on a particular interface, then you
would create a webcontainer, give it a connector for that particular interface
and then deploy the admin webapp to that container.
So more often than not the selection of webcontainer will be by name rather
than type.
I guess the solution is to have in the geronimo-web.xml and optional
element to specify the ObjectName of the target container. However
as we need to do similar things for webConnectors and weblogs and session
managers etc. etc. then it would be good to have a generic geronimo mechanism
that would allow an entity being deployed to provide input into selecting
between multiple possible containers.
So I agree that it is good to have split out the deployer from the container,
but I still would like to see a general solution to this use-case.
I'll have a look at davids checks-ins and see if I have any more concrete
suggestions.
cheers
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by Jeremy Boynes <je...@coredevelopers.net>.
Greg Wilkins wrote:
>
> below...
>
> Jan Bartel wrote:
>
>> Sorry for the late and rushed reply, but briefly:
>>
>> David Jencks wrote:
>> <snip>
>>
>>> Web framework. Along with converting to use GeronimoMBeans, the
>>> functionality of the web deployer should be separated from the web
>>> container to match the architecture of the other deployer/container
>>> frameworks.
>>
>>
>>
>> I will look into the GeronimoMBean for the web layer, however I am not
>> convinced of the separation of the deployer from the web container. It
>> suits the web layer that the container is the deployer because:
>>
>> 1. we want to be able to run multiple Jettys
>> 2. we want to be able to run multiple Tomcats AND multiple Jettys (AND
>> whatever else web container flavours).
>>
>> Refactoring out the deployer functionality from the web container just
>> introduces problems of the deployer working out which instance of a
>> web container to deploy to.
>>
Isn't it going to have to anyway? For example, if your runtime contains
two Jetty's and a Tomcat then you will need to identify the target
during deployment.
<snip/>
> Thus I think we need to solve the relationship between deployer and
> container based on more than just type for all deployers.
>
By separating deployment from runtime we achieve this.
For example, when you deploy a WAR you would say that you wanted to use
the Jetty deployer. That will result, probably, in Jetty specific GBeans
being constructed.
During the same deployment session, you could also choose to deploy
another WAR using the Tomcat deployer. This is going to generate Tomcat
specific GBeans.
There is nothing to stop you doing that (well maybe common sense) and
you will end up with a configuration that requires both Jetty and Tomcat
to be present.
> Currently Jan and I have done this by making the WebContainer a deployer,
> so that if multiple webcontainers are present, each will be offerred a
> WAR, connector, sessionmanager etc. and can decide if it will deploy it.
>
I don't think this is a good separation of concerns - the work done
during deployment seems to me to be completely different from what needs
to be done by the container at runtime.
> If we are to separate the deployer from container, then we will need
> to add a way to specify a sub-type or specific instance of a container
> to the gDD. It would be best if this was done generically and not just
> for the web containers.
>
Is it enough just to have deployer specific vendor DDs e.g.
geronimo-jetty.xml and geronimo-tomcat.xml? This would seem like an easy
way to separate them out - if you have both DDs and both deployers then
the container arbitrarily chooses one.
--
Jeremy
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by Greg Wilkins <gr...@mortbay.com>.
below...
Jan Bartel wrote:
> Sorry for the late and rushed reply, but briefly:
>
> David Jencks wrote:
> <snip>
>
>> Web framework. Along with converting to use GeronimoMBeans, the
>> functionality of the web deployer should be separated from the web
>> container to match the architecture of the other deployer/container
>> frameworks.
>
>
> I will look into the GeronimoMBean for the web layer, however I am not
> convinced of the separation of the deployer from the web container. It
> suits the web layer that the container is the deployer because:
>
> 1. we want to be able to run multiple Jettys
> 2. we want to be able to run multiple Tomcats AND multiple Jettys (AND
> whatever else web container flavours).
>
> Refactoring out the deployer functionality from the web container just
> introduces problems of the deployer working out which instance of a web
> container to deploy to.
>
> For the other containers, eg ejb container, the deployer can be factored
> out because there is (AFAIK) a 1:1 relationship between deployer and
> container.
There has been some discussion of eventually supporting multiple EJB
containers. It may be that in the future we may have a JOnAS based
container deployed at the same time as an OpenEJB one. EARs could
have something in the gDD to specify:
+ any EJB container.
+ a specific type of EJB container.
+ a specific instance of an EJB container.
This is similar to what Jan has been working towards with the
webcontainer where a WAR, connector, session manager, etc. will be able
to specify in it's gDD:
+ any web container.
+ a specific type of web container.
+ a specific intance of a web container.
Thus I think we need to solve the relationship between deployer and
container based on more than just type for all deployers.
Currently Jan and I have done this by making the WebContainer a deployer,
so that if multiple webcontainers are present, each will be offerred a
WAR, connector, sessionmanager etc. and can decide if it will deploy it.
If we are to separate the deployer from container, then we will need
to add a way to specify a sub-type or specific instance of a container
to the gDD. It would be best if this was done generically and not just
for the web containers.
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by David Jencks <da...@coredevelopers.net>.
On Tuesday, January 6, 2004, at 01:22 PM, Jan Bartel wrote:
> Sorry for the late and rushed reply, but briefly:
>
> David Jencks wrote:
> <snip>
>> Web framework. Along with converting to use GeronimoMBeans, the
>> functionality of the web deployer should be separated from the web
>> container to match the architecture of the other deployer/container
>> frameworks.
>
> I will look into the GeronimoMBean for the web layer, however I am not
> convinced of the separation of the deployer from the web container. It
> suits the web layer that the container is the deployer because:
>
> 1. we want to be able to run multiple Jettys
> 2. we want to be able to run multiple Tomcats AND multiple Jettys (AND
> whatever else web container flavours).
>
> Refactoring out the deployer functionality from the web container just
> introduces problems of the deployer working out which instance of a
> web container to deploy to.
>
> For the other containers, eg ejb container, the deployer can be
> factored out because there is (AFAIK) a 1:1 relationship between
> deployer and container.
Well, IMNSHO, separating the deployment planner from the web container
resulted in a much clearer design. You can set the target web
container, essentially, as an attribute of the deployment planner.
Also, IIUC, Jeremy's redesign of deployment will often result in the
deployment planner running on a different machine from the web
container, which would cause problems if they were one component.
david jencks
>
> Jan
>
>
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by Jan Bartel <ja...@coredevelopers.net>.
Sorry for the late and rushed reply, but briefly:
David Jencks wrote:
<snip>
> Web framework. Along with converting to use GeronimoMBeans, the
> functionality of the web deployer should be separated from the web
> container to match the architecture of the other deployer/container
> frameworks.
I will look into the GeronimoMBean for the web layer, however I am not
convinced of the separation of the deployer from the web container. It
suits the web layer that the container is the deployer because:
1. we want to be able to run multiple Jettys
2. we want to be able to run multiple Tomcats AND multiple Jettys (AND
whatever else web container flavours).
Refactoring out the deployer functionality from the web container just
introduces problems of the deployer working out which instance of a web
container to deploy to.
For the other containers, eg ejb container, the deployer can be factored
out because there is (AFAIK) a 1:1 relationship between deployer and
container.
Jan
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by David Jencks <da...@coredevelopers.net>.
I've converted the web, remoting, and clustering modules to geronimo
mbeans, as well as a few miscellaneous mbeans. These appear to be the
last uses of the original dependency management framework so I removed
AbstractManagedObject, AbstractManagedContainer, and
AbstractManagedComponent.
The original dependency service is still referred to by the
StandardMBean deployment task. IMNSHO this can best be removed by
deploying StandardMBeans as geronimo mbeans. This requires:
-writing something like GeronimoMBeanInfo.addOperationsDeclaredIn to
look at all interfaces in the xxxMBean inheritance chain and also use
naming conventions to identify attributes
-interpreting the dependency management stuff for plain mbeans as
geronimo mbean endpoints. Since this last feature is not currently
used AFAIK, the syntax is presumably not fixed in stone.
As a side note, it would be a very nice feature to be able to override
the endpoint object name pattern supplied in GeronimoMBeanInfo in the
*-service.xml file instance deployment descriptor.
I've also added a feature to geronimo mbean endpoints. You now have a
choice for collection valued endpoints. You can use the original
system where you supply a collection valued attribute that is set once
and modified behind the scenes without notifications, or you can supply
a GeronimoMBeanEndpointListener object that is notified when an
endpoint is added or removed from the collection. I also fixed a
serious bug in the endpoint management in which GeronimoMBeans were
being added before they were initialized or useable, let alone started.
Let me know if this has caused problems.
thanks
david jencks
On Sunday, December 28, 2003, at 12:50 PM, David Jencks wrote:
> I've converted the security module to GeronimoMBeans.
>
> I've changed the deployment pattern for EJBModuleConfiguration and
> WebModuleConfiguration so that the ejb and web deployment planners are
> expected to deploy these mbeans in a configured state. Previously it
> was possible for unconfigured ModuleConfigurations to be generated by
> lookups on SecuriityService.
>
> If this change is inconsistent with the JACC spec, please let me know.
>
> thanks
> david jencks
>
> On Thursday, December 25, 2003, at 10:03 PM, David Jencks wrote:
>
>> There are still at least two generations of component code in current
>> geronimo cvs: the original(?) version requiring fairly explicit
>> container/containee management and the much simpler and more
>> automated GeronimoMBean version. I would like to get this cleaned up
>> in the next few days. If the original authors (or someone else)
>> wants to do this, please speak up, otherwise I will start on it soon.
>>
>> I think it would be better if more people than Dain and I become
>> familiar with the GeronimoMBean code, so I encourage others to work
>> on this.
>>
>> The areas I am particularly aware of are:
>>
>> Security framework. I see that some of the container/containee
>> management is based on the class of the containee. This could be
>> converted to rely on object name patterns to fit in the current
>> GeronimoMBean structure or perhaps the GeronimoMBean could be
>> extended to deal with endpoints filtered by class rather than object
>> name. In the absence of better understanding I'd move to object name
>> patterns. Also, I believe that the thread-based mbean server lookup
>> in GeronimoLoginConfiguration is misguided and unnecessary. I think
>> we can assume that there will be only one mbean server per vm used
>> for geronimo management. Other mbean servers in a vm might be used
>> for other purposes, but I see no need for more than one "Geronimo"
>> mbean server per vm. If anyone disagrees, please supply a convincing
>> use case. Alan, sorry I didn't speak up about this when you
>> originally asked.
>>
>> Web framework. Along with converting to use GeronimoMBeans, the
>> functionality of the web deployer should be separated from the web
>> container to match the architecture of the other deployer/container
>> frameworks.
>>
>> There may be other places needing similar work, these are the ones I
>> have encountered recently.
>>
>> Thanks
>>
>> david jencks
>>
>
Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Posted by David Jencks <da...@coredevelopers.net>.
I've converted the security module to GeronimoMBeans.
I've changed the deployment pattern for EJBModuleConfiguration and
WebModuleConfiguration so that the ejb and web deployment planners are
expected to deploy these mbeans in a configured state. Previously it
was possible for unconfigured ModuleConfigurations to be generated by
lookups on SecuriityService.
If this change is inconsistent with the JACC spec, please let me know.
thanks
david jencks
On Thursday, December 25, 2003, at 10:03 PM, David Jencks wrote:
> There are still at least two generations of component code in current
> geronimo cvs: the original(?) version requiring fairly explicit
> container/containee management and the much simpler and more automated
> GeronimoMBean version. I would like to get this cleaned up in the
> next few days. If the original authors (or someone else) wants to do
> this, please speak up, otherwise I will start on it soon.
>
> I think it would be better if more people than Dain and I become
> familiar with the GeronimoMBean code, so I encourage others to work on
> this.
>
> The areas I am particularly aware of are:
>
> Security framework. I see that some of the container/containee
> management is based on the class of the containee. This could be
> converted to rely on object name patterns to fit in the current
> GeronimoMBean structure or perhaps the GeronimoMBean could be extended
> to deal with endpoints filtered by class rather than object name. In
> the absence of better understanding I'd move to object name patterns.
> Also, I believe that the thread-based mbean server lookup in
> GeronimoLoginConfiguration is misguided and unnecessary. I think we
> can assume that there will be only one mbean server per vm used for
> geronimo management. Other mbean servers in a vm might be used for
> other purposes, but I see no need for more than one "Geronimo" mbean
> server per vm. If anyone disagrees, please supply a convincing use
> case. Alan, sorry I didn't speak up about this when you originally
> asked.
>
> Web framework. Along with converting to use GeronimoMBeans, the
> functionality of the web deployer should be separated from the web
> container to match the architecture of the other deployer/container
> frameworks.
>
> There may be other places needing similar work, these are the ones I
> have encountered recently.
>
> Thanks
>
> david jencks
>