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
