geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: ObjectName, j2eeType, and GBeans
Date Mon, 25 Jul 2005 07:03:45 GMT
I'd like to make it clear that my objections are not to fixing the 
naming system currently used, which I think has some problems other 
than those noted here, but to changing it without careful thought, and 
destabilizing geronimo during the change.

The idea of putting the "primary interface" in the name assumes that 
there is only one primary interface.  This is not the case for some 
gbeans, notably the connection tracker: it exposes one interface to the 
connection managers and another interface to the transaction manager.  
Neither one is "primary".  I'm against putting interface names into 
object names until a satisfactory solution for this kind of problem is 
agreed on.

thanks
david jencks

On Jul 24, 2005, at 11:45 PM, David Jencks wrote:

>
> On Jul 24, 2005, at 4:14 PM, Jeremy Boynes wrote:
>
>> I would suggest adding a property for the primary interface that the 
>> component provides e.g.
>>   service=org.apache.geronomo.module.SomeService
>>
>> This would provide an easy way to identify what was offering a 
>> service.
>>
>> I'd go further and say you should stop abusing the JSR77 namespace 
>> leaving it just for objects that the specification defines. It would 
>> also take the "j2eeType" J2EE concept out of the non-J2EE container 
>> and allow you to remove the runtime dependency of the kernel on the 
>> j2ee module.
>
> Why do you think there is a runtime dependency of the kernel on the 
> j2ee module?  The type string included in GBeanInfo is used only at 
> deploy time to help resolve gbean references.
>
> Since the jsr77 spec indicates that objects other than those required 
> may be exposed by jsr77, I'm not sure why you consider adding more 
> objects to be abuse.
>
> I'd rather we didn't jump into big changes here.  In my experience 
> changing the naming system involves changes in just about every 
> builder module.  I think this is something we could consider for 2006. 
>  I am definitely -1 on any change to the basis of the naming system 
> before 1.0 is released.  If you want to experiment please use a 
> branch.
>
> thanks
> david jencks
>
>>
>> --
>> Jeremy
>>
>> Aaron Mulder wrote:
>>> 	So as I'm working on this management interface, I'd like a way to 
>>> identify "all the things that implement X".  Such as, for logging, 
>>> the log configuration GBean, or for web containers, the web 
>>> container GBean.  In other areas, the way we've done this is to 
>>> operate off the j2eeType -- so if you're looking for a security 
>>> realm, you look for a j2eeType of NameFactory.SECURITY_REALM, and so 
>>> on.  This only really works if the GBean declares a j2eeType in its 
>>> GBeanInfoBuilder, os otherwise it generally ends up with the generic 
>>> j2eeType of "GBean", and I don't want to rely in a specific 
>>> component name.
>>> 	So, to get to my point, does anyone object to expanding the use of 
>>> j2eeType outside of proper JSR-77 types?  We've already done it for 
>>> security realms (asa I alluded to above) and others, just want to 
>>> make sure no one feels that's a bad policy.
>>> 	An alternative might be for the kernel to remember which GBeans
>>> implement which interfaces, and then I could search by interface.  
>>> Or that
>>> could be done outside the kernel by indexing all GBeans and adding a 
>>> GBean
>>> load/unload listener, though that seems a little weird for what 
>>> would be a
>>> pretty core GBean identification feature.  These alternatives could 
>>> have
>>> the advantage that we're not abusing the "j2eeType" property with 
>>> values
>>> outside those explicitly listed in the JSR-77 spec, particularly for
>>> objects that don't implement J2EEManagedObject.
>>> Thanks,
>>> 	Aaron
>>
>


Mime
View raw message