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