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.

Bug 204653 - BouncyCastle jar not found in Netbeans 7.1
Summary: BouncyCastle jar not found in Netbeans 7.1
Status: RESOLVED INCOMPLETE
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 7.1
Hardware: PC Linux
: P2 normal (vote)
Assignee: Sergey Petrov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-03 21:31 UTC by efhilton
Modified: 2012-01-31 18:14 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Bad set of config files. These result in BouncyCastle not found exception. (19.68 KB, application/x-gzip)
2012-01-24 21:17 UTC, efhilton
Details
Bad set of config files. These result in BouncyCastle not found exception. (20.05 KB, application/x-gzip)
2012-01-24 21:18 UTC, efhilton
Details
Good set of config files. No exceptions while compiling in 7.1 (19.68 KB, application/x-gzip)
2012-01-24 21:18 UTC, efhilton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description efhilton 2011-11-03 21:31:47 UTC
Product Version = NetBeans IDE 7.1 Beta (Build 201109252201)
Operating System = Linux version 2.6.38-12-generic running on amd64
Java; VM; Vendor = 1.6.0_26
Runtime = Java HotSpot(TM) 64-Bit Server VM 20.1-b02

While attempting to build my EAR and EJB project, I get that the bouncycastle jar is not found. 

If I go back to 7.0.1, the project builds flawlessly.

I'm comparing the virgin 

This is the actual exception:

================= cut here =========================
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.RuntimeException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for org.bouncycastle.asn1.DERObjectIdentifier not found
	at org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor.process(CanonicalModelProcessor.java:407)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:625)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:554)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:699)
	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:981)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:727)
	at com.sun.tools.javac.main.Main.compile(Main.java:353)
	at com.sun.tools.javac.main.Main.compile(Main.java:279)
	at com.sun.tools.javac.main.Main.compile(Main.java:270)
	at com.sun.tools.javac.Main.compile(Main.java:69)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.taskdefs.compilers.Javac13.execute(Javac13.java:56)
	at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1134)
	at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:912)
	at org.netbeans.modules.java.source.ant.JavacTask.execute(JavacTask.java:144)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:390)
	at org.apache.tools.ant.Target.performTasks(Target.java:411)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
	at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
	at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
	at org.apache.tools.ant.Task.perform(Task.java:348)
	at org.apache.tools.ant.Target.execute(Target.java:390)
	at org.apache.tools.ant.Target.performTasks(Target.java:411)
	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
	at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
	at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
	at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
	at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:285)
	at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:539)
	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Caused by: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for org.bouncycastle.asn1.DERObjectIdentifier not found
Comment 1 David Konecny 2011-11-06 21:45:23 UTC
Looks like a classpath issue. From exception I can see that when javac handles annotation processors an annotation processor from EclipseLink is triggered and (I'm guessing now) one of you JPA entity classes is referencing org.bouncycastle.asn1.DERObjectIdentifier but bouncycastle jar is not on the classpath of the annotation processor?

Sergey, were there any changes between 7.0.1 and 7.1 which could cause this problem? I'm increasing to P2 just to evaluate this issue promptly. Feel free to drop back to P3 if there is no regression on our side. Thx.
Comment 2 Sergey Petrov 2011-11-07 09:50:45 UTC
At least there was changes in eclipselink itself, it may be something on eclipselink side, also there was changes in issue 201117 affecting classpath and may be more but need more evaluation and also it's good to have reproducible testcase or sample project, I'm not sure there is much more evaluation possible without these details.
Also I can see it's quite old build 20110925 and may be it's fixed with "weaving" issue fix.

efhilton
can you try some lates daily build, attach sample project or provide steps to create a project?
Comment 3 Sergey Petrov 2011-11-08 13:25:38 UTC
please reopen with more details, I have no much ideas on evaluation right now, all is just guessing.
David, do you have any?
Comment 4 efhilton 2011-11-22 14:34:23 UTC
I just upgraded to Netbeans 7.1, one of the later nightly builds:

Product Version: NetBeans IDE Dev (Build 201111090600)
Java: 1.7.0_147-icedtea; OpenJDK 64-Bit Server VM 21.0-b17
System: Linux version 3.0.0-13-generic running on amd64; UTF-8; en_US (nb)
User directory: /home/efhilton/.netbeans/dev
Cache directory: /home/efhilton/.netbeans/dev/var/cache

The problem continues to be there.  I try to build our project and it fails with the same exception as before.  If I go back to IDE 7.0.1 it builds with flying colors.

I'll see if I get a chance sometime during the remainder of the week to try to come up with a test project that I can send to you.
Comment 5 Sergey Petrov 2011-11-23 10:14:57 UTC
Any hints on how to create this project may help too.
Comment 6 efhilton 2011-12-14 20:01:39 UTC
There seem to be two issues that may be affecting this.

First, there seems to be an ugly interaction between Netbeans and the revision control system.  Somehow, from what I can see, every time we run Netbeans it seems to be toggling the classpath variable in project properties.  According to my subversion history for this specific project, at some point in the past the classpath was cleared, which may be leading to this.

Second, during the move to 7.1, it seems as if there have been some small modifications to the paths. So, if you start up Netbeans 7.1 and import the settings from previous versions of Netbeans, it appears as if your paths will be wrong, thus leading to the problem that I describe here.  In fact, this seems to be another manifestation of another submission that I recently filed: 551409.
Comment 7 David Konecny 2011-12-14 21:47:00 UTC
(In reply to comment #6)
> First, there seems to be an ugly interaction between Netbeans and the revision
> control system.  Somehow, from what I can see, every time we run Netbeans it
> seems to be toggling the classpath variable in project properties.  According
> to my subversion history for this specific project, at some point in the past
> the classpath was cleared, which may be leading to this.

Could you be more concrete please? What exact property are you talking about? What was the value in the past and what is the value now? Could you track down who/what is toggling the classpath? Is it a usage of some different NetBeans versions perhaps? Or is it a result of some user action? When you say "toggling" you mean toggling between what values?

> Second, during the move to 7.1, it seems as if there have been some small
> modifications to the paths. So, if you start up Netbeans 7.1 and import the
> settings from previous versions of Netbeans, it appears as if your paths will
> be wrong, thus leading to the problem that I describe here. 

Again some example of what paths get wrong and what is the wrong and correct value might shed more light on your problem. Without that we cannot really help you. Could you narrow problem down to a few steps which we could use reproduce the problem?

> In fact, this
> seems to be another manifestation of another submission that I recently filed:
> 551409.

You made a typo in the bug number?
Comment 8 efhilton 2011-12-14 22:43:56 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > First, there seems to be an ugly interaction between Netbeans and the revision
> > control system.  Somehow, from what I can see, every time we run Netbeans it
> > seems to be toggling the classpath variable in project properties.  According
> > to my subversion history for this specific project, at some point in the past
> > the classpath was cleared, which may be leading to this.
> 
> Could you be more concrete please? What exact property are you talking about?
> What was the value in the past and what is the value now? Could you track down
> who/what is toggling the classpath? Is it a usage of some different NetBeans
> versions perhaps? Or is it a result of some user action? When you say
> "toggling" you mean toggling between what values?

Ok, my bad.  Let me give you an example.  I have an Enterprise (eg. EAR) project.  This project links to several EJB Module projects.  This project itself does not have any source code and therefore we never make modifications to it. Occasionally, however, we group it with some other project and commit its changes to the repository.  Now, because we did NOT touch the project in any way whatsoever, you would assume that it should have no changes registering in the revision control system (eg. you should not see the blue harddrive looking thing next to the project name).  However, we always see changes (eg. there is always a blue harddrive sitting next to the name) happening in the netbeans/project.properties file.

In the project.properties file, the variable "j2ee.platform.classpath" is constantly toggling between a blank value or an actual path.  As an actual example, in revision 21 in the repository, we have a value in this variable.  In revision 22, it's blank. In revision 23 a new value was added to it.  As far as I can tell, this variable is updated every time I start up Netbeans 7.0.1.  

Again, remember that we NEVER make modifications to this project because this project is simply a placeholder that links to other EJB projects.

The same behavior is happening to all my projects, to the point that most of the time that I start up Netbeans, the blue harddrive is sitting next to any number of the projects.

We are presently using Mercurial as our revision control system, and I don't recall seeing this on Subversion.


> 
> > Second, during the move to 7.1, it seems as if there have been some small
> > modifications to the paths. So, if you start up Netbeans 7.1 and import the
> > settings from previous versions of Netbeans, it appears as if your paths will
> > be wrong, thus leading to the problem that I describe here. 
> 
> Again some example of what paths get wrong and what is the wrong and correct
> value might shed more light on your problem. Without that we cannot really help
> you. Could you narrow problem down to a few steps which we could use reproduce
> the problem?
> 

In netbeans 7.0.1, create a project. Put it under revision control (mercurial)

Close Netbeans. Look at netbeans/project.properties.

Start up netbeans 7.0.1, Look at netbeans/project.properties.  Chances are that the values for the netbeans/projects.properties have changed.  It doesn't seem to happen all the time, but it is something that my crew and I have noted on several times in the past.

I am looking at Netbeans 7.1RC2 right now, and I'm unable to recreate this problem.  Maybe it's fixed recently??


> > In fact, this
> > seems to be another manifestation of another submission that I recently filed:
> > 551409.
> 
> You made a typo in the bug number?

Hmm... it doesn't seem to be a bug number but an "Exception number"? It doesn't seem to have a bug id yet (it's still in triage?).
Comment 9 David Konecny 2011-12-15 19:58:11 UTC
Thanks for the additional info.

(In reply to comment #8)
> In the project.properties file, the variable "j2ee.platform.classpath" is
> constantly toggling between a blank value or an actual path.  As an actual
> example, in revision 21 in the repository, we have a value in this variable. 
> In revision 22, it's blank. In revision 23 a new value was added to it.  As far
> as I can tell, this variable is updated every time I start up Netbeans 7.0.1.  

When NetBeans opens a project it checks what application server the project requires and based on that information it tries to lookup an appropriate servers from IDE's servers registered under Services->Servers. After a server is found NetBeans takes server's classpath and assign it to project's j2ee.platform.classpath property. This works well as long as all team members working on a certain project have the same server registered in the IDE. It sounds like in your case that's not the case and one of your team members (I'm guessing here) does not have required server in the IDE and so NetBeans reset the classpath to blank and user push the change to your repository and later when the same project is opened by somebody else with the server registered in the IDE classpath gets sets again and change is pushed to main repo again. Is that possible explanation?

> 
> In netbeans 7.0.1, create a project. Put it under revision control (mercurial)
> 
> Close Netbeans. Look at netbeans/project.properties.
> 
> Start up netbeans 7.0.1, Look at netbeans/project.properties.  Chances are that
> the values for the netbeans/projects.properties have changed.  It doesn't seem
> to happen all the time, but it is something that my crew and I have noted on
> several times in the past.

Would it be "j2ee.platform.classpath" property or some other one? It is possible that there was a bug which got fixed. During project opening different subsystems of NetBeans IDE get a chance to update project properties and we always tried to be friendly to versioning control systems and do only necessary changes. If you have a concrete name of property which is changing without a reason (should be visible in your Mercurial history) then we can investigate the module handling that property and either confirm that it was a problem which was fixed or file a bug for that module.

> > > In fact, this
> > > seems to be another manifestation of another submission that I recently filed:
> > > 551409.
> > 
> > You made a typo in the bug number?
> 
> Hmm... it doesn't seem to be a bug number but an "Exception number"? It doesn't
> seem to have a bug id yet (it's still in triage?).

I see. It is http://statistics.netbeans.org/exceptions/detail.do?id=183767 - at first sight it does not look related to this problem though.
Comment 10 efhilton 2012-01-24 21:16:28 UTC
Ok, after several weeks of frustration of trying to track down paths and mercurial changes, I have finally had some success to at least compile my project in Netbeans 7.1.

I am attaching two files: 

nbproject.good.tar.gz
nbproject.bad.tar.gz

These come from the same project, whereas one set of files works, the other ones do not.

As per our previous discussions, I have tried to recreate the problem in several ways by starting a project in 7.0.1 and then trying to then migrate the project to 7.1. The result is that I have not been successful at creating a brand new project that fails after the migration.  Regardless, all of our existing code in our mercurial repositories continue to fail during compilation time after the move to Netbeans 7.1. The failure is always the same: bouncycastle not found.  

The only thing that we have not done is to involve Mercurial in any way whatsoever during the test trials. And as such, we've had a 100% success rate in migrating a test project created in 7.0.1 to 7.1. So, the tool does not seem to be causing the problem, but rather the interface between the tool and mercurial (in fact we've found already several bugs in the way mercurial integrates with Netbeans -- where mercurial mangles the file and netbeans doesn't know how to handle it).

What the two attachments show are the project files from the same project. The good tar.gz file comes from as created by Netbeans 7.1.  The other one comes from what used to compile successfully in 7.0.1.  To create these files, I:

1. Created the project under 7.0.1.  Maintained the project under revision control (Mercurial).

2.  create a brand new project under Netbeans 7.1 with the same name.  I tarred and gzipped this project folder.

3. I took my gzipped folder from (2) and untarred it on top of item (1) above. 

I hope this helps.
Comment 11 efhilton 2012-01-24 21:17:13 UTC
Created attachment 115205 [details]
Bad set of config files. These result in BouncyCastle not found exception.
Comment 12 efhilton 2012-01-24 21:18:23 UTC
Created attachment 115206 [details]
Bad set of config files. These result in BouncyCastle not found exception.
Comment 13 efhilton 2012-01-24 21:18:52 UTC
Created attachment 115207 [details]
Good set of config files. No exceptions while compiling in 7.1
Comment 14 David Konecny 2012-01-25 00:13:22 UTC
I'm looking at the difference between bad and good nbproject and there are only few differences:

* bad nbproject contains "annotation.processing.processor.options=-Aeclipselink.canonicalmodel.use_static_factory=false"

* bad nbproject contains ${libs.JDOM-1.1.1.classpath} on compilation classpath

* bad nbproject contains ${libs.eclipselink.classpath}:${libs.eclipselinkmodelgen.classpath} on its processor classpath

* bad nbproject has 1.7 source and target

Everything else looks innocent. Do you have any idea Sergey? I do not.
Comment 15 Sergey Petrov 2012-01-25 09:50:26 UTC
have no ideas, it's unlikely there is any BouncyCastle in eclipselink, but it may have sense to play with removal of "extra" options to see which one may affect compilation.
Comment 16 David Konecny 2012-01-25 21:51:50 UTC
(In reply to comment #15)
> have no ideas, it's unlikely there is any BouncyCastle in eclipselink

Sergey, one difference is that "bad" version contains eclipselink annotation processor on processor classpath but "good" one does not. And executing annotation processor from EclipseLink causes the problems and fails project compilation. So the problem seem to be that after opening a certain 7.0.1 NetBeans project in NetBeans 7.1 we automatically enable eclipse link annotation processor for some reason. Any idea what that might be?

efhilton, could you please check project properties of one of your bad projects and open "Compiling" tab and see whether "Enable Annotation Processing" is on? If it is try to disable it and that should make the compilation problem to go away.
Comment 17 Sergey Petrov 2012-01-26 08:16:37 UTC
In this case it's strange as from 1st comment @If I go back to 7.0.1, the project builds flawlessly.@
Also from your comment there is no difference in "enable" state for annotation processor, but there is a difference for classpath for ap and also for a property related to weaving as I see.
Comment 18 efhilton 2012-01-30 20:47:07 UTC
(In reply to comment #16)
> (In reply to comment #15)
> > have no ideas, it's unlikely there is any BouncyCastle in eclipselink
> 
> Sergey, one difference is that "bad" version contains eclipselink annotation
> processor on processor classpath but "good" one does not. And executing
> annotation processor from EclipseLink causes the problems and fails project
> compilation. So the problem seem to be that after opening a certain 7.0.1
> NetBeans project in NetBeans 7.1 we automatically enable eclipse link
> annotation processor for some reason. Any idea what that might be?
> 
> efhilton, could you please check project properties of one of your bad projects
> and open "Compiling" tab and see whether "Enable Annotation Processing" is on?
> If it is try to disable it and that should make the compilation problem to go
> away.

Confirmed.  On Netbeans 7.1 I disabled "Enable Annotation Processing".  It builds flawlessly, or at least the error goes away.
Comment 19 Sergey Petrov 2012-01-31 04:50:06 UTC
As exception is thrown from org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor it's expected there will be no issue with ap off. Good set of file contain "annotation.processing.enabled=true" and "annotation.processing.enabled.in.editor=true" and it have no impact on compilation. Something goes wrong with classpath for unknown reason.
Comment 20 David Konecny 2012-01-31 18:00:51 UTC
(In reply to comment #17)
> Also from your comment there is no difference in "enable" state for annotation
> processor, but there is a difference for classpath for ap and also for a
> property related to weaving as I see.

Sergey, so why opening a project in 7.1 causes its annotation processor classpath to be automatically updated?
Comment 21 David Konecny 2012-01-31 18:04:05 UTC
(In reply to comment #18)
> Confirmed.  On Netbeans 7.1 I disabled "Enable Annotation Processing".  It
> builds flawlessly, or at least the error goes away.

Great. Could you try to create please a simple new test project with "Enable Annotation Processing" ON which would demonstrate the problem and attach it to this issue? You may have to tweak your classpath little bit to achieve that I think. Thanks!
Comment 22 Sergey Petrov 2012-01-31 18:14:46 UTC
>causes its annotation processor classpath to be automatically updated

are you sure it's the reason?
there are two ons - first is reopening in 7.0 still works if I got it right and it's not updated for other "good" projects which works both in 7.0 and in 7.1.