This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I'm using code like this (details can be found in the contrib module, under audit, in the class "Audit.java", and in the mf-layer.xml in the same directory): Lookup l = Lookup.getDefault(); l.lookup(RuleCompareTo.class); //l.lookup(RuleEquals.class); [...] Lookup.Template lt = new Lookup.Template(Rule.class); Lookup.Result lr = l.lookup(lt); Set ruleset = lr.allClasses(); System.out.println("ruleset: " + ruleset); [...] and entries like this in the mf-layer: <file name="org-netbeans-modules-audit-rules-RuleCompareTo.instance"> <attr name="instanceOf" stringvalue="org.netbeans.modules.audit.rules.RuleCompareTo"/> </file> This code will find the "RuleCompareTo" but not the "RuleEquals" class (the RuleEquals entry *is* in the xml layer, just didn't want to repeat so much). If I remove the // before the lookup on RuleEquals.class, it will also find that one. I would, however, like to find all classes that I have mentioned in the xml layer and included in the jar. This is currently keeping me from being able to use dynamic extension.
Created attachment 6229 [details] Zip of source code that includes the Audit.java file and the mf-layer.xml
Shouldn't instanceOf be Rule, not RuleEquals (etc.)??
I think it might be; but as far as I remember, I tried this, with not difference. I'll try again, though. In any case, it doesn't explain why the lookup with templates works when you have done a lookup on the class, but doesn't when you haven't. Also, as far as I understand, the lookup system is supposed to know which classes implement the interface I send in the template.
Found it. If you get instanceOf wrong, it *does* matter how you prime lookup. With the broken .instance files, the lookup of RuleCompare finds the instance, so this is added to the memory pool of objects. Then the lookup of Rule might use this instance - because it can see it is really assignable to Rule - but not the broken .instance for RuleEquals - because it cannot know whether it is assignable to Rule without doing a classload, which it will not do, because the presence of instanceOf tells it not to. The lookup system *cannot* know which classes implement the interface you give in the template without loading them, and instanceOf is specifically designed to avoid loading them. If you are confused by instanceOf, don't use it, and the classes will always be loaded and the result should be correct. It is a useful optimization but it has to be accurate: no lookup query can be guaranteed to find a .instance using instanceOf unless the queried class is listed among the instanceOf classes.
>The lookup system *cannot* know which classes implement the interface you give in the template without loading them, and instanceOf is specifically designed to avoid loading them. >If you are confused by instanceOf, don't use it, and the classes will always be loaded and the result should be correct. Are you saying that if I simply leave out the mf-layer declarations, it should work? Because I thought that you have to use it to register your objects for lookup. Or do I have to use another form? >It is a useful optimization but it has to be accurate: no lookup query can be guaranteed to find a .instance using instanceOf unless the queried class is listed among the instanceOf classes. BTW please take this as an opportunity to have a look at the lookup documentation (I used mainly the one in the book), to check whether it is sufficiently clear.
> Are you saying that if I simply leave out the > mf-layer declarations, it should work? Because I thought that > you have to use it to register your objects for lookup. Or do I have > to use another > form? No. You have to register it in mf-layer but you don't have to use the instanceOf clauses. Use just instanceClass or direct filenames.
In other words: you do not need to use instanceOf, it is only an optimization, but if you do it use it had better be correct. It is fine to omit a superinterface like java.io.Serializable that no one would query on anyway, but queries against omitted superclasses/superinterfaces may or may not succeed. I added a cautionary note to the Services API.
Okay, mea culpa for reading the book, not the services API (just did a search on "xml-layer" or "mf-layer" or something like that, and tried to use what came out of there; which was primarily the book). When I *had* read the services API, I wasn't yet ready to think about lookup. So, I think the API doc is *much* clearer than that in the book, seemingly reversing the priorities between instanceOf and instanceClass (among other things). I'll give more specific feedback on the "designated place".
that should read: ... API doc is *much* clearer than that in the book, which seemingly reverses ...
for the record, the proper way to achieve the effect is: <file name="org- netbeans-modules-audit-rules-RuleCompareTo.instance"> <attr name="instanceClass" stringvalue="org.netbeans.modules.audit.rules.RuleCompareTo"/> </file> BTW I inadvertedly tried to use instanceClass...Rule (which is abstract); this correctly gave me an InstantiationException at Runtime. However, the knowledge that this is invalid is available at build time. Are there any provisions for checking layer files during ant build?
Well actually the *best* way is to use both instanceClass and instanceOf correctly, but yes what you have should work. You can do a syntactic check of layers at build time (see master build script) but there is no provision for semantic checks currently. It could get very complicated to do this. A runtime check seems much more practical.
I'll look into using the *best* way. The audit module is precisely the place for semantic checks, so I'll keep in mind to allow it to be expanded from .java files to netbeans xml layers (and other file types, of course). This particular condition ("does an instanceClass attribute declare a non-concrete class"?) won't be that hard to do.
Resolved for 3.4.x or earlier, no new info since then -> closing.