JakartaEE Auto complete of @Named Managed Beans not working in Netbeans 14 #4338
Comments
bercolax
added
kind:bug
|
same problem. NB 13 and 14 if you hard code el link in it works fine, but will not display. Using Payara Community server, followed their Jakarta EE 9 tutorial where the same el worked perfectly on IntelliJ platform. If you just import Javax.inject.Name it displays correctly in NB. |
|
I guess in the NB plugin must do a Search javax and replace with jakarta and publish this as an add on plugin for those who want to work with Jakarta EE 9 onwards. |
|
I can still reproduce this issue with NetBeans 15 and 16-rc1. |
|
Same here, I tried it last night with the Jakarta 9.1 compatible Glassfish
Server.
Still no luck!
…On Sat, 22 Oct 2022, 6:13 am Javier Llorente, ***@***.***> wrote:
I can still reproduce this issue with NetBeans 15 and 16-rc1.
—
Reply to this email directly, view it on GitHub
<#4338 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANAJPVJWKM2KGA64UYYMAQ3WELTNFANCNFSM52YNK3CQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Incase we can get involved and help, kindly let me know. Will be happy to get involved. We can have two jars for related plugin. Users working with the jakartaee packages can uninstall the javax.xxx plugin and install the jakartaee.xxx plugin.
|
|
Can any one please tell if this has been fixed in Netbeans 16? (released on Nov 30, 2022) |
|
Cdi beans annotated with jakarta.inject.Named stil not detected in NetBeans 16 In a maven web application with jakartaee 9.1 and facelets when try auto complete in #{} expression are till proposed beans with javax namespace instead of jakarta namespace e.g. javax.servlet.http.httpsession
|
|
I had done some work on this issue earlier this year but the PR was not submitted in time for release. I need to perform a diff against the latest code and my working branch to try and determine what is still causing this issue. Will try to get this done soon. Sorry for the delay. |
|
Ok, thanks for the update.
…On Mon, 12 Dec 2022, 12:22 pm Josh Juneau, ***@***.***> wrote:
I had done some work on this issue earlier this year but the PR was not
submitted in time for release. I need to perform a diff against the latest
code and my working branch to try and determine what is still causing this
issue. Will try to get this done soon. Sorry for the delay.
—
Reply to this email directly, view it on GitHub
<#4338 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANAJPVJLSZXVMNPCS7ERP3LWMZ44LANCNFSM52YNK3CQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thanks for the reply and the update. |
|
hello, I have the same problem (cannot detect CDI beans in xhtml files ). i'm using Netbeans 14 and jakartaEE 10 with the compatible eclipse glassfish server. |
Now i have downloaded Netbeans 17 and the problem is still there. |
|
Hi, the only way I have been able to use autocompletions in jsp is by adding the javax.servlet-api library with java 11. |
|
in netbeans 17 and jdk 20, autocomplete does not work between <%%> in jsp file, please help |
|
Unfortunately it was not possible to solve this problem I am using 17 without success the problem is that this is an essential tool for development making programming much easier did anyone succeed? |
|
This is the same as issue #4035. I currently have a PR to repair that issue in progress. |
|
Still have this issue. MacOsx , Windows, Linux Netpeans 14, 16, 17. |
|
@bercolax @apapamarkou @grantleyT @menny68 Should be fixed in NetBeans 18. Would be nice if someone could double check so that we can close the issue. |
|
Issue is still present for me in 18, no named beans discovered, no EL auto-completion in projects that use JakartaEE. |
Previously NetBeans bundles the JSF reference implementation Mojarra in order to provide several functionality (like namespaces) based on the parsed taglib xml files from that jar. This is somehow problematic as: 1) The dependency needs to be updated on every new JSF release 2) NetBeans needs to fulfil the expectations of Mojarra This leads to the problem that we currently cannot update and bundle the latest Mojarra version as Java 11 is required. This change wants to get less dependant on that bundled JSF implementation by resolving the reference implementation using maven. Instead of reading the taglib xml files from that bundled jar NetBeans now gets in from the local maven repository or downloads it from maven central. If this is not possible we fallback to the bundled version. This change also improves the situation when autosuggestion is invoked in the namespace part of JSF xhtml documents by ordering the suggested namespace with the one on top which is most likely to be used. This should fix apache#6069 apache#5470 apache#5470 apache#4338
Previously NetBeans bundles the JSF reference implementation Mojarra in order to provide several functionality (like namespaces) based on the parsed taglib xml files from that jar. This is somehow problematic as: 1) The dependency needs to be updated on every new JSF release 2) NetBeans needs to fulfil the expectations of Mojarra This leads to the problem that we currently cannot update and bundle the latest Mojarra version as Java 11 is required. This change wants to get less dependant on that bundled JSF implementation by resolving the reference implementation using maven. Instead of reading the taglib xml files from that bundled jar NetBeans now gets in from the local maven repository or downloads it from maven central. If this is not possible we fallback to the bundled version. This change also improves the situation when autosuggestion is invoked in the namespace part of JSF xhtml documents by ordering the suggested namespace with the one on top which is most likely to be used. This should fix apache#6069 apache#5470 apache#5470 apache#4338
Previously NetBeans bundles the JSF reference implementation Mojarra in order to provide several functionality (like namespaces) based on the parsed taglib xml files from that jar. This is somehow problematic as: 1) The dependency needs to be updated on every new JSF release 2) NetBeans needs to fulfil the expectations of Mojarra This leads to the problem that we currently cannot update and bundle the latest Mojarra version as Java 11 is required. This change wants to get less dependant on that bundled JSF implementation by resolving the reference implementation using maven. Instead of reading the taglib xml files from that bundled jar NetBeans now gets in from the local maven repository or downloads it from maven central. If this is not possible we fallback to the bundled version. This change also improves the situation when autosuggestion is invoked in the namespace part of JSF xhtml documents by ordering the suggested namespace with the one on top which is most likely to be used. This should fix apache#6069 apache#5470 apache#5470 apache#4338
|
Fixed with #6160 |
|
Installed Netbeans 19 and verified that the issue has been fixed. Thanks a lot. |
Apache NetBeans version
Apache NetBeans 14
What happened
I have created a Maven built JakartaEE 9 web application in Netbeans 14. Other things are working fine. But in the JSF page, I am not able to see the EL auto complete displaying the list of @nAmed beans. As the packages have been renamed jakarta (replacing javax), may be the changes must be done in the related modules to list the @jakarta.inject.Named annotated Java classes in the EL autocomplete.
The navigation from the EL in the JSF page to the Java source code of the jakarta.inject.Named annotated Java classes is also not happening.
How to reproduce
Did this work correctly in an earlier version?
No
Operating System
Ubuntu 20+, Windows 11
JDK
JDK 11
Apache NetBeans packaging
Apache NetBeans provided installer
Anything else
Every time
Are you willing to submit a pull request?
No
Code of Conduct
Yes
The text was updated successfully, but these errors were encountered: