geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Signatrue change of GBeanRegistry.listGBeans [Re: svn commit: r154941]
Date Wed, 23 Feb 2005 18:33:36 GMT
On Feb 23, 2005, at 8:45 AM, Jeremy Boynes wrote:

> Dain Sundstrom wrote:
>> On Feb 22, 2005, at 7:23 PM, jboynes@apache.org wrote:
>>>
>>>      public Set listGBeans(ObjectName pattern) {
>>> -        return gbeanRegistry.listGBeans(pattern);
>>> +        String domain = (pattern == null || 
>>> pattern.isDomainPattern()) ? null : pattern.getDomain();
>>> +        Map props = pattern == null ? null : 
>>> pattern.getKeyPropertyList();
>>> +        Set gbeans = gbeanRegistry.listGBeans(domain, props);
>>> +        Set result = new HashSet(gbeans.size());
>>> +        for (Iterator i = gbeans.iterator(); i.hasNext();) {
>>> +            GBeanInstance instance = (GBeanInstance) i.next();
>>> +            result.add(instance.getObjectNameObject());
>>> +        }
>>> +        return result;
>>>      }
>> On just a cursory review of this commit, it appears that you have 
>> changed the way object name queries work.  Before making any other 
>> changes to this code, can you please explain the changes you want to 
>> make, so we can discuss the impact?  I am very nervous about any 
>> changes to this code.
>
> Perhaps on more detailed examination you'll realize that the only 
> thing changed is that we no longer support partially wildcarded domain 
> patterns, something that we never used and was pretty pointless.

So you have removed the feature supporting domain wild cards.  I know 
we currently don't use them, but don't see any reason to remove them 
either.  Also I belive that you have changed the meaning of an empty 
domain name.  In JMX it means match the default domain only, which is 
something I want to begin using in our plans and matching code.

> Also, given we're changing the API anyway, there is the opportunity 
> here to remove the stupid overloading of names and patterns and have a 
> much clearer query API.

I don't agree on spliting names and patterns.  There is a natural 
connection between patterns and specific names.  In the reference code, 
it is nice to say, I want a reference to this exact object using a non 
pattern object name.  The interchangeability between specific and 
pattern names is very convenient and I don't see any reason to remove 
the feature.

> We have talked about the changes here extensively and all agreed on 
> the direction. Continue to be nervous, but please don't raise 
> roadblocks without due consideration.

I don't remember discussing discussing removing domain queries, or 
splitting object names and patters.  Maybe you can refresh my memeory.

Anyway, here is my formal -1 roadblock.

-dain


Mime
View raw message