Re: PROPOSAL (round 4): Extensions to MDR XMI API

Martin Matula wrote:
> Hi Brian,
> 
> Brian Smith wrote:
> 
>> 0. Could you explain what the intended threading model is? I.e. when 
>> can multiple threads simultaneously operate on a shared 
>> XMIReader/XMIWriter/XMIProducer/XMIReferenceResolver/etc.
> 
> The XMIReader/Writer/ReferenceProvider should be thread safe. As I wrote 
> to the Javadoc, reader should lock XMIReferenceResolver for the whole 
> reading, which ensures that other threads will not interfere with the 
> state of XMIReferenceResolver.

Okay, so another way of stating this is that there can be at most one 
thread per XMIReferenceResolver? That means there can be at most one 
thread per XMIReader, since an XMIReader can only reference a single 
XMIReferenceResolver at a time. So, basically XMIReader has a serialized 
(i.e. non-concurrent) execution model. That seems very reasonable, 
especially since MDR currently only allows one read-write transaction 
per repository anyway.

Would XMIWriter have a similar serialized execution model? It seems 
possible that XMIReferenceProvider could be implemented in a stateless 
fashion. But, it also seems that it would be reasonable for the 
reference provider to maintain some state since it has to ensure that 
all the xmi.ids are unique within the resultant document. But if it 
needs to be allowed to maintain state then it seems (a) there needs to 
be a way to reset that state, and (b) XMIWriter and XMIReferenceProvider 
must have a serialized execution model.

Also, do you want to specify that implementations of this API _must_ be 
thread-safe, or just that they _should_ (_could_?) be thread-safe?

> 
>> 1. Do you think that XMIOutputConfig/XMIInputConfig need to be 
>> abstract? I am thinking that they are just a statically-typed variant 
>> of Properties/Map.

> But for the convenience of users I can make the configuration class 
> non-abstract (so that users can create instance of it), althogh I 
> thought that they will rather work like this:
> XMIReader reader = XMIReaderFactory.createXMIReader();
> reader.getConfiguration().set...();

Okay, your example makes sense. I had in my mind that I would create an 
XMIInputConfig, set its properties, and then create the reader. I was 
actually hoping that I could create one XMIInputConfig and one 
XMIOutputConfig, set their properties, and then set them to be the 
default via Lookup. Then I could call XMIOutputConfig.getDefault() to 
get my pre-configured output config. This would mean that presumably I 
could just use XMLWriterFactory.getDefault().createXMLWriter() and the 
resultant writer would be configured with my custom settings (assuming 
that the parameter-less createXMLWriter() is specified as 
createXmlWriter(XMLOutputConfig.getDefault())). But, it is not obvious 
to me whether or not it is even possible to set the default lookup 
instance for a class using NetBeans lookup. Is it possible? Or, would 
there have to be some kind of static void 
XMIOutputConfig.setDefault(XMIOutputConfig) method for that to be possible?

> No. There is a way to reset the state. As stated in JavaDoc, 
> XMIReferenceResolver resets to its fresh state before it exists from the 
> outermost call of the resolve method. So according to JavaDoc it should 
> work in the following way:
> 1) reader starts reading the document
> 2) reader is about to register the first object
> 3) reader synchronizes on XMIReferenceResolver
> 4) reader registers the first deserialized object
> 5) reader registers other objects
> 6) reader finished reading, but some references are still unresolved
> 7) reader calls resolve method on XMIReferenceResolver
> 8) ref. res. starts to read other documents by creating readers reading 
> the referenced documents
> 9) steps 1-7 are repeated for nested readers - during the reading more 
> nesting of resolve calls may be needed, at the end, all the references 
> are resolved
> 10) XMIReferenceResolver resets to its fresh state
> 11) ref. resolver returns from resolve method entered at step 7
> 12) reader frees the lock on XMIReferenceResolver

Thanks, this is an excellent explanation. I had missed the added note 
about resetting state, sorry.

>> 5. Do you think it would be a good idea to have XMIReferenceProvider 
>> be able to (optionally) provide xmi.uuid values too?
> 
> 
> Sounds interesting. I guess I will add a note that xmiId can be set to 
> null, which means that it should be automatically generated by writer. 
> Then we can add uuid (now or later) and also allow null which would mean 
> that it will not be included in the document.

I don't know if getXmiId should be allowed to return null to get the 
writer to generate it automatically. That means the XMIWriter would be 
more complicated by the xmi.id generation logic. Also, it seems it would 
be difficult for XMIWriter to guarentee that it would generate xmi.ids 
that were unique with respect to all future and current xmi.ids 
generated for the document by the reference provider.

> OK, I am just tired of writing too many javadoc for each new round of 
> this proposal and then rewrite it at the next round. I will wait till 
> the API is finalized.

Sorry. At least, things seem to be winding down.

- Brian