geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: ObjectName, j2eeType, and GBeans
Date Mon, 25 Jul 2005 13:37:58 GMT
On Mon, 25 Jul 2005, David Jencks wrote:
> 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.

	Well, the GBean factory does have a special constructor field for 
"j2eeType".  It's not what I'd call a runtime dependency, but it's hard to 
argue that that's useful for non-J2EE configurations of Geronimo.

> 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.

	For one thing, JSR-77 says:

"In addition to the standard specified managed object types, J2EE Product
Providers may include vendor-specific managed object types in the
management system implementation. Vendor-specific managed object type
models must extend the J2EEManagedObject type and support the attributes
required by the J2EEManagedObject model."

	And none of our "extensions to the model" implement
J2EEManagedObject.  We can consider whether we think they should, but it
doesn't always clearly make sense.  For example, the logging service and
config store are visible via JSR-77, but they'd also be used in non-J2EE
applications, and it would seem a little weird for them to be tied to
J2EEManagedObject.  It's not a huge deal since J2EEManagedObject is not
terribly heavyweight, but it is either a violation of the spec (as now) or
an unexpected dependency (if we move them all to J2EEManagedObject).

> 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.

	Which is of course why we're soliciting feedback on the list here, 
to try to apply some careful thought to the issue.  I'm fine charging 
ahead with more j2eeTypes for now, I just don't feel so good about it and 
want to start thinking about alternatives.

> 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.

	If we do go with the strategy of the kernel indexing GBeans by the 
interfaces they expose in their GBeanInfo, then there is no "primary" -- 
each one exposes exactly as many as it exposes.  I guess that's another 
advantage of the indexing interfaces over adding to object name, even if 
it may be a marginally more intrusive change.

Aaron

> 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