Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 342987

Summary: User Library is not checked to ensure Schema Compiler present
Product: [WebTools] Dali JPA Tools Reporter: Shaun Smith <shaun.smith>
Component: JAXBAssignee: Paul Fullbright <paul.fullbright>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: jolene.moffitt, neil.hauge, tranle1
Version: unspecifiedFlags: neil.hauge: pmc_approved? (david_williams)
neil.hauge: pmc_approved? (raghunathan.srinivasan)
neil.hauge: pmc_approved? (naci.dai)
neil.hauge: pmc_approved? (deboer)
neil.hauge: pmc_approved+
neil.hauge: pmc_approved? (kaloyan)
neil.hauge: pmc_approved? (cbridgha)
neil.hauge: review+
Target Milestone: 3.0 RC2   
Hardware: PC   
OS: Windows XP   
Whiteboard: PMC_approved
Bug Depends on: 345617    
Bug Blocks:    
Attachments:
Description Flags
patch none

Description Shaun Smith CLA 2011-04-15 10:51:51 EDT 
After creating a JAXB project with a user defined JAXB implementation library (using EclipseLink) I proceeded to attempt to compile a schema.  However since I had not (intentionally) included the necessary XJC jars in my user library schema compilation failed with an exception.

If the JAXB platform has expectations about schema compiler classes provided by the user library a library should be checked for availability.

java.lang.NoClassDefFoundError: com/sun/tools/xjc/BadCommandLineException
Caused by: java.lang.ClassNotFoundException: com.sun.tools.xjc.BadCommandLineException
	at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Exception in thread "main"
Comment 1 Neil Hauge CLA 2011-04-18 17:27:31 EDT 
Not sure that this bug needs to depend on bug 342984 but leaving for now.
Comment 2 Neil Hauge CLA 2011-04-20 11:35:56 EDT 
I think the jars missing from validation are:

com.sun.tools.xjc_*.jar
com.sun.xml.bind_*.jar
Comment 3 Neil Hauge CLA 2011-05-10 17:00:26 EDT 
After discussing with Paul it seems the best way to do this would be to have a library validation 'warning' that would suggest but not require that you add these additional jars for JAXB Class Generation.
Comment 4 Paul Fullbright CLA 2011-05-12 10:53:42 EDT 
this was partially fixed along with bug 345453, but more investigation is necessary, especially for the xjc included with the jre
Comment 5 Neil Hauge CLA 2011-05-18 16:23:19 EDT 
Our JAXB XJC related library validation that was previously added should still apply to EclipseLink JAXB platform projects, but should not apply to Generic JAXB platform projects as a result of now supporting the JDK XJC.  For Generic JAXB platform, we could leave the validation to the Class Gen wizard to minimize change, or if it is low risk and we have time, we could add similar XJC validation for Generic JAXB platform at project creation.
Comment 6 Paul Fullbright CLA 2011-05-18 18:37:19 EDT 
Created attachment 196056 [details]
patch
Comment 7 Neil Hauge CLA 2011-05-19 00:28:18 EDT 
(In reply to comment #6)
> Created attachment 196056 [details]
> patch

This patch simply ensures that when Using Eclipse JAXB, the user is warned if the necessary classes are not on the classpath.
Comment 8 Neil Hauge CLA 2011-05-19 00:31:18 EDT 
This functionality will exist at the class gen wizard level when the patch for 345617 is check in, so given that this will be redundant validation, I think it can wait for the first service release.
Comment 9 Neil Hauge CLA 2011-05-19 00:33:27 EDT 
(In reply to comment #8)
> This functionality will exist at the class gen wizard level when the patch for
> 345617 is check in, so given that this will be redundant validation, I think it
> can wait for the first service release.

Of course right after hitting submit on this comment, I realize that this patch also fixes the incorrect validation that currently exists for Generic platform.  Since this is an issue of invalid validation at this point, it makes it much more fitting for RC2, especially given the low risk of this fix.
Comment 10 Neil Hauge CLA 2011-05-19 00:36:51 EDT 
    Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. 

This patch removes an invalid library validation warning and adds the correct library validation warning.

    Is there a work-around? If so, why do you believe the work-around is insufficient? 

Workaround is to ignore the warning, and possibly misconfigure your classpath.

    How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? 

I have tested the fix, along with Paul.

    Give a brief technical overview. Who has reviewed this fix? 

This patch simply ensures that when Using Eclipse JAXB, the user is warned if
the necessary classes are not on the classpath.  It does this by checking to see if necessary classes can be found on the classpath for Schema Generation in the EclipseLink platform.

    What is the risk associated with this fix? 

Low, very isolated, boilerplate type code.
Comment 11 Neil Hauge CLA 2011-05-19 02:38:49 EDT 
Approving so this can make it into Thursday's build.  We can roll back if there are any objections from the PMC.
Comment 12 Paul Fullbright CLA 2011-05-19 02:48:14 EDT 
committed for rc2
Comment 13 Jolene Moffitt CLA 2011-06-13 14:34:09 EDT 
Verified in Build I-3.3.0RC4-20110603221533

Verified warning appears correctly if using EL platform and no warning appears if using Generic platform.  see the link to view test steps for verification.  http://wiki.eclipse.org/Dali_3.0_RC2