geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <jer...@coredevelopers.net>
Subject RE: [PATCH] JSR77 - 4 managed objects
Date Fri, 15 Aug 2003 04:37:48 GMT
gianny DAMOUR wrote:
> Hello,
>
>
> Sean wrotes:
> [...]
> >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 agree. Did you have a look to the thread "[JSR77] kernel and model glue
> strategy"? I try to explain how JSR77 could be plugged into the current
> kernel without impacting the type hierarchy.
>

I did, and I have to admit I have some baggage here which makes me nervous
about a 'glued' design like this. The JSR77 model defines a structure for
managed objects that the server needs to expose. However, to be truly
managable, the server is going to expose many more attributes and operations
than just those defined by JSR77.

I have this concern that a strict, inheritance based hierarchy will not be
able to handle the different implementations of managed objects, and hence
we end up exposing two hierarchies (the strict JSR77 one and the actual
Geronimo one) which leads to a synchronisation nightmare.

> > > 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.
> I do not understand exactly your point here. However, I hope to submit a
> show case of the proposed strategy very soon.
>

I think that it is important that the JSR77 model synchronise itself with
the running kernel rather than relying on the kernel to keep the model in
sync. So methods like addServer() worry me as they are relying on the kernel
to reliably call them; the alternative would be for getServers() to fetch
the current state from the kernel each time. It is much easier to diagnose a
simple poll than trying to work out which event was missed.

I hope that makes sense - I look forward to seeing your show case.

Cheers
Jeremy


Mime
View raw message