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
