I've upgraded from NetBeans 8.0 to 8.0.1 via netbeans update tool.
I've also updated glassfish 4.0 to 4.1 via glassfish update tool.
I've restarted netbeans after glassfish update.
My project uses CDI and corresponding annotation javax.enterprise.context.SessionScoped
My project cannot compile in NetBeans. apparently this interface has been moved to cdi-api.jar which is not listed under glassfish libraries.
I've even created new javaee project in NetBeans and the problem retains.
The problem is solved by manually adding cdi-api.jar to the project.
it's not hard to workround.
libraries shown as server libraries are handled by serverplugins in my opinion.
I do not understand how NetBeans builds it's Server-Side Library set. I have grep through the entirety of the directories for both netbeans and glassfish for the occurrence of a name of a .jar that I know that netbeans did find. Nothing except the jar file itself.
The cdi-api.jar is not missing, it is located in the glassfish/modules directory for Glassfish 4.1. This library clearly has the required javax.enterprise.context.
However, curious thing is that for Glassfish 4.0, the same javax.enterprise.context package is under weld-osgi-bundle.jar, and not under cdi-api.jar.
In Glassfish 4.1, javax.enterprise.context has effectively been removed from weld-osgi-bundle.jar and moved into cdi-api.jar instead.
So again, I do not understand where netbeans learns the required libraries to use during the compile phase (and includes them in the server libraries). Is this a hardcoded feature? I hoped this was somehow a matter of configuration, or autodiscovery, so we can fix without waiting for a patch.
(In reply to jdesmet from comment #2)
> I do not understand how NetBeans builds it's Server-Side Library set. I have
> grep through the entirety of the directories for both netbeans and glassfish
> for the occurrence of a name of a .jar that I know that netbeans did find.
> Nothing except the jar file itself.
With this I meant grep'ing the binary installation on my pc. Not the code base.
> The cdi-api.jar is not missing, it is located in the glassfish/modules
> directory for Glassfish 4.1. This library clearly has the required
cdi-api.jar is not missing in the modules directory - but is missing from the GUI.
> In Glassfish 4.1, javax.enterprise.context has effectively been removed from
> weld-osgi-bundle.jar and moved into cdi-api.jar instead.
That seems in short why the packages could not be found.
I think this is some how hardcoded using the ServerLibraryImplementation specific to glassfish. Cannot find the sources - and not sure how to fix.
*** Bug 247709 has been marked as a duplicate of this bug. ***
The problem also occurs in Windows 7 64-bit with JDK 1.8.0_25.
cdi-api-fragment.jar should be considered?
main nb code
but it use internally some
And therefore it may be gf issue however it's nice to workaround it on nb side in this case.
There may be some more places where extra jars can be handled without org.glassfish, for example JavaEEServerModuleFactory
Unfortunately it's not my area, and I'm not able to fix it fast yet, but may look a bit more
>TBD, should be shown as unevaluated for owner
I would also like to know how NetBeans determines the server-side libraries to include in a Java EE project. If someone finds that out it would be nice to have a reference in case this problem crops up in the future.
I too used the workaround described in the problem Description. However, I unchecked the Package checkbox in the NetBeans Project's Libraries list for cdi-api.jar, since I know it will be found in the execution environment and therefore doesn't need to be included in the .war.
*** Bug 250293 has been marked as a duplicate of this bug. ***
This seems to be missing GF 4.1 config modification in GF Tooling module. Adding it with CDI jar included.
...and how NetBeans finds server-side libraries to include in a Java EE project? This was rewritten from scratch in 7.4 to remove Java hard-coded classes from plugin and new XML config files were added into GF Toolign library.
You can find this in org.netbeans.modules.glassfish.tooling.server.config inside GlassFish Tooling module.
GF Version to XML mapping is in ConfigBuilderProvider:
* plugin's server configuration is defined in individual XML files, e.g. GlassFishV3.xml, GlassFishV4.xml
* individual XML to configuration mappings are in CONFIG_V3 (initial), CONFIG_V4 and CONFIG_V4_1 static fields.
* config discovery sequence is defined in Config config static field
And how it works? Just imagine some sequence of GF versions like
3.0 3.0.1 3.1 3.1.1 3.2 4.0 4.0.1 4.1 4.1.1
This discovery sequence defines versions since which new GF configuration XML is applied. With current setup
* 3.0 3.0.1 3.1 3.1.1 3.2 are mapped to plugin's server configuration stored in GlassFishV3.xml
* 4.0 4.0.1 are mapped to configuration stored in GlassFishV4.xml
* 4.1 4.1.1 and following versions (until new XML/Config.Next is added) are mapped to GlassFishV4_1.xml
All 'used' (e.g you have GF server rof matching version egistered) plugin's server configurations are loaded and cached.
Created attachment 152572 [details]
Added plugin's config for GlassFish 4.1 with cdi-api.jar
Created attachment 152679 [details]
Pushed into web-main:
user: Tomas Kraus <TomasKraus@netbeans.org>
date: Thu Mar 12 11:03:48 2015 +0100
summary: Bug# 247013 - cdi-api.jar is missing from glassfish 4.1 libraries
Hi Thomas. When will this fix be released? It's end of April, almost May, and my IDE still has this issue. Will this be rolled out as a patch? When?
I'm not working with NetBeans team for almost two years so I don't know much about current release schedule. :(
Huh. Wow, that's odd since your user id pushed a change on March 18 2015. So who is in charge of this ticket?
It's assigned to me so it's still me. :) Petr Hejl <email@example.com> is currently working on GF plugin. He may know current release schedule. I'll keep fixing some of the issues from time to time when I have some free time. :)
Alternatively you ca try the dev build.