Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Sun, 28 Dec 2003 12:50:41 -0800
Subject: Re: Lets finish conversion to GeronimoMBean, or, no more code rot.
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
From: David Jencks <david@coredevelopers.net>
To: geronimo-dev@incubator.apache.org
Content-Transfer-Encoding: 7bit
In-Reply-To: <38850552-3769-11D8-8F72-003065F4889C@coredevelopers.net>
Message-Id: <7F81D95A-3977-11D8-8F72-003065F4889C@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
>