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

Hi Brian,

Brian Smith wrote:
>> 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.

Yes.

> 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.

No, I don't want this to be the case. XMIReferenceProvider should be 
more like a global service for providing XMI.IDs and document URIs not 
depending on who writes them to the XMI. The XMI.IDs returned from 
reference provider should always be the same for a given object. That's 
why I thought that for objects that XMIReferenceProvider does not care 
about, null can be returned so that XMIWriter can assign any xmi.id to 
it. This way we could preserve stateless XMIReferenceProvider and allow 
multithreaded access also to XMIWriter. But even when not allowing null 
from getXmiId the XMIReferenceProvider can be virtually stateless by 
having an internal counter of type "long" that would obviously be enough 
for generating xmi.ids that it does not care about for the whole life of 
XMIReferenceProvider.
This reminds me that I have to allow returning "null" from the 
getSystemId method that would mean that XMIReferenceProvider does not 
control which file a given object should go to.
I have the following scenario in mind:
All MOF metamodels import PrimitiveTypes package from MOF metamodel. 
Thus the XMIReferenceProvider can return fixed XMI.IDs and systemID for 
PrimitiveTypes package and its elements and systemID=null, xmi.id="a" + 
increment++ for other objects.

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

I would rather say the implementations _must_ be thread safe to avoid 
problems if someone replaces our default XMIReader implementation with 
their thread-unsafe implementation.

> 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())). 

It is still possible. You can create your own subclasses of these 
abstract classes which is even better, because this way you can ensure 
in the implementation that the properties of the configuration cannot be 
changed - this is important if you want to share the default 
implementation. That tells me that maybe I should allow to return 
UnsupportedOperationException from setters and state that config 
returned from getConfiguration of reader/writer must implement these 
operations.

> 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?

In the meta-inf lookup this is not possible. You can write your own 
implementation of lookup and pass it the your java program in properties 
(I think it is org.openide.util.Lookup=<your lookup class>) which allows 
that, or if you are in NetBeans, you can programmaticaly add a new 
instance DataObject to the services folder in the default filesystem.

>> 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 agree.
Martin