geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: ObjectName, j2eeType, and GBeans
Date Mon, 25 Jul 2005 06:45:26 GMT

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