I am trying to deploy this application to the Mule server.
It works on Anypoint Studio without a problem.
When I go to deploy it on the standalone server, it fails and in the logs, I find this error
java.lang.IllegalStateException: Incompatible version of plugin 'APIKit' (org.mule.modules:mule-apikit-module) found. Artifact requires version '1.6.0' but context provides version '1.5.5'
What's weird is that the version of APIKit I used on the app is 1.6.0 which I upgraded from 1.5.5.
The app is using a domain, and the dependencies' versions between the domain and the app are the same.
What can be the solution to this problem?
It looks like the domain is really using the dependency for APIKit 1.5.5. Another reason could be some incompatible version of the REST Validator Extension as mentioned in the documentation. Also if the domain or the application is using a jar library to import common Mule configurations it may be referring to a different version of the APIKit module. You can take a look at the logs to see what versions are being deployed.
Related
I need some information of log4j2 for updating our central versions of Mule CE 3.9.0 and Mule CE 3.9.5 (CE=Community Edition).
What is the best way to protect them and does downloading only jar files from Apache site https://dlcdn.apache.org/logging/log4j/2.12.3/ be useful to patch Mule CE 3.9?
Regards
As a summary you only need to find the vulnerable jars in the mule-server and in the mule flows deployed in the apps folder.
A Java project is a set of java class and libraries with complex dependencies relationship, but easy to replace one of them (manually or automated with maven), so no matter how or where log4j is being used, we just need replace the jar file.
mule community server 3.9.0
In this version, with this command find . -type f -iname "*log4j*" we will get the log4j jars:
As we can see, the version prior to the 2.14.x
log4j-jul-2.8.2.jar
log4j-jcl-2.8.2.jar
log4j-slf4j-impl-2.8.2.jar
log4j-core-2.8.2.jar
log4j-api-2.8.2.jar
log4j-1.2-api-2.8.2.jar
But according to the official maven repository, this version is affected too :(
Just the 2.17.0 is safe to use
Source: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
If this change breaks your mule, just delete the specific vulnerable class:
zip -q -d
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Source: https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
mule flow or mule app
This is not the server, is the app developed by programmers, packaged as .zip and deployed to the mule apps folder in the server.
In this layer, the app can ignore completely the server configurations and has its own jar versions.
If you don't use maven (rare), you need to search and replace the jar, app by app, similar to the server with find command but in the specific app folder:
/opt/mule_server/apps/my-mule-app
If you use maven, you could find if the jar is used with the pom.xml previewer of Eclipse Ide or with command mvn dependency:tree. Check this:
https://stackoverflow.com/a/68916675/3957754
Remember: If you not use directly this jar, you need to check if mule esb server uses it.
Here some tips from manual to automated pipelines:
mule esb monolithic with manual deployment
In this case you need to fix the server and your apps.
for the server, backup, stop, search the jar on lib folder and replace it with the 2.17 (after vulnerability fix) and start. Test if everything is working
for the mule apps, the process is the same: stop the mule server, go to your mule apps and one by one, search the jar and replace it. Start the mule server and test if everything is working
git repository , maven and one mule app by server
In this case, you don't have a big server with a big mule containing a lot of mule apps/flows. You have one light server for just one mule app.
Just search the dependency in your pom with maven and replace it.
Push your changes and in the next deploy( manual or automated) your mule app will be fixed.
Also note that this approach fix the app, not the server.
git, docker
If you are using docker, the things are easy. Just search the Dockerfile (usually in a git repository). In this file there are a lot of sentences, since the java installation until the star of mule server.
Choose the exact line between the download of mule and the start of server and put a sentence which replace the jar file
Next deploy will pick you new image version and that's all.
automated flow(devops)
Here you are using maven, gi, docker and some ci server. You just need:
update the git repository of your mule app (maven)
update the git repository of your docker image
deploy your fix using the ci server.
With this, you will not need human access to the production servers to fix your java application ( mule)
On Linux we have the MULE_HOME/policies directory. We are trying to deploy manually the packaged policy as per documentation from mule documentation
We don't want to use any point platform. Any idea or any documentation there
We used to drop different mule jar (application jar and domain jar) into apps and domains folder and it works fine( hot deploy).
This is for mule runtime version 4.2.x
Please notice, if anybody, the custom policy has to be connected to the exposed API or the mule application under the apps folder. In summary, to do the manual job as it is done from the GUI by anypoint platform
We are migrating from WebSphere 8.0 to WildFly 10.0.0. after compiling the project in eclipse and removing all the reference of IBM WebSphere jars, on deploying the application, I am getting an error that NoClassDefFoundError: com/ibm/wsspi/uow/UOWException
I have tried to search this exception class in my project, i did not find any.
Can you please help me in fixing this error.
Along with the migration , we are also upgrading Java version to 8 and Spring version to 4.3.0
While working on this, I figured that we were referring to WebSphereUowTransactionManager which is specific for WebSphere in the Springs Transaction Manager. We have to replace it with JtaTransactionManager for removing the exception.
JPA 2.0 "seems" to be finally working in my application deployed on Weblogic 10.3.5 (after tweaks described below).
However, I still get the following message on the WL console terminal:
This version of OpenJPA cannot read a persistence.xml document with a version different from "1.0". Found: version "2.0" in
This is appearing more than once in the logs and I am looking at some way to get rid of it. Read somewhere that this happens with WL 11g release but is there a way to hide/do away or fix it?
Environment:
Weblogic 10.3.5
Toplink configured as default persistence provider in console
WL classpath modified to have jpa2 specific jars in WL in front of the path (as described in Toplink with Weblogic 10.3)
Removed Toplink jars from application.
We've used the Oracle patch to configure JPA2 on WLS 10.3.5
http://docs.oracle.com/cd/E24329_01/web.1211/e24972/using_toplink.htm#CIHIBGBG
Looks as if Kodo is using openJPA. You might consider configuring Toplink in your console.
I just downloaded the Glassfish version 3.1.2, this is not yet an official release.
I need this version because my web application is using websockets.
The problem I have now is with the Glassfish plugin for eclipse, he is not recognizing the new Glassfish Version.
With the Glassfish Version 3.1.1 in Eclipse everything works fine.
I am using Oracle Glassfish Server Tools (Eclipse plugin ) version 2.0.0.20111104904 from Oracle(last version I could download).
If I try to add a new Server Runtime Environment in Eclipse for the Glassfish 3.1.2 I get the error:
There is no valid GlassFish installation in the specified directory...
I need everything to be able to debug my web application in Eclipse.
Anyone know what the plugin is checking ?
There is any change to trick the plugin so will run with Glashfish 3.1.2 too ?
Use the plugin from here (for Indigo): http://dlc.sun.com.edgesuite.net/glassfish/eclipse/indigo/
The plugin for Helios does not support 3.1.2.
If you have to live with the bits the are blessed by Oracle or keep using Helios, then you can try the following trick:
create a couple files....
${glassfish.rootdirectory}/modules/jsf-impl.jar and
${glassfish.rootdirectory}/modules/jstl-impl.jar
These files were renamed between 3.1.1 and 3.1.2...
You may be able to get the 3.1.2 to mascarade as 3.1.1 by just
creating empty files with the above names. If that doesn't do it,
make copies of the following files should do it.
The new name for jstl-impl.jar is
gf312/glassfish/modules/javax.servlet.jsp.jstl.jar
The new name for jsf-impl.jar is
gf312/glassfish/modules/javax.faces.jar.
If you are on Helios, you can try the following:
uninstall the Glassfish 3.1.1 plugin (and all associated runtimes and servers).
go to "Install new software" and type in (for the URL): http://download.java.net/glassfish/eclipse/indigo
Though the plugin says indigo, it is also working for me in Helios. And it gives options for both Glassfish 3.1.1 and 3.1.2 servers (pre and post name changes).
Note that it downloads Glassfish itself, and installs an internal server. You can delete that one, and install your own server ("New server...") if you have an existing server you want to work with (as I did).
HTH.