This bug already has 100 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=124462

Created attachment 92561 [details]
stacktrace

I  tried a few ways to get around my problem here. I cannot seem to generate a new project unless NetBeans has only just been opened. If I need to create a new class or project, I need to exit the program and then open it again. Sorry to "bug" you good people with this, but is NetBeans going to work on Ubuntu 9.10?

*** Bug 176846 has been marked as a duplicate of this bug. ***

99% of the reports are from Linux.
http://statistics.netbeans.org/exceptions/showduplicateslist.do?id=124462

I was able to reproduce on my Ubuntu 9.10 with NB 6.7.1 installed from Ubuntu native packages. Creating a class in a project raises CNFE either for log4j.Logger or for freemarker.RsrcLoader. Restart does not help, neither does deleting classloader caches at .netbeans/6.7/var/cache/all-*

IMO related to the installation via Ubuntu native packages.

Reassigning to installer/debian. Please, evaluate.

Hi Tonda,

Any insight on reproduction steps ?

Tried:
1. Start from scratch
2. Create new project and few classes in it
3. Create second project & classes
4. Wait some time or restart and create classes again: they are created w/o exception

Am I missing some step ? 

Tested on U 9.04 & NB 6.5. According to Exc. reports it should happen with any version 6.0.1-6.7.1

Hi Alexei. What I did was installed fresh 6.7.1 from packages (via Synaptic Package Manager the usual way) and started it. I also installed Maven from Plugins if that is the difference probably.

Any creation of a Java Class via New File wizard fails. I don't know if restarting the IDE after installing Maven is important or not.

Thanks! Maven+restart did the trick for me.

Very likely that some other plugins may highlight this problem as well.

Seems to be the problem with classloading. (ClassNotFoundException: org.apache.log4j.Logger starting from ModuleCL@12dd538[org.netbeans.libs.freemarker] with possible defining loaders [ModuleCL@2b249[org.netbeans.modules.maven.embedder]) see [1];
After Maven installation log4j is loaded from maven-embedder-2.1-20080623-patched.jar but seems to be not available for freemarker.

Jesse, Milos do you have any comments on this?

Another guess is that stripped ide doesn't originally contain any log4j dependency so this causes the problem somehow. So we should add such dependency.

Anyway a workaround exists (use "netbeans --cp:p /usr/share/java/log4j-1.2.jar"), so P1 -> P2. 

[1]:
........
........
FINER [org.netbeans.JarClassLoader]: Loading org/apache/log4j/Logger.class from /home/yn158264/.netbeans/6.8/modules/ext/maven-embedder-2.1-20080623-patched.jar
........
........
java.lang.ClassNotFoundException: org.apache.log4j.Logger
	at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
Caused: java.lang.ClassNotFoundException: org.apache.log4j.Logger starting from ModuleCL@12dd538[org.netbeans.libs.freemarker] with possible defining loaders [ModuleCL@2b249[org.netbeans.modules.maven.embedder]] and declared parents [ModuleCL@bc5596[org.netbeans.libs.jsr223], ModuleCL@33b121[org.netbeans.modules.queries], org.netbeans.MainImpl$BootClassLoader@dbe178]
	at org.netbeans.ProxyClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:336)
Caused: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
	at freemarker.log.Log4JLoggerFactory.getLogger(Log4JLoggerFactory.java:65)
	at freemarker.log.Logger.getLogger(Logger.java:255)
	at freemarker.template.utility.SecurityUtilities.<clinit>(SecurityUtilities.java:67)
	at freemarker.ext.beans.BeansWrapper.<clinit>(BeansWrapper.java:146)
	at freemarker.template.ObjectWrapper.<clinit>(ObjectWrapper.java:69)
	at freemarker.core.Configurable.<init>(Configurable.java:132)
	at freemarker.template.Configuration.<init>(Configuration.java:109)
	at freemarker.template.Configuration.<clinit>(Configuration.java:96)
	at org.netbeans.libs.freemarker.FreemarkerEngine.initFreeMarkerConfiguration(Unknown Source)
	at org.netbeans.libs.freemarker.FreemarkerEngine.eval(Unknown Source)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:249)

The workaround is integrated in netbeans-6.8 packages for Ubuntu.

We bundle freemarker-2.3.8.jar which does not include any class freemarker.log.Log4JLoggerFactory. If the native packages use some alternate version of FreeMarker which does, then that is likely the source of the problem.

To me it looks like freemarker.log.Logger.getLogger is failing to notice that log4j is unavailable.

http://freemarker.svn.sourceforge.net/viewvc/freemarker/trunk/freemarker/src/freemarker/log/Logger.java?revision=1016&view=markup

confirms that createFactory catches CNFE, but this is not enough: if freemarker is compiled against log4j but then run without it, no CNFE will be thrown here, but rather a NCDFE later. Suggest (compilable but untested):

Index: src/freemarker/log/Logger.java
===================================================================
--- src/freemarker/log/Logger.java	(revision 1174)
+++ src/freemarker/log/Logger.java	(working copy)
@@ -269,12 +269,18 @@
             {
                 try
                 {
-                    return createFactory(i);
+                    LoggerFactory f = createFactory(i);
+                    f.getLogger("just.testing");
+                    return f;
                 }
                 catch(ClassNotFoundException e)
                 {
                     ;//Intentionally ignored
                 }
+                catch(NoClassDefFoundError e)
+                {
+                    ;//Intentionally ignored
+                }
             }
             System.err.println("*** WARNING: FreeMarker logging suppressed! ***");
             return new NullLoggerFactory();

Jesse,
Thanks for the evaluation. The problem is that we can't patch freemarker in Ubuntu. Actually Ubuntu contains freemarker 2.3.16 whereas NetBeans uses 2.3.8.
I suppose we might want to switch NetBeans to 2.3.16 in the next release so patching freemarker is not the best solution. 
On the other hand it is quite strange that maven-embedder contains log4j binaries. Is it possible to warp log4j round its own module as it is done for another external projects? I suppose it can help.

well, the maven embedder has something like 20 external dependencies with versions that work. In general there should not be problems with encapsulation, unless the given binary has some weird autodiscovery mechanisms that backfire then. Having each binary wrapped in separate module is rather impractical here and can result in runtime linking errors when we upgrade bits in netbeans that have been incompatibly changed..
log4j is a dead project therefore the risk there is low I guess.

Milos,

In case if we want to see maven packaged in Linux (Tonda has recently raised this question) the embedder should be updated (separated into several modules) anyway. We can't place binaries in Ubuntu repos and have to use existing binaries. Log4j-1.2 exists in Ubuntu so having it in embedder jar is a big problem for packages. But this all is about future. 
Currently the problem is the following: since Ubuntu contains later version of the freemarker which tries to use log4j(since it available in embedder) but can't find it for some reason(may be classloading problem) the exception is thrown. I can't patch or update freemarker so have to patch NetBeans sources to resolve the issue. The problem is reproducible by replacing freemarker 2.3.8 with 2.3.16(http://sourceforge.net/projects/freemarker/files/freemarker/2.3.16/freemarker-2.3.16.tar.gz/download) in NetBean installation. If create a java class after such replacement the exception will be thrown.

(In reply to comment #11)
> we can't patch freemarker in Ubuntu.

I wasn't suggesting that you patch it. Get freemarker fixed upstream and push the Ubuntu packager to include the new release.

(In reply to comment #14)
> (In reply to comment #11)
> > we can't patch freemarker in Ubuntu.
> 
> I wasn't suggesting that you patch it. Get freemarker fixed upstream and push
> the Ubuntu packager to include the new release.

The latest release of the freemarker (2.3.16) won't fix this issue.
A patch against the freemarker sources like proposed one is not applicable for the Linux distributions.

AFAIU the maven.embedder module provides accessibility of the classes from the org.apache.log4j package located in maven-embedder-2.1-20080623-patched.jar for all other modules of the NetBeans, including for the libs.freemarker module. Why?

(In reply to comment #15)

> AFAIU the maven.embedder module provides accessibility of the classes from the
> org.apache.log4j package located in maven-embedder-2.1-20080623-patched.jar for
> all other modules of the NetBeans, including for the libs.freemarker module.
> Why?

No, if it provides anything, it does so only to the modules dependending on the module. That fact that log4j or freemarker ignores classloading hierarchy is actually the reason why log4j and commons-logging were abandoned by sane projects.

(In reply to comment #16)
> No, if it provides anything, it does so only to the modules dependending on the
> module. That fact that log4j or freemarker ignores classloading hierarchy is
> actually the reason why log4j and commons-logging were abandoned by sane
> projects.

The libs.freemarker module doesn't implement something that can change or destroy classloading that is usual for a NetBeans module. It is a simplest wrapper for the freemarker library.  The freemarker itself uses "normal" way to understand if the org/apache/log4j/Logger.class is accessible.  

Seems, a cause of the issue is that the maven.embedder module enables the private log4j package not only for the dependent modules, but for all other modules too.

(In reply to comment #17)
> The libs.freemarker module doesn't implement something that can change or
> destroy classloading that is usual for a NetBeans module. It is a simplest
> wrapper for the freemarker library.  The freemarker itself uses "normal" way to
> understand if the org/apache/log4j/Logger.class is accessible.  
> 
> Seems, a cause of the issue is that the maven.embedder module enables the
> private log4j package not only for the dependent modules, but for all other
> modules too.

Now this starts getting tiresome. Once again let me reiterate that if something in freemarker module attempts to load something in module that it doesn't depend on, the SOMETHING in the freemarker module is bypassing the module classloader constraints.

But since I'm a merry and helpful fellow, I've looked into the libs.freemarker/external/freemarket-license.txt and found this little gem of information there:

Name: FreeMarker
Version: 2.3.8
License: freemarker
Origin: http://mesh.dl.sourceforge.net/sourceforge/freemarker/freemarker-2.3.8.tar.gz
OSR: 5726
Description: Template engine
Comment: contents trimmed with pattern: freemarker/ext/* freemarker/ext/dom/* freemarker/ext/jdom/* freemarker/ext/jsp/* freemarker/ext/rhino/* freemarker/ext/servlet/* freemarker/ext/xml/* freemarker/log/**/Log4J* freemarker/log/**/Avalon* freemarker/**/*Jython* freemarker/cache/WebappTemplateLoader*


so I suppose the freemarker we ship is not a stock version of freemarker but a rather stripped one.

(In reply to comment #15)
> The latest release of the freemarker (2.3.16) won't fix this issue.

Why is why I recommended that the bug be fixed upstream so 2.3.17 (or whatever) can be released, and then bundled in common Linux distributions.

(In reply to comment #17)
> The freemarker itself uses "normal" way to
> understand if the org/apache/log4j/Logger.class is accessible.

As demonstrated in my patch, its technique for checking for the availability of log4j does not work as intended.

An occasion [1] gave me a chance to resolve this issue for the Fedora. It was solved for both the development branch and the Fedora 13 branch (current release).
A patch proposed by Jesse [2] has been provided for the FreeMarker package.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=569799
[2] http://cvs.fedoraproject.org/viewvc/rpms/freemarker/F-13/freemarker-2.3.13~logging.patch

I've tested the solution against the NB 6.8 installed from the RPMs and the Maven plugin installed from the UC "NetBeans for Fedora"...

* Added extra debug output gives the following result:
- unsuccessful attempt 1 
LoggerFactory   : freemarker.log.Log4JLoggerFactory@3822fc
LoggerFactory CL: ModuleCL@1ea0105[org.netbeans.libs.freemarker]
- successful attempt 2
LoggerFactory   : freemarker.log.JDK14LoggerFactory@ea3e3c
LoggerFactory CL: ModuleCL@1ea0105[org.netbeans.libs.freemarker]

* The creating of new projects (both java and maven), their builds, and creating of new java files inside these projects was completed without any exceptions.

*** Bug 186613 has been marked as a duplicate of this bug. ***

*** Bug 188701 has been marked as a duplicate of this bug. ***

Fixed in 6.8 packages