Jeremy Boynes wrote:
JNDIEnvironmentRefs was added to allow ComponentContextBuilder to work
with different POJOs representing unrelated objects (EJBs and AppClients
for sure, possibly Servlet's and Filters if needed). It works for either
proposal.

It is supertype defined schemas, so it should be there regardless I think.

This is a view used during container configuration and is not really
part of the data model. The issue I had with your initial proposal was
that it made the entire spec model abstract which meant that it could
not me used to implement the DDBeans Aaron needs for the deployment
tool.

Why not? The DDBeans would have used the abstract model and not known that there was a geronimo implementation behind it.

As it is, the DDBeans or standard schema will not be able to be used to
generate something  that is directly usable by geronimo code.

We can't even pass in a geronimo tree to be manipulated by code written
against the standard tree - any sets it does will fail due to the wrong
type of element.

But we can build a geronimo tree and pass it into code that does read-only
from a standard tree.  Hopefully that will be our only cross tree use-case?

I might be wrong, but I can't for now think of another view that is
common across several components - maybe JNDIBindable, but if all it is
is the JNDI name then I'm not convinced a separate interface is needed
(this can just be handled by the respective container).

The whole point of OO design is to handle things you have not thought of yet.

But enough sour grapes from me:-)  I was not able to convince people
of my ideas, so lets move on with what we have.  I think it is a little
better for all this discussion.

cheers






Reply via email to