We are developing a mobile app using IBM MobileFirst platform.
We compile the code using the command line tool with the command 'mfp build' and deploy it using 'mfp deploy', and we are able to preview the application from the URL mentioned below: http://localhost:xxxxx/worklightconsole/index.html
After doing 'mfp build' I get these 6 files:
mobapp.war
mobAppAdapter.adapter
Dashboard-all.wlapp
Dashboard-common.wlapp
Dashboard-desktopbrowser-1.0.wlapp
Dashboard-ipad-1.2.wlapp
Questions:
Where can I find the 6 files in 'worklight console'? (or)
Which other URL I have to refer to verify whether the files have been deployed correctly or not?
Because when I type in 'mfp build' it deploys the files but we are not sure where its getting deployed. We don't have WAS installed instead 'liberty' is used to our knowledge
The MobileFirst Platform CLI tool contains an embedded WebSphere Liberty profile server inside of it. It is this server and its internal database (during development time(!)), that the artifacts you have mentioned get deployed to.
You create a project ("mfp create").
You then start the server ("mfp start").
You then create your applications, develop them, etc...
Eventually you build and deploy it to the server ("mfp build", "mfp deploy").
The resulting files of the build command are the .adapter and .wlapp files.
These get deployed using the deploy command to the server's database.
You then see these files in the console using "mfp console".
The .war file is your project's runtime, containing metadata required for various server operations. This file is part of the server and handled automatically by the underlying tooling. This is invisible to you during development.
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)
Developer server version is
mfp -v: 7.1.0.00.20160206-1603
Production server version is
wladm -version 7.1.0.00.20150807-0630
Project is mfp cordova type.
Building for developer server.
App built with Ant works.
App built with Gradle works.
Building for production server.
App built in release/debug with Ant - works fine.
App built in release/debug with Gradle, gets [...android/init] timeout or 500.
Signing is the same.
Configuration is the same.
wlapp is properly deployed to production and developer server.
On device app looks fine. Everything is ok, but cannot connect to WL server.
Looks like something is wrong with app authenticity.
But Ant signed-release works. Gradle signed-release/debug fails to connect.
Same project, same settings. Whats wrong. Have you seen this?
EDIT
Looking at logcat logs, found this error
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.../base.apk"],nativeLibraryDirectories=[/data/app/.../lib/arm, /vendor/lib, /system/lib]]] couldn't find "libauthjni.so"
But when I just change address (wlclient.properties) to local Dev server - everything is ok. No error.
Cordova applications created with the CLI are based on Cordova 3.7.
Cordova 3.7 does not support a Gradle-based project structure.
I am not able to start the server or stop the server from outside the Mobile First Project. Even to create the runtime server MFP does not allow it unless you are with in the project.
Why does it has dependencies on the project. Logically I can use this sever for multiple projects right?
C:\Users\temp\.ibm\mobilefirst\7.1.0.00.20151114-1616\server\wlp>mfp status
Server worklight is not running.
C:\Users\temp\.ibm\mobilefirst\7.1.0.00.20151114-1616\server\wlp>mfp start
Error: You must be in a MobileFirst project to execute this command.
C:\Users\temp\.ibm\mobilefirst\7.1.0.00.20151114-1616\server\wlp>
Please follow the documentation. There are CLI commands to stop and start the server. There is a single server and you create projects that are all deploy to it.
Navigate into a MobileFirst project and run the command "mfp start".
I have downloaded an iFix from IBM fix central (6.1.0.02.20150520-1015) for Worklight Server and Worklight Studio but I could not locate the below jar files.
Applicationcenterdeploytool.jar
Ibm-java-x86_64-sdk-7.0.-6.0.bin
Json4j.jar
Wlpdevelopers-runtime-8.5.5.2.jar
Can you confirm if the above jar files are also specific to worklight version and will be seen post WL server installation or are they generic files which can used with any WL version which can be used by jenkins build scripts.
Ibm-java-x86_64-sdk-7.0.-6.0.bin - this is IBM's version of Java. This is not bundled with either a GM or iFix or Fix Pack. You're downloading this yourself prior to any installation, if you choose to use it.
Wlpdevelopers-runtime-8.5.5.2.jar - I have no idea what that is. Looks like some WAS or WAS Liberty profile file, which you also install separately from Worklight
Applicationcenterdeploytool.jar - located post-install at install-directory/ApplicationCenter/tools/applicationcenterdeploytool.jar and is the deploy tool of Application Center, used by the ant task scripts.
Json4j.jar - located post-install at install-directory/ApplicationCenter/tools/json4j.jar and is used to handle the JSON file format
I need to deploy a web applicataion as an exploded archive (instead of .war) due to some legacy servlet path location code used in it (ServletContext.getRealPath()). I only have web-based admin console access to the WebLogic 11g server that I intend to deploy to. However, I can't figure how to do it. I see an option for deploying archives, but not directories.
Thanks!
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/deployment/overview.html
"WebLogic Server supports deployments that are packaged either as archive files using the jar utility, or as exploded archive directories".
The link
http://download.oracle.com/docs/cd/E13222_01/wls/docs81/deployment/overview.html
is for version 8.1. In newer versions this option does not exist in the admin console (production mode).
The only way is if you somehow access the operating system, or ask somebody to, unzip the war file in some place and then install from that directory (through admin console). You can also upload the war using admin console, and then in the uploaded directory ask to whom as access to SO to unzip it in that place.
You can also try some ninja stuff like: upload the war that you want to expand. Then make another war that contains code that unzips the war you want to expand.
To solve your problem in weblogic11gR1,In admin console in configuration tab -->web-App container click the option "Archived Real path enabled" so that you can access the servletcontext.getRealpath().