geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Hamblett <shambl...@charter.net>
Subject Re: [PATCH] JSR77 - 4 managed objects
Date Fri, 15 Aug 2003 03:43:17 GMT
On Thursday 14 August 2003 11:27 pm, Jeremy Boynes wrote:

Ok, 
	On that note, I should get involved in this discussion to determine if I 
should continue to work on the J2EEDeployedModule, J2EEApplication, 
J2EEModule.  I think the path is correct for based on what I have read of 
JSR77, but I can't see the correlation between what is implemented for the 
kernel/container/'the real worker' and the model described in JSR77.  It is 
my understanding that the J2EEManagedObjectModel is required in order to 
implement this JSR, but are they supposed to be implemented as abstract 
classes, interfaces, or classes.  I think if this is implemented as classes, 
it could be a foundation for a reference implementation of a J2EE Server.  I 
don't think that is what we are shooting for, but it's late and I could be 
wrong about that too.  If we need to redirect our efforts to get better 
organized, then I am in.

Sean


> "This chapter contains the models and metamodels that specify the format,
> semantics and relationship of the managed objects required by all compliant
> implementations of this specification." [JSR77 pp 19]
>
> By making these (final) concrete classes, you are dictating the
> implementation. However, the specification is deliberately vague here to
> allow for different vendor implementations of this model. Even within
> Geronimo, there could be different implementations - for example, different
> WebModules from Jetty and Tomcat, different JMSResources from OpenJMS vs
> Geronimo's.
>
> You have also defined the implementation of the relationships between the
> managed objects - for example, the implementation of
> J2EEDomainImpl.getServers(). This requires the kernel to ensure that all
> relationships are accurately reflected in these objects rather than having
> the implementation here determine that from the true component
> relationship.
>
> Don't get me wrong, I appreciate your contribution here but I think it
> would be better to define the interfaces across the board.
>
> Thanks
> Jeremy
>
> > >These should be interface definitions rather than concrete
> >
> > classes - there
> >
> > >could be a variety of classes implementing them.
> >
> > I diagree with this one. It is nice to provide an interface but not
> > required. However, I have refactored the proposed patch.
> >
> > >Secondly, there should not need to be any references to
> >
> > javax.management in
> >
> > >them - the intention is that this model can be used by non-Java
> >
> > clients and
> >
> > >so all the attributes should be simple types; for example, the
> >
> > spec defines
> >
> > >the OBJECT_NAME type to be a string.


Mime
View raw message