Bugzilla – Full Text Bug Listing
| Summary: | Classloader problem with APT | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Christian Plesner Hansen <stderr> | ||||||||
| Component: | APT | Assignee: | Generic inbox for the JDT-APT component <jdt-apt-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | eclipse, i.am.joel, jgarms | ||||||||
| Version: | 3.3 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | Macintosh | ||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Christian Plesner Hansen
Is your processor packaged as a jar file or as a plug-in (that extends annotationProcessorFactory)? Are the string resources in the same jar or plug-in as the processor, or are they (or a class or resource they depend upon) elsewhere? Can you attach a copy of your .factorypath file (or just include contents in a comment in the bug, if they're short)? Please assign back to me after providing that info. Thanks. (In reply to comment #1) > Is your processor packaged as a jar file or as a plug-in (that extends > annotationProcessorFactory)? It's a jar generated from a plugin that defines an extension of aPF. > Are the string resources in the same jar or plug-in as the processor, or are > they (or a class or resource they depend upon) elsewhere? It's all in the same jar. > Can you attach a copy of your .factorypath file (or just include contents in a > comment in the bug, if they're short)? <factorypath> <factorypathentry kind="WKSPJAR" id="/org.quenta.pql.apt/lib/pql.jar" enabled="true" runInBatchMode="false"/> </factorypath> (In reply to comment #2) I'm looking now at the JRE source code for ResourceBundle.getBundle(). It looks like it plays some substantial classloader tricks (e.g., it has a getLoader() method that calls a private native undocumented method getClassContext() to get some sort of stack of Classes, that it then navigates to find one it thinks is right...). Wouldn't surprise me if it didn't get along with the Eclipse classloader. Are you able to debug into that stack trace of yours, to look and see what classloader it's getting inside ResourceBundle.getLoader()? My suspicion is that we'll have to punt this over to the Platform team to figure out the interaction, but let's get as much info as possible first. FWIW, the classloader we use to load your jar is created in the org.eclipse.jdt.apt.core plug-in, in AnnotationProcessorFactoryLoader.createClassloader(). It's very simple, just an URLClassLoader parented by our code and adding your jar file. Created attachment 51888 [details]
First instance of annotation processor
Created attachment 51889 [details]
Second instance of annotation processor
I've attached two jars that can be used to reproduce the bug. Here's how it works: 1: create a new java project 2: copy test-apt-1.jar into the project as test-apt.jar 3: add test-apt.jar to the build path and enable the annotation processor in the jar 4: create a class and annotate it with @APTTestAnnotation, save the file 5: copy test-apt-2.jar into the project as test-apt.jar At this point I get the error I originally reported. Both jars contain the same classes and both work fine when used by themselves. #2 is just #1 unpacked and then packed again. (In reply to comment #6) Let me see if I correctly understand... are you saying that both jars work fine in isolation, regardless of build or reconcile phase, but that the problem manifests itself when you replace one jar with the other on the fly? That is, at that point, a build still works, but reconcile starts failing? (In reply to comment #7) > (In reply to comment #6) > > Let me see if I correctly understand... are you saying that both jars work > fine in isolation, regardless of build or reconcile phase, but that the problem > manifests itself when you replace one jar with the other on the fly? Yes. > at that point, a build still works, but reconcile starts failing? No, not exactly -- an error shows up in the log immediately after the second jar is copied into the project. The build/reconcile thing might not be the problem. (In reply to comment #8) What is the precise information in the error that is reported in the log? It does make sense that a reconcile could fail shortly after you change a jar file on the factory path. We cache the classloaders, and dump the cache when we detect a change such as that; but if the reconcile is triggered before we get the change notification to dump the cache, then the cached classloader would be pointing to a jar file that no longer exists (even though another one has taken its place on disk). Do reconciles fail from that point onward, or does the problem correct itself? Note that if you are copying the jar file via the filesystem rather than within the Eclipse IDE, you may need to refresh the workspace (F5) for Eclipse to detect the change and fire the notification that results in the classloader cache being dumped. The same would be true if you changed a jar on the classpath, I think. > What is the precise information in the error that is reported in the log? eclipse.buildId=I20060922-0010 java.version=1.5.0_06 java.vendor=Apple Computer, Inc. BootLoader constants: OS=macosx, ARCH=ppc, WS=carbon, NL=en_US Framework arguments: -keyring /Users/plesner/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws carbon -keyring /Users/plesner/.eclipse_keyring -consoleLog -showlocation Error Thu Oct 12 23:58:43 CEST 2006 Unexpected failure running APT on the file(s): MyClass.java java.lang.ExceptionInInitializerError at apt.test.TestProcessor$1.process(TestProcessor.java:19) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.dispatchToFileBasedProcessor(APTDispatchRunnable.java:545) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTInFileBasedMode(APTDispatchRunnable.java:265) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:579) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.access$1(APTDispatchRunnable.java:563) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable$2.run(APTDispatchRunnable.java:217) at org.eclipse.jdt.apt.core.internal.env.BuildEnv$CallbackRequestor.acceptBinding(BuildEnv.java:633) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:793) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:466) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:707) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:820) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:381) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:84) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:223) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:170) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:86) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:157) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:509) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:274) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:59) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:249) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:169) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:607) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:162) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:196) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:225) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:228) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:302) at org.eclipse.core.internal.resources.Project.build(Project.java:88) at org.eclipse.jdt.internal.ui.util.CoreUtility$BuildJob.run(CoreUtility.java:142) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) Caused by: java.util.MissingResourceException: Can't find bundle for base name apt.test.messages, locale en_US at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:836) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:805) at java.util.ResourceBundle.getBundle(ResourceBundle.java:549) at apt.test.Messages.<clinit>(Messages.java:10) ... 34 more > Do reconciles fail from that point onward, or does the problem correct itself? Both reconciles and builds continue to fail with a ClassDefNotFound when they try to access the class whose initialization failed. > Note that if you are copying the jar file via the filesystem rather than within > the Eclipse IDE, you may need to refresh the workspace (F5) for Eclipse to > detect the change and fire the notification that results in the classloader > cache being dumped. The same would be true if you changed a jar on the > classpath, I think. It's all within the IDE -- I drag the files into the package explorer from Finder. I've tried to reproduce this error in the debugger but unsuccessfully, since it all comes down to dynamic loading of different jars which is pretty tricky to debug. So I don't know which classloader ResourceBundle ends up with. It does sound like we're not successfully dumping the classloader cache - possibly we're not getting the notification event? I'll look into it. Changing OS from Mac OS to Mac OS X as per bug 185991 I am having a similar problem during the processing of a WebService annotation. My Eclipse application depends on communicating with a server via web services. I use standard annotations in the classes. This has been working for a long time under both Win XP and Linux without issue. I am now trying to get the application running on OS X 10.5 (Leopard) and I have ran into a problem. On OS X I get a RuntimeModelerException "A WebService annotation is not present on class: com.etish.useme.est.webservices.server.Server" when running inside Eclipse. Well the class in questions is annotated. In fact I have a mock client I use for testing the server code which exercises the same call from the command line and it works perfectly. I have ran this through the debugger and it appears that the class in question does *not* have annotations. At least the annotations field on the interface inside the debugger indicates a size=0 and keyset is null. There is no chance of a bad copy being loaded as only one copy exists in the workspace and as I said the exact same artifacts are used to launch the tests as a java program. Created attachment 86454 [details]
Stacktrace of failure to process WebService annotation.
Btw, are there any workarounds for this problem? It is a show stopper for me on OS X. (In reply to comment #15) > Btw, are there any workarounds for this problem? It is a show stopper for me on > OS X. I don't believe your problem is identical, though the underlying cause might be related. The original problem has to do with problems when a jar file changes; see Comment #8. I think trying to address your bug in this context is just going to be confusing, especially since your bug appears to be related to a platform issue (works fine on Linux and Windows but not on Mac) and does not appear to have anything to do with APT (there is no APT code in your stack trace). Can you please enter a separate bug? You can reference this bug from that one, if you would like. Reassigning to jdt-apt-inbox, per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |