Native: Parsing Error about quarkus-primefaces

[gesker]

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.
Like you pointed out it is probably very unlikely that most won't have validators in place.
In any event... Thank you, Sir @melloware!

[melloware]

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".

[melloware]

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>

[melloware]

See this:

[melloware]

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

[gesker]

So, I jumped over the the quarkus-faces project as I'm mostly modeling my setup versus that project and ran:

❯ mvn dependency:tree | grep el-api
[INFO] |  |  \- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M1:compile

I excluded org.apache.tomcat:tomcat-el-api from the org.apache.myfaces.core.extension.quarkus:myfaces-quarkus

        <dependency>
            <groupId>org.apache.myfaces.core.extensions.quarkus</groupId>
            <artifactId>myfaces-quarkus</artifactId>
            <version>${myfaces.version}</version>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.tomcat</groupId>
                    <artifactId>tomcat-el-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Then I reran the dependency check to verify that the tomcat-el-api was being in fact excluded and reran the native build

❯ mvn dependency:tree | grep el-api
[INFO] |  |  \- jakarta.el:jakarta.el-api:jar:5.0.1:compile
❯ mvn clean compile package -Pnative 

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:

❯  mvn dependency:tree | grep el-api;
[INFO] |  |  |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO] |  |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO]    |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO] |  |  |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO] |  |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO]    |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile
[INFO] |  |  |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |     |  +- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile

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?

[melloware]

When I run mvn dependency:tree | grep el-api on my Quarkus Faces project I get this...

[INFO] |  |  \- jakarta.el:jakarta.el-api:jar:5.0.1:compile
[INFO] |  |  \- org.apache.tomcat:tomcat-el-api:jar:11.0.0-M3:compile

[gesker]

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" ??

[melloware]

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.

[gesker]

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: ***@***.***>

[melloware]

OK added to the pom.xml no harm in me adding it here.

[melloware]

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

[gesker]

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: ***@***.***>

[melloware]

Yep I reversed it I just can't explain why that break it when you said it solves your issue.

[gesker]

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!