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.
Created attachment 104367 [details] sample project to reproduce issue A URLMapper is not registered in the lookup when in the process method of an annotations processor. Add the following code to attached maven project: URLMapper mapper = Lookup.getDefault().lookup(URLMapper.class); if (mapper == null) throw new RuntimeException("Missing URLMapper"); What would be a workaround? How to explicitly register a URLMapper in there? P1: until workaround is found. http://forums.netbeans.org/post-93375.html
P1? That must be a joke! Dear sympatic user, URLMapper seeks for implementations via Lookup.getDefault(). That is likely to work in any environment. Just make sure the proper implementation is on classpath.
> URLMapper seeks for implementations via Lookup.getDefault(). That is likely to work in any environment. Just make sure the proper implementation is on classpath. How do you do that? Any code/tutorial/sample? I've no clue and didn't expect to need to. Is NB dragging back into plumbing? Also, I consider this a bug, because it's not documented anywhere that this will not work at that phase: File tutorialFile = getFile(getSourceDir(), "/org/netbeans/test/codegen/Tutorial1.java"); JavaSource tutorialSource = JavaSource.forFileObject(FileUtil.toFileObject(tutorialFile)); http://wiki.netbeans.org/JavaHT_Modification But if you want, consider it a feature request? Can we avoid plumbing at that phase too?
I believe you are mixing apples and bananas. You are trying to use APIs of a java.source module during compilation, in side an AnnotationProcessor? http://wiki.netbeans.org/JavaHT_Modification That is insane. AnnotationProcessor comes from JDK, it is NetBeans IDE independent. You can't use arbitrary NetBeans APIs in it! If you want to perform a modification of your sources files, consider writing a NetBeans module.
I don't see why do the APIs I'm accessing need to be nbm modules (NB dependant). They provide generic utility/wrappers of the JDK classes in the first place. The dependance comes once one needs to access the Document editor, for example. Likewise, in the sample project you see that indeed the method I'm complaining about works inside a unit test (without the need of being within an nbm module). The inconsistency is that it won't work inside the process() method.
This is due to a classloader issue when running the annotation processor. Just add this line in the beginning of the process() method, and you're golden: Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); Has nothing to do with NetBeans API's :)
(In reply to comment #5) > This is due to a classloader issue when running the annotation processor. Just Is this an issue/bug in the jdk then? Why is this boilerplate line required? Would it not be a sensible default? > add this line in the beginning of the process() method, and you're golden: > > Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); > This indeed solved the FileObject fileObj = FileUtil.toFileObject(srcFile) issue, but not: final JavaSource classSource = JavaSource.forFileObject(fileObj), which is now null. > Has nothing to do with NetBeans API's :) I now see why too.
JavaSource.forFileObject(fileObj) is null because fileObj represents "test.txt". Point it to a class file, and it will load just fine. Rename test.txt to Test.java and put "public class Test {}" in it, you'll see :)
s/class file/java source file/g
Using NB Java infrastructure inside an annotation processor is not reasonably possible, in my opinion (except very rare edge cases). It depends on the NB's version of javac, and on the NB module system to mask out the JDK's version of the javac classes (in tests this is solved by prepending the NB version on the bootclasspath).