Open lprimak opened 1 year ago
Hello @lprimak,
Thank you for raising this issue. Is there a reason why you are trying to load the libraries using the --libraries
flag rather than using the ./asadmin add-library
command? I will come back after I test the reproducer.
Best regards, Felix
Hi, Felix,
Actually add-library
is irrelevant to the problem. The issue exists whether the libraries are in <domain>/lib
or <domain>/applib
, using add-library
, --libraries
or not, it doesn't matter.
Easiest test case is just to put a CDI library into <domain>/lib
and try that. CDI artifacts aren't loaded no matter how the library gets into the domain.
Thank you!
Greetings, It's been more than 5 days since we requested more information or an update from you on the details of this issue. Could you provide an update soon, please? We're afraid that if we do not receive an update, we'll have to close this issue due to inactivity.
Hello @lprimak,
Please ignore the automation. Apologies for not coming back earlier, other internal projects kept me from replying, I had a look at the reproducer, and in order for me to assess what went wrong, I would need more information: do I require any additional configuration besides an empty Postgres database and the data source?
The project is also targeted at Java 21. We do not officially support Java 21 on Payara 6 Community Edition, only Java 17 and 11. We plan on adding support for Java 21 in the future, but we do not officially support the platform yet. So if you could provide me with a reproducer targeting Java 17 or 11 and explain the additional configuration steps on the server side, I could raise the issue with the Platform Development team.
Ok, I’ll create a branch
Just FYI the target doesn’t really make a difference but I do get the need tor an easier reproducer. I’ll get something going
Hi, Felix,
I have created a much simpler reproducer and re-worked the issue description above. Please take a look, it should be true http://sscce.org so you can easily see the issue.
Thank for your patience!
Greetings, It's been more than 5 days since we requested more information or an update from you on the details of this issue. Could you provide an update soon, please? We're afraid that if we do not receive an update, we'll have to close this issue due to inactivity.
Greetings, It's been more than 5 days since this issue was identified as abandoned. We have closed this issue due to inactivity, please feel free to re-open it if you have more information to share.
Not abandoned. I can't even reopen the issue :(
Hello @lprimak,
Apologies for the automation closing the issue before it was done. I will have a look at the reproducer today and come back with an update
Hello @lprimak,
I have finished looking through the reproducer. I had to add a couple of things (namely the compile and source Java version, 11 in my case) and the maven-war-plugin
with the property failOnMissingWebXml
set to false
.
In the case of-Dskinny.war=true
, I can see the error that you are describing, the app is not even being able to be deployed.
In the case of-Dskinny.war=false
, it works as expected.
Overall, your use case should be supported, as adding the library to the <domain_dir>/lib
should be enough. I even tried <domain_dir>/lib/ext
, with no success. I raised an internal issue with the internal reference FISH-7871
, for the Platform Development team to investigate and fix the bug.
Thank you very much for the contribution and for the easy-to-follow reproducer!
Best regards, Felix
Thank you Felix. BTW your maven must be ancient for you to need to add anything. If you upgrade to latest maven it should work out of the box.
Hello @lprimak, no problem!
I am using Maven 3.8.6. So probably a year out of date, but you made me curious, so I will update my Maven and try it again with no modifications.
Thank you again for the many contributions you have made to our platform!
Kind regards, Felix
Brief Summary
Trying to create a layered payara domain and thin WARs by putting many large libraries into domain/lib or domain/applib and using
asadmin deploy --libraries lib1.jar,lib2.jar xxx.war
When libraries contain CDI artifacts, they are not loaded, nor are they scanned by the Payara deployment processWhy do this?
Class loading takes a lot of time during application deployment. In order to speed up deployment during development process, large application dependency JARs can be put into Payara
<domain>/lib
directory. This prevents class-loading of dependencies during deployment more than once, and can speed up development time by orders of magnitude, and improves developer experience.Expected Outcome
CDI beans are loaded from applib/ or lib/ in the domain The following message should print in the Payara
server.log
:Current Outcome
CDI beans are not loaded and application cannot be deployed Error Message:
Full exception:
Reproducer
https://github.com/flowlogix/cdi-scanning
The reproducer contains a library and an app that uses it (Greeter/GreeterApp)
To reproduce the failure: Inside the
cdi-scanning
directory:mvn package
- generates a 'skinny' WAR without the library insidelibrary/target/library-1.x-SNAPSHOT.jar
to<domain_dir>/lib
directory (or useasadmin add-library
, but this is irrelevantasadmin deploy app/target/app-1.x-SNAPSHOT.war
To get a working application, using standard WAR method: Inside the
cdi-scanning
directory:Operating System
Any
JDK Version
Any
Payara Distribution
Payara Server Full Profile, Payara Server Web Profile (version 2023.9)