As of Payara version 5.2021.7 I can deploy my application automatically in docker on container start but it errors with Invalid ejb jar [my application]: it contains zero ejb.
However, I can log into the UI and deploy the application manually without any errors.
I'm pretty new to the java/payara world. Does anyone know why deploying it automatically requires an .ejb file but doing it manually doesn't?
The solution was to have the war file in the top level deployment directory ($DEPLOY_DIR) instead of having it nested inside another folder.
Related
We extensively use Java ServiceLoaders as a plugin infrastructure for our application components. We define interfaces, and then use the loader to load them at run time. Adding additional jars with extensions and service files are fine for our use cases.
However, i'm struggling to understand how we would be able to continue this approach while deploying an application within Wildfly. The intent is as stated above, the ability to add "extension" jars to the web-application class path without having to
Stop the server
Unzip the war
Add additional jar
Zip war
Start the server
In Tomcat, we could deploy web application folders instead of a war. So stopping the server, dropping in a jar, and starting the server worked fine. Within Wildfly (latest), it appears to not like the deployment of a folder vs war.
I've read about the modules approach, but have not been successful using this approach to get the deployed application to see the module from the service loader implementations.
Would like to know if there is an alternative solution or perhaps we are doing something wrong?
Thanks
WildFly supports exploded deployments with the deployment scanner or using the explode command with jboss-cli. Using the jboss-cli you can even update files remotely.
I have a spring boot application using ms-sql database, it deploys properly in external tomcat when the server is newly started, but when I redeploy the same war file I get the following error(the war file still deploys but is not functioning properly:
Native library mssql-jdbc_auth-8.4.1.x64.dll already loaded in another classloader when I redeploy the war file in external tomcat.
So I undeploy the war file, restart the tomcat server, and redeploy it, and it's deploying properly and working (functions and CRUD).
I am using tomcat 9.0.43 and there are no other applications deployed to the server instance.
EDIT: I am running tomcat on windows and also have the .dll file in the tomcat bin folder. Also I'm using maven for dependency management.
The program uses integrated security for DB auth
Your problem comes from the double usage you want to make of your WAR file:
on one side you need the JDBC driver whenever you run the WAR file using java -jar,
on the other side you don't want JDBC drivers in the web application's classloader, whenever the WAR file is deployed in a servlet container. The servlet container should provide the drivers.
Fortunately the spring-boot-maven-plugin already provides such a feature in the repackage goal: all the dependencies marked as provided (such as the Embedded Tomcat libraries) are placed in the WEB-INF/lib-provided folder and hence are not loaded by the servlet container.
Therefore you only need to mark the JDBC driver as provided and add it to Tomcat's common loader's classpath ($CATALINA_BASE/lib).
I would like to manage EAR deployed and exploded in the Wildfly application server on the fly, meaning to change its content (mainly JAR files as submodules) without need to reinstantiate or redeploy the whole package. (which takes time and during the time other modules are not available)
I was trying to do this through the Wildlfy CLI using the commands available for deployment, for example the following commands:
/deployment:myapp.ear:remove-content
/deployment:myapp.ear:add-content
These commands effectively remove or add content inside exploded application on Wildfly, however it seems to be not deployed without redeploying the whole application again.
Is there any way how to achieve it? Is it feasible?
I am assuming this all you are looking for in the context of testing your application and not for production kinds of instances.
If so, you can use WildFly standalone mode and a deployment scanner, which can be configured to keep scanning directories for any change and deploy it. Thanks!
Repository - https://github.com/wso2/product-apim
Branch - 2.x-dependency-upgrade
Recently, While working with WSO2 API Manager, I found that some war files are generated and deployed.
To experiment with the war files, I deployed them on tomcat server. Deployment doesn't work and gives Error creating bean with name 'cxf' defined in class path resource META-INF/cxf/cxf.xml.
Detailed Error Log : https://gist.github.com/anonymous/4c2378967ffcc1bb7a9bb475507120e9
.war file location: \product-apim\modules\distribution\product\target\wso2am-2.2.0-SNAPSHOT\repository\deployment\server\webapps
I tried to play with dependencies but with no change in error status.
Why does these war files work well with the WSO2 standalone server, but not with the tomcat server ?
How could we resolve the dependency issue ?
First of all, don't use 2.x-dependency-upgrade branch, which is a temporary one. Use 2.x branch instead.
Those war files need dependencies coming from carbon platform. (You can see lots of NoClassDefFoundError errors in the log) So, without those, they won't be working properly.
I have been trying to work with WildFly, however I'm facing some odd issues, for example I can deploy from a *.war withouth any problem with connection to the database, but an unmanaged deployment is a headache, never starts, same when trying to do this throught Eclipse.
I'm doing a normal deploy for debugg using Eclipse, but anytime I'm getting this message:
WFLYEE0027: Could not load oracle.jdbc.driver.OracleDriver referenced in env-entry.
I have all the runtime configuration in Eclipse and also I did all the module configuration inside WildFly for standalone. I have added the *.jar to the proyect manually.
This is a maven project, any idea of how to solve this?
Okay, for this time I could solve the problem by adding the *.jar files this way:
So now WildFly can load the libraries from the lib folder