Native: Parsing Error #30
Comments
|
Interesting because the MyFaces Quarkus Extension already has this...and it was working for the previous rev? <!-- EL implementation -->
<dependency>
<groupId>org.apache.tomcat</groupId>
<artifactId>tomcat-jasper-el</artifactId>
<version>11.0.0-M1</version>
</dependency> |
|
See this: |
|
My GitHub Actions does a native build of a PrimeFaces app every time I commit and you can see the Native build worked here: https://github.com/quarkiverse/quarkus-primefaces/actions/runs/4568837815/jobs/8064383108 |
|
So, I jumped over the the quarkus-faces project as I'm mostly modeling my setup versus that project and ran: I excluded org.apache.tomcat:tomcat-el-api from the org.apache.myfaces.core.extension.quarkus:myfaces-quarkus Then I reran the dependency check to verify that the tomcat-el-api was being in fact excluded and reran the native build That project built fine -- which I didn't expect -- and that led me to believe that the reason it was building fine was that the jakarta.el-api lib was picked up and available via the quarkus-hibernate-validator dependency which transitively pulls in expressly which in turn pulls in jakarta.el-api 5.0.1. I had NOT been adding myfaces-quarkus to my own project as it is included in both quarkus-primefaces and quarkus-omnifaces and it isn't listed on the code.quarkus.io so I figured it wasn't critical. Still, adding myfaces-quarkus did not resolve the parser error for me but adding jakarta.el-api did. So, I kind of reached the conclusion that jakarta.el-api was what was really needed here in this project; quarkus-primefaces. And, might be needed in quarkus-omnifaces, too??? Now, here in the quarkus-primefaces which I didn't build yet but did try to run a dependency:tree both libraries show up often: But, as in the earlier dependency:tree run, jakarta.el-api doesn't seem to be included with quarkus-primefaces over at sonatype. Did I hunt that down the right way? I know I got to my conclusion in a sort of a round about way. And, at the moment, I'm not 100% sure I reached the right conclusion even at that as my guess would have been that tomcat-el-api being included would have gotten the job done. So, maybe tomcat-el-api is what really needs a look? What do you think? |
|
When I run |
|
My guess is that the Quarkus Faces project would not build if it was not importing quarkus-hibernate-validator which contains the transitive jakarta.el-api and would throw "unresolved method during parsing: jakarta.el.ELResolver" ?? |
|
I think you need that though because Native is going To find a whole bunch of javax validation classes it's going to say are missing. So not sure why you are not including hibernate validator?? That is the whole jakarta bean validation package. |
|
Mostly kicking out reports and charts from sql views almost no user input
on this service. Sort of a micro-ui.
On anything bigger I probably wouldn't have noticed. EL was a head
scratcher there for a minute.
…On Fri, Mar 31, 2023 at 10:13 AM Melloware ***@***.***> wrote:
I think you need that though because Native is gong. To find a whole bunch
of javax validation classes it's going to say are missing. So not sure why
you are not including hibernate validator??
—
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUGXHUQU7D525TSBCZ2HSDW637A5ANCNFSM6AAAAAAWNVWMNM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
OK added to the pom.xml no harm in me adding it here. |
|
If this is really a once in a blue moon kind of a thing a DNF or Won't Fix is not the end of the world AT ALL. |
|
Interesting check this out I am getting a native build failure now on GitHub Actions: https://github.com/quarkiverse/quarkus-primefaces/actions/runs/4577321096/jobs/8082584255 |
|
Can you pull that dependency back out?
…On Fri, Mar 31, 2023 at 11:05 AM Melloware ***@***.***> wrote:
Interesting check this out I am getting a native build failure now on
GitHub Actions:
https://github.com/quarkiverse/quarkus-primefaces/actions/runs/4577321096/jobs/8082584255
—
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABUGXHW7VYDBQHLEQWWLAJ3W64FFLANCNFSM6AAAAAAWNVWMNM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Yep I reversed it I just can't explain why that break it when you said it solves your issue. |
|
I simplified my current project/module (micro ui that doesn't include validators) and the module again compiles down to native -- no parser errors. So, a step forward. But, as soon as I get a successful native package I'm again getting "Warning: Could not resolve java.xxx for reflection Reason" Now, I kind of expected to require adding some @RegisterForReflection decorations to my own classes but I didn't think these for " java" and jakarta .faces classes wold be something I'd see so scratching my head on that. So, a step backward.
Actually, to the point of thinking my dev station was setup oddly wrong for some reason so I fired up a vanilla vm, setup a fresh debian/openjdk environment and seeing the strange warnings there, too. So, just tried a couple of other projects where the aim is to flip some traditional wars to quarkus where primefaces is one of the maven submodules and kind of the same thing. First round after bumping to 3.0.0 CR1. All is fine in regular packaging. Things run quite well. As soon as try to package native I'm chasing jar/lib conflicts that kind of don't make sense at first look like - especially after this discussion her on this issue, and #32 and #31. All good -- and actually quite snappy btw -- until I try to package native. I was going to joke that I got caught in jar hell Friday but now I'm not sure which hell I'm in? :) I've got a lot of these projects and over time I got very disciplined about my "dependencyManagement" configuration it it's relationship to the sub-modules. I haven't visited jar hell in a long long loooong time. My guess is probably not jar hell but more of a "I just hit a steeper part of my grallvm learning curve." For instance, not related to this but similar experience, I ran into a self inflicted wound on a misplaced decoration that was in the wrong place for a sub-module where the service was interacting with the db. Never got an error in Quarkus 2.x. Then in getting ready for the upgrade to Quarkus 3 I got errors and I blew a few days trying to understand what graalvm was telling me until a kind soul over at Quarkus threw me a little help here quarkusio/quarkus#32188 (comment) and here quarkusio/quarkus#32298. In the new week, probably later in the week, I think I'm going to carve out some time to try create a new mulit-module project with a single ui module and connect it to a single service module and try to zero in. If I can get a reliable failure I'll create a reproducer. Thank you so much @melloware for your patience and have a great weekend! |
|
Yep let me know. I am more than happy to tweak GraalVm settings in PF, OmniFaces, MyFaces if we find stuff missing but minimal reproducers definitely help! I have always been using QuarkusFaces since its a worst case scenario "uses everything". |
When trying to compile using native profile I'm getting a parser error. Adding the jakarta-el dependency resolves the issue:
That seems to be the most current version over at maven but not sure if there is a newer version related to Jakarta EE 10. This "might" be a leftover from version 9.
Anyway, could this dependency be added directly to quarkus-primefaces?
Parsing error thrown without this jar is:
The text was updated successfully, but these errors were encountered: