Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 125493 - ClassNotFoundException: JAXBException with jdk 6u4
ClassNotFoundException: JAXBException with jdk 6u4
Status: RESOLVED DUPLICATE of bug 125655
Product: platform
Classification: Unclassified
Component: Module System
PC Linux
: P1 with 1 vote (vote)
Assigned To: Jesse Glick
Depends on:
  Show dependency treegraph
Reported: 2008-01-17 16:05 UTC by mgoe
Modified: 2008-12-23 14:24 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT

Module suite project showing the issue. (2.22 MB, application/x-gzip)
2008-01-17 16:08 UTC, mgoe

Note You need to log in before you can comment on or make changes to this bug.
Description mgoe 2008-01-17 16:05:57 UTC
I'm using JAXB in a Netbeans 6 module suite project. After I switched to jdk 6u4 the application does no longer work. 
The application compiles. But during runtime I get the following ClassNotFoundException:

java.lang.ClassNotFoundException: javax.xml.bind.JAXBException
	at org.netbeans.ProxyClassLoader.loadClass(
	at java.lang.ClassLoader.loadClass(
	at java.lang.ClassLoader.loadClassInternal(
Caused: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
	at org.yourorghere.module1.JAXBAction.performAction(
	at org.openide.util.actions.CallableSystemAction$
	at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(
	at org.openide.util.actions.CallableSystemAction.actionPerformed(
	at javax.swing.AbstractButton.fireActionPerformed(
	at javax.swing.AbstractButton$Handler.actionPerformed(
	at javax.swing.DefaultButtonModel.fireActionPerformed(
	at javax.swing.DefaultButtonModel.setPressed(
	at javax.swing.AbstractButton.doClick(
	at javax.swing.plaf.basic.BasicMenuItemUI.doClick(
	at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(
	at java.awt.Component.processMouseEvent(
	at javax.swing.JComponent.processMouseEvent(
	at java.awt.Component.processEvent(
	at java.awt.Container.processEvent(
	at java.awt.Component.dispatchEventImpl(
	at java.awt.Container.dispatchEventImpl(
	at java.awt.Component.dispatchEvent(
	at java.awt.LightweightDispatcher.retargetMouseEvent(
	at java.awt.LightweightDispatcher.processMouseEvent(
	at java.awt.LightweightDispatcher.dispatchEvent(
	at java.awt.Container.dispatchEventImpl(
	at java.awt.Window.dispatchEventImpl(
	at java.awt.Component.dispatchEvent(
[catch] at java.awt.EventQueue.dispatchEvent(
	at java.awt.EventDispatchThread.pumpOneEventForFilters(
	at java.awt.EventDispatchThread.pumpEventsForFilter(
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(
	at java.awt.EventDispatchThread.pumpEvents(
	at java.awt.EventDispatchThread.pumpEvents(
Comment 1 mgoe 2008-01-17 16:08:44 UTC
Created attachment 55209 [details]
Module suite project showing the issue.
Comment 2 mgoe 2008-01-17 16:11:21 UTC
I added a module suite project which shows the problem. Just select File>JAXBAction to trigger the Exception shown in 
my bug report.
Comment 3 Lukas Hasik 2008-01-21 14:44:39 UTC
reassigning to pnejedly - isn't it caused by the warmup cache? 
also CC'ing Jarda. Maybe he fixed in issue 125655.

Anyway, please evaluate it. This is P1 that is considered to be stopper for 6.1 M1. It needs to be evaluated/fixed ASAP
thank you
Comment 4 Petr Nejedly 2008-01-21 15:43:04 UTC
Hardly related to startup cache - the user runs NB6.0, not a dev build.
Comment 5 Jesse Glick 2008-01-21 19:20:20 UTC
You cannot currently use the JRE's version of these classes. You must include JAXB in a lib wrapper module and depend on it.

*** This issue has been marked as a duplicate of 96711 ***
Comment 6 mgoe 2008-01-22 10:20:38 UTC
I don't think that it is a good idea to suppress the jre provided classes for several reasons:

1. Bugs
If there is a bug in a class normally provided by the jre but replaced/suppressed by netbeans you will not be able to 
write a bug report against the jre. The jre people will always reject bug reports for classes not contained in the jre 
because the jre has been tested with the classes it contains.

2. License issues
Even for a lawyer it is sometimes very hard to find out if you are allowed to extract some jars from a project and use 
them in another project. For that reason I don't want to use classes from an external source if they are present in 
the jre.

3. Endorsed dirs mechanism
There is an established way to replace classes in the jre with newer ones using the endorsed dirs mechanism. Why 
reinvent the wheel?

4 Documentation issues
Where is the documentation of the classes suppressed by netbeans. Who will decide which classes should be suppressed.

For the reasons mentioned above I would like to have a netbeans platform which per default does not alter the jre in 
any way. If a developer requires changes the developer should be forced to switch on these changes manually for 
example by a property.

Best regards,
Martin Goettlicher
Comment 7 Jesse Glick 2008-01-23 21:17:52 UTC
See issue #96711.
Comment 8 Jesse Glick 2008-02-16 00:51:49 UTC
Comment 9 Jesse Glick 2008-02-16 00:52:06 UTC

*** This issue has been marked as a duplicate of 125655 ***
Comment 10 Quality Engineering 2008-12-23 14:24:57 UTC
This issue had *4 votes* before move to platform component

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo