Re: MORE QUESTIONS: copy of JMI extents

Hi Holger,

Holger Krug wrote:
> Some StructRef related questions emerging from my work on a JMI copy
> operation:
> 
> When I copy from one RefPackage A to another RefPackage B both, A and B
> may be from different repositories or even from different JMI
> implementations.
> 
> My problem is the creation of RefStruct's in B being copies of
> RefStruct's in A. My questions are more related to understanding the
> specs than being really an implementation problem, which actually is
> solved.
> 
> Currently I assume, that I must find a proxy in or "near by" B to
> create the RefStruct value. But the JMI/MOF specs do not say anything
> about this, do they ? So probably I could just take the RefStruct as
> provided by A and use it in B, provided that it does not contain any
> unresolved references to instance objects.

Yes, you can do that.

> If the RefStruct from A does contain references to instance objects,
> I'm even in the best case forced to recreate the RefStruct to use it
> in B, because I must exchange A's instances with B's instances. But I
> wonder if I probably could use a proxy from A to create the new
> RefStruct ?

This may be a problem, because the factory method could consider the B's 
instances as not being of the correct type for some JMI implementations 
I guess. Anyway, for MDR it would work fine.

> Is anything said in the specs about the compatibility of RefStruct's
> across JMI repositories and implementations ? For values of
> CollectionType, it's clear: they are arbitrary Java collections, hence
> compatible. The same probably is true for values of PrimitiveType and
> EnumerationType. Therefore I think values of StructureType should be
> compatible similarly. But if so, I cannot understand why the specs
> provide specific factory methods in the model, which in some cases may
> be hidden anywhere in the vastnesses of my repository, very hard to
> find.

Yes, structure types as any other datatypes are JMI implementation 
independent and there were long discussions about mapping them to 
classes instead of interfaces in JMI. However since this seemed to be a 
problem for some of the EG members, we kept it as interfaces and thus we 
had to provide factory methods for the implementation of those interfaces.

> 1) Can I reuse StructRef's created in one JMI repository/implementation
>    in another one ?

For structures that have non-object typed fields definitely yes.
For structures with object typed fields it can be risky as the factory 
method can check the equality of metaobjects of the passed value with 
the type of the field in the metamodel which (if A and B are in 
different repositories) may result in TypeMismatchException.
Although the structures are just "stupid" values, AFAIK the typechecking 
for their fields is not formaly defined in the spec. thus can be 
implemented using RefObject.refIsInstanceOf which would return false for 
objects from a different repository (if they are instances of different 
copies of the same metamodel).
But if you suppose that A.refMetaObject().equals(B.refMetaObject()) - 
i.e. both A and B are instances of the same copy of some metamodel (not 
instances of two copies of the same metamodel), then you can be sure 
that the factory methods in A will work for B.

> 2) Is there any clarification concerning this point in the JMI/MOF specs ?
>    If not, shouldn't it be added ?

I am not sure. I need to look at the spec...

> 3) Was is really a good design decision, to put the factory methods for
>    StructRef's into the proxies ? At least if StructRef's are deemed to
>    be compatibel across JMI repositories/implementations I cannot understand
>    quite well, why it was made so ugly difficult to create them. What would
>    be the alternatives ?

That's my question - what would you suggest to make it better?

Martin