Lets finish conversion to GeronimoMBean, or, no more code rot.

[David Jencks]

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