Re: PROPOSAL: Extensions to XMIReader and XMIWriter interfaces

Brian Smith <[email protected]>
Newsgroups gmane.comp.java.netbeans.modules.mdr.devel
Organization CollabNet Hosting
Message-ID <[email protected]>
Martin Matula wrote:
> Brian Smith wrote:
> 
>> Martin Matula wrote:
>>
>>> Extend XMIReader interface by adding the same read methods that it 
>>> already has but with additional parameter of type HRefResolver.
>>
>> I think this isn't a good idea because then users won't be able to use 
>> their own HRefResolver with the methods already defined. I think it 
>> might be better to have a "setHRefResolver" method on XMIWriter, and 
>> if it isn't called, then XMIWriter will use a default HRefResolver 
>> (e.g. Lookup.getDefault().lookup(HRefResolver.class)).
> 
> Hm. The problem with this approach is that it introduces the concurency 
> issues. (i.e. can modules that do not use HRefResolver be sure that the 
> XMIWriter/Reader do what they are expected to?, what if someone forgets 
> to unset the HRefResolver/XMIReferenceProvider?, etc.)
> Maybe a solution could be a registry of HRefResolvers and 
> XMIReferenceProviders.

Yes, you are right, my idea doesn't work well when multiple clients are 
sharing the same XMIReader/XMIWriter. But at the same time, I don't 
think it makes sense to keep adding methods to XMIWriter/XMIReader that 
add an extra argument for each possible customization. For example, in 
the (near?) future you will probably want to be able to handle 
XMI.extension elements and also be able to deal with XMI.header 
information. And I think you will end up with combinitorial growth in 
the number of methods in these interfaces if the plug-in functionality 
is done by adding parameters to the read/write methods in these interfaces.

>> This way, we can set the default resolver at application start up 
>> time, and thus isolate direct dependencies on MDR-specific methods to 
>> a smaller part of our code.
> 
> Do you think the lookup is appropriate? AFAIK there is no way of 
> redefining lookup entries in your application if MDR library already 
> adds the default implementation of HRefResolver.

I am wondering if Lookup is appropriate for XMIWriter and XMIReader. 
Perhaps XMIWriter and XMIReader instances shouldn't be shared?

 > Should we then remove
> all meta-inf lookup entries from the MDR libraries themselves and move 
> them to the applications that use MDR? (this would solve also the issue 
> that we currently have with dev builds of NB - see the e-mail I sent out 
> this morning).

I don't really know how to solve this lookup issue, but it seems that it 
will is already being resolved in a way that doesn't require the 
removal. If you want to remove the meta-inf/services entries that is 
fine by me, but I'd like to decide one way or the other soon because I'm 
hoping to let people try out the tool I mentioned a while back (a 
standalone command-line tool) and I'm currently using the default lookup 
for that.

- Brian
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.