geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: ObjectName, j2eeType, and GBeans
Date Sun, 24 Jul 2005 23:14:50 GMT
I would suggest adding a property for the primary interface that the 
component provides e.g.

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.


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

View raw message