We have an old application running on a WebLogic 8.1.5.0.
In this version, we can see that the application has been configured as a directory (which has classes, css, images, htmls), but No WAR, JAR or EAR found for this app.
PFB the extract from config.xml
Application Name="abc" Path="/wls_domains/flret/admin/applications" StagingMode="nostage" TwoPhase="true">
<WebAppComponent Name="abc" Targets="admin" URI="abc"/>
Now, we need to migrate this application to WebLogic 10.3.6.0.
New Weblogic is not allowing us to deploy an application other than WAR, EAR or JAR.
Also, config.xml structure is completely different for new weblogic.
<name>XYZ</name>
<target>XYZ_cluster</target>
<module-type>war</module-type>
<source-path>servers/admin/upload/XYZ.war</source-path>
<security-dd-model>DDOnly</security-dd-model>
Is it something related to weblogic versions and feature available to deploy a directory?
Can someone plz suggest can I complete this deployment or any other way to do this.
Thanks in advance.
Looks like you have an 'Exploded Archive' app, which modern versions of weblogic do not support. You need to upgrade to a modern format, or put it directly on the filesystem of the app server.
(see: How can I deploy an exploded web app through WebLogic 11g administrative console?)
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)
i am using idea ultimate 2020.3
i created a maven web project.
when i changed java or jsp files and choose update class and resources, they can be hot deploy.
however, if i changed files under src/main/resources, e.g. mybatis xml file under src/main/resouces/config/mapper, they cannot be hot deploy.
how can i fix it?
Make sure you are deploying an exploded artifact, see Update applications on application servers
Also make sure the module has configured Web resources (has the Web facet with Web Resource Directories and Source Roots configured:
I am having two queries
1. Can I deploy web application as a folder instead of war file in JBoss AS 7?
2. If not ,how to update the JSP or html or js files with out building/deploying the war file again?
JBoss supports the ability to deploy an archive file or as an exploded directory. To explode a Java EE archive, unzip the archive to a directory that is named the same as the archive file. As long as the directory name has the correct extension (.war, .ear, etc.) JBoss will deploy the directory normally. So if your war file has name HelloWorld.war, your exploded directory name should be HelloWorld.war too.
Please also note that it is recommended to edit your deployment-scanner in the standalone.xml configuration file and changing auto-deploy-exploded property back to false for exploded deployment. Quote from JBoss 7.1 Documentation:
Manual deploy mode is strongly recommended for exploded content, as
exploded content is inherently vulnerable to the scanner trying to
auto-deploy partially copied content.
Edit:
Please see link https://community.jboss.org/thread/200114. Looks like this is a confirmed bug in JBoss 7.1.1 that JBoss ignores the configuration in jsp-configuration and does not reload modified jsp. It is fixed in 7.1.2. You need to build 7.1.2 nightly build yourself. Or talk to JBoss Support if you have Enterprise support.
I' starting to use ServiceMix and Camel and I've run through many examples.
It seems that the examples that are OSGi can be deployed in ServiceMix via hot deploy or via console, but I don't know how to deploy a project that is not an OSGI. Can it be done?
For example, I'm looking at the example project from Camel 2.10.0 called camel-example-cxf-proxy. I did some alterations and now I wanted to load it in ServiceMix. If I copy/paste to the deploy directory it is loaded but when I try to run it via osgi:start id it fails.
However if I run it from the IDE as a standalone it runs just fine and I can send and receive requests via SoapUI.
When I'm done with the examples I'll want to create my own project in eclipse and do tests in the IDE and in ServiceMix. I don't really understand the advantage of OSGi yet. SO I'm not too compelled to use OSGi for my project.
My main question is: Can I deploy a non-OSGi non-JBI compliant project in servicemix? Something like the camel-example-cxf-proxy. If yes, how can I do it? If no, how can I OSGi-fy the camel-example-cxf-proxy?
Thank you :)
Apache ServiceMix which uses Apache Karaf as its kernel, support pluggable deployment units. Though OSGi is the main unit.
You can deploy JBI artifacts (eg JBI was used as deployment units for Apache ServiceMix 3.x). So we offer that as a migration path to run JBI in SMX 4.x.
A plain WAR file can be deployed as well. You can for example just drop a .war file in the deploy directory. If you deploy from the shell, you need to prefix the deployer with war so it knows to use the war deployer.
There is some documentation about the various pluggable deployers here
http://fusesource.com/docs/esbent/7.0/esb_deploy_osgi/UrlHandlers.html
For example to install an Apache Wicket WAR example using Maven you can do from the shell:
osgi:install war:mvn:org.apache.wicket/wicket-examples/1.4.7/war?Web-ContextPath=wicket
The Apache documentation about deployer is mainly documented at Apache Karaf
http://karaf.apache.org/manual/2.2.9/users-guide/deployer.html
Now to deploy OSGi applications can be a bit of pain to assemble. And that is why FuseSource created FAB to make it much easier. I blogged about this a bit, which references to videos and more material: http://www.davsclaus.com/2012/08/osgi-deployment-made-easy-with-fab.html
With FAB you can just deploy regular Maven projects out of the box without any OSGi pain.
If your project is a maven project, you can try :
mvn install
Then start your servicemix, and in servicemix command line :
install mvn:groupId/artifactId/version
This will prompt a bundle ID. Then, juste start the bundle :
start <bundle_id>
You can check the state of your bundle with command "list"
The project has to be a bundle to be installed in servicemix / karaf. So the steps to make a camel project work in OSGi are the following.
Use the maven bundle plugin in the pom and configure it to import / export the necessary packages if necessary.
Make sure your camel context is defined in a way that OSGi can start. This is either in the activator of the bundle or in a spring config in the right location or with a blueprint config in the right location.
See two of my karaf tutorials for the details:
CXF: http://www.liquid-reality.de/x/EoBk
Camel: http://www.liquid-reality.de/x/G4Bk
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().