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.
GF v3 adds/modifies a few annotations that are already defined (but old) in a pure regular JDK 6. Without starting GF, if I use these new annotations in my Nb project source code, NetBeans flags a red icon in the editor For example, in a web app targetting gf v3, create a class like: import javax.annotation.sql.DataSourceDefinition; import javax.annotation.Resource; @DataSourceDefinition(className="foo", name = "new annotation") public class NewClass { @Resource (lookup="new attribute for GF from the endorsed dir") String foo; } This works for javax.annotation.sql.DataSourceDefinition ( a new annotation, and on the classpath provided by GlassFish v3 plugin) but fails for @Resource (lookup="new attribute for GF from the endorsed dir") String foo; since lookup is a new attribute only defined by the GF javax.annotation.jar jar and not in the JDK 1.6 used by NetBeans IDE. Half of a workaround is to define -Xbootclasspath/p:${j2ee.platform.classpath} in the project properties/compling section (so a clean build of the project passes) , but I still see the editor red x. I guess then compile on save does not work either?
The -Xbootclasspath/p:${j2ee.platform.classpath} option does not help to the java support as it's only the runtime argument and java support doesn't know about it. I will try to find another way how to do it.
Thanks in advance, Tomas!
Increasing priority to resolve this rather earlier than late.
The issue has two parts: 1) The editor errors 2) The build process The workaround for the first problem is to create an explicit platform and add the path to endorsed jars into sun.boot.class.path property of the platform definition file. The workaround of the second problem was described by Ludo. The fix has also 2 parts: 1) The editor part can be solved by extending the ClassPathSupportFactory.createBootClassPathImplementation to take the endorsed jars which will be prepended to boot cp. I can do the API change to allow it. The web project will need to use this extended method. 2) The build part needs a change of build script to prepend the endorsed jars to boot cp.
David, if you want such a fix, let me know I will fill the API change for the ClassPathSupportFactory.
There are also related issues 173426 and 173428: for JAX-WS, we already (sort of) handle the build aspect, but not the parser/editor aspect.
Thanks Tomas, I transferred your proposal to following wiki page for further discussion and tuning: http://wiki.netbeans.org/EndorsedLibrariesHandling At this stage it is still just evaluation and then we can decide
At this stage it is still just evaluation and then we can decide whether we want to go ahead and implement it or not. Feel free to update it and add problems, questions, suggestions as needed.
See also another but similar issue 173461.
> Half of a workaround is to define -Xbootclasspath/p:${j2ee.platform.classpath} in the project properties/compling Isn't there a cleaner solution, for build process(Problem 2), to specify endorsed directory rather than -Xbootclasspath ? For Example: -Djava.endorsed.dirs=GlassFish_home/glassfish/modules/endorsed IMHO, we should use the recommended endorsed mechanism rather then hack with -Xbootclasspath See:http://java.sun.com/j2se/1.5.0/docs/guide/standards/ As a 3-party module developer I'd appreciate to specify the list of folders, needed by my module, that will be added to list of project's endorsed folders. Then, I'd expect the project infrastructure will care about the rest: - jar files from "endorsed" folders will be added to project boot class path (Problem 1) - folders will be added to "-init-macrodef-javac" target (build-impl.xml) to "-Djava.endorsed.dirs" compiler option. (Problem 2)
Another side effect of this bug is that when you explore the glassfish jar (modules/endorsed/javax.annotations.jar )(via favorites tab for example) in the NetBeans explorer, you do not see a node for the "lookup" attribute in the NetBeans java navigator view.... So it seems that this navigator view is taking its model from the jdk classes, not from the explored jar... That would be another (different?) bug
Yes Ludo that would be another bug. Not sure which component though. java? jar? ...
Thinking about the issue, it would be good to have something like "endorsed" section in project customizer where both users and 3-party modules(programatically) could add folders. The project infrastructure could handle those folders(and jars within the folders) to extend (boot)classpath and project build script.
>Yes Ludo that would be another bug. Not sure which component though. java? jar? ... No, this is the same issue. The project provided wrong boot classpath, fixing the boot cp problem also resolves this.
I vote for Milan's suggestion (customizer maybe property without UI for endorsed dirs) and API for allowing 3rd parties to extend it. This would work fine with my suggestion (boot cp extension).
re. UI - ok, do you guys mean adding a simple single line edit box to "Compiling" category just above "Additional Compiler Options" labelled "Endorsed Libraries"? Sounds simple enough to do. We would have to ask for UI review as we are in UI freeze. re. API - Tomas, when you say "API for allowing 3rd parties to extend it" do you agree to use existing ClassPath API with a dedicated classpath type or are you suggesting we should create a new dedicated API?
Created attachment 88870 [details] proof of concept
Attached is proof of concept patch. It is quite straightforward and relatively small change. The patch contains: * API changes * web project build script changes * web project sharability support changes I tested it on Ludo's example or on Web Services example and it works well - after adding following lines to project.properties: endorsed.classpath=/home/david/GlassFish_v3/glassfish/modules/endorsed/javax.annotation.jar editor stops marking lines as erroneous, project compilation works and Make Project Sharable wizard shows javax.annotation.jar correctly. 3rd party modules could modify endorsed classpath via existing ProjectClassPathModifier.[add|remove]Libraries(Library[], aJavaSourceFile, ClassPathSupport.ENDORSED_CLASSPATH) or retrieve it via ClassPath.getClassPath(aJavaSourceFile, ClassPathSupport.ENDORSED_CLASSPATH). Any suggestions, comments? Tomas, java.api.common is Friend API contract so a quick way to proceed with this change would be for you to review my patch and if you think it is non-controversial then that would be the API review and I would just commit the changes (after updating api changes, @since, etc.). Or if you prefer to go via FAST TRACK review on apireviews mailing list then go ahead and do API change yourself. Thanks. One more thing which remains to be done is to transplant the fix to J2SE and other J2EE project types. I'm happy to do that. Re. UI - it would be actually much easier and better to just reuse existing classpath customizer UI (a list with buttons Up/Down/Add...) because it present classpath items to user in a way they are used to. With single edit box line the problem will be that user may end up seeing in customizer values like "${file.reference.javax.annotation.jar}:${libs.ws-something.classpath}".
*** Issue 173461 has been marked as a duplicate of this issue. ***
Why the BootClassPath takes an endorsedClassPath as a ClassPath? Isn't better to take it as a name of property (similar to other). Also it may be faster than delegating to cp. Otherwise OK.
Regarding the UI, I am thinking whether this should be somehow more hidden. This is an expert setting, so would't it be better to put it on an "advanced" button, rather than as another tab in the Libraries section?
I have to correct my claim that -Djava.endorsed.dirs is better than -Xbootclasspath/p. The first one is better for directories, the second for list of jars. Sorry for that. Looks we have all we need. Do we need something to do in shareable case? Example (project is shareable) - we create JAX-WS_ENDORSED library from jar files located at nb_home/java3/modules/ext/jaxws21/api - use addLibraries(...) to add JAX-WS_ENDORSED lib - are those jars copied to project_home/lib automatically ? BTW, where's the Make Project Shareable wizard ?
re. "Why the BootClassPath takes an endorsedClassPath as a ClassPath" - if I used property name instead of ClassPath then I will need to pass to BootClassPathImplementation also project folder in order to resolve possibly project relative paths in endorsed classpath. I tried to rewrite it the way you suggested but unless I'm missing some helper methods somewhere it is more code in BootClassPathImplementation and benefit is probably not be worth it. Let me know if you have some other idea how to do it and I will change the code - for now I'm going ahead with current ClassPath based impl. re. "UI" - until we agree on some UI I'm going to implement this without a UI. UI can be always added later if really needed. re. "are those jars copied to project_home/lib automatically" - yes re. "where's the Make Project Shareable wizard" - if project is not sharable then open project properties and in Libraries category try to set Sharable Libraries folder. That will start Make Project Sharable wizard.
Fixed in all project types - c572a09321c0 Ludo, at the moment you can add to your project.properties or private.properties: endorsed.classpath=/your/path/to/GlassFish_v3/glassfish/modules/endorsed/javax.annotation.jar and editor and compiler will work. Now, I was about to file a separate issue to enhance Deployment API to allow server plugins to provide endorsed libraries but I wonder whether better solution would be for JEE project types which target EE6 to do that automatically. What's the point of forcing each server plugin to provide endorsed JARs when it is EE6 spec requirement? So the solution I would prefer is to add a new NetBeans library (named eg. "EE6 Endorsed APIs") and when a project is created for EE6 server (web or full or both?) it will automatically place that library on newly introduced ENDORSED classpath. What do you think Ludo? Or anybody else? PetrH?
re. "UI" I'd vote for some UI for endorsed jars. 1. we have users that use endorsed mechanism. See for example issue 173892. Endorsed mechanism and it's quite often recommended in WS documentation 2. AFAIK, the content of nbproject is not designated for user modification 3. Though, there is a JDK way to put jars to jre/lib/endorsed directory, it's not recommended as it may cause unpredictable behaviour of another applications. So it's preferable to configure endorsed mechanism on project site.
>if I used property name instead of ClassPath then I will need to pass to BootClassPathImplementation also project folder in order to resolve possibly project relative paths in endorsed classpath The AntProjectHelper.resolveFileObject() should be enough, you can add the (AntProjectHelper to BootCP). Anyway it is not TCR, take it as TCA.
While java.api.common is a reasonable place for the new ENDORSED constant in 6.8, assuming this approach works the constant should be moved to an official API for a subsequent release.
>I would prefer is to add a new NetBeans library (named eg. "EE6 Endorsed APIs") and when a project is created for EE6 server I'd appreciate that. Nevertheless, Except of javax.annotation.jar we need also webservices-api-osgi.jar and jaxb-api-osgi.jar.
Integrated into 'main-golden', will be available in build *200910091401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/c572a09321c0 User: David Konecny <dkonecny@netbeans.org> Log: #172952 - now way to use classes from GF endorsed/ dir
"JavaEE 6.0 Endorsed API Library" library added; J2EE project types put this library on ENDORSED classpath if project spec version is EE6. 668a2a738132 Jesse - yes. Ludo - webservices-api-osgi.jar does not have a license. Could you fix that please? Milan - you will have to check/update ENDORSED classpath of J2SE project from WS support. Also please clean up "javac.compilerargs.jaxws" from J2EE project types - it should not be needed now, right?
Trying to use: ProjectClassPathModifier.addLibraries(Library[], aJavaSourceFile, ClassPathSupport.ENDORSED_CLASSPATH) get the exception: SEVERE: Project in /space/home/mkuchtiak/NetBeansProjects/JavaApplication2 of class org.netbeans.modules.java.j2seproject.J2SEProject has a ProjectClassPathModifierImplementation but it will not handle classpath/endorsed for /space/home/mkuchtiak/NetBeansProjects/JavaApplication2/src java.lang.UnsupportedOperationException: Project in /space/home/mkuchtiak/NetBeansProjects/JavaApplication2 of class org.netbeans.modules.java.j2seproject.J2SEProject has a ProjectClassPathModifierImplementation but it will not handle classpath/endorsed for /space/home/mkuchtiak/NetBeansProjects/JavaApplication2/src at org.netbeans.api.java.project.classpath.ProjectClassPathModifier.findExtensible(ProjectClassPathModifier.java:381) at org.netbeans.api.java.project.classpath.ProjectClassPathModifier.addLibraries(ProjectClassPathModifier.java:88)
Endorsed classpath type was missing in the list of extensible classpath types - fixed in f26791552b34. Next time please file a new defect issues instead of reopening this one. Thanks.
<rant> why do I need Ludo to tell me about the same problem in maven projects? Is Maven still only the weird stuff mkleint is doing? </rant>
Maybe reading the (java) projects api changes is enough.
Integrated into 'main-golden', will be available in build *200910140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/668a2a738132 User: David Konecny <dkonecny@netbeans.org> Log: #172952 - now way to use classes from GF endorsed/ dir
Integrated into 'main-golden', will be available in build *200910141401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f26791552b34 User: David Konecny <dkonecny@netbeans.org> Log: #172952 - ENDORSED classpath was not listed in ExtensibleClassPathTypes
reopening and reassigning to maven to keep track of the changes there..
There is one other problem with this related to Javadoc; I opened a separate issue 174677 for it.
http://fisheye.codehaus.org/changelog/mojo/?cs=10953 partially solves the problem on the maven build side of things. MacOSX needs to be better supported though.
updated version with Ludo's new endorsed api jar and in a profile that should work on all platforms with sun's jdk (and on mac as well) http://fisheye.codehaus.org/changelog/mojo/?cs=10993
Integrated into 'main-golden', will be available in build *200910300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/30acd598ff60 User: Milos Kleint <mkleint@netbeans.org> Log: #172952 first stub for endoresed cp. not really working yet.
Integrated into 'main-golden', will be available in build *200911041401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/0d5105142ba9 User: Milos Kleint <mkleint@netbeans.org> Log: #172952 second stub for endoresed cp.
maven support's Boot ClassPath and Endorsed ClassPath finalized in changeset ending with this one: http://hg.netbeans.org/core-main/rev/227528c6f76c it works with default archetypes we have ship for javaee6. Or anything else that uses the same patterns, alternate setups are possible in maven, but currently not supported. No ClassPathModifier support, it's too complicated to edit and do it right. consider it fixed now