We Keep Coding

Want to change the context path in Spring boot application in an external Tomact server version 9

I want to deploy a Spring boot application in an external Tomcat server version 9. I am able to deploy it and working the endpoints also. But properties I have set in application.properties file those are not working. Like server.servlet.context-path=/myapp is is not working instead the context path which I am getting is http://localhost:8080/myapp-0.0.1-SNAPSHOT/api/ping.
I am using 2.3.10.RELEASE and Java 1.8 and Tomcat version 9.0.46 Can anyone please help me out with this.
But everything is perfectly working on embedded tomcat. Thanks in advance and any suggestion, comment is highly appreciated.
Can anyone please help me with how I can do this - My war file name would be myapp-0.1.war but the context path of the application would be like this localhost:8080/myapp/api/ping

Use finalName property in your build file (pom.xml for maven)
<finalName>myapp</finalName>

When you run a Spring Boot application in an external servlet container, the server.* properties do not apply.
If you are willing to change the naming convention you can drop a WAR file named myapp##0.1.war in the $CATALINA_BASE/webapps directory and benefit from parallel deployment (cf. parallel deployment).
If you want to stick to your naming convention, you can create a folder for your WAR files (e.g. $CATALINA_BASE/webapps-available) and create a deployment descriptor $CATALINA_BASE/conf/<engine_name>/<host_name>/<context_path>.xml (in your case probably $CATALINA_BASE/conf/Catalina/localhost/myapp.xml) with the following content:
<Context docBase="${catalina.base}/webapps-available/myapp-0.1.war" />

Can/should I depend on WebLogic's bundled modules

My target platform is a WebLogic 12c application server.
I have an ear-project, which on startup requires e.g. org.apache.commons.logging.LogFactory.
I know that this class - an related classes - can be found in <WL_HOME>/modules/com.bea.core.apache.commons.logging.api_1.1.1.jar, but it is not by default available on the classspath.
In such cases - am I supposed to somehow make the jar file in <WL_HOME>/modulesavailable on the classpath - or should I provide whatever jar file I find suitable - either bundled in the application, or placed in <WL_HOME>/user_projects/domains/<mydomain>/lib?
If I am to use the one in the <WL_HOME>/modules folder - how do I configure my domain to make it available?
To me it seems reasonable that the jar files in the modules folder should be considered provided dependencies, but so far I have been unable to find the right way to enable them as such - I have been browsing for an answer for hours:-)
UPDATE:
I know I can simply add them to the CLASSPATH variable in the server startup script - my question is more like - should I? Is there a better way - or should I completely forget about <WL_HOME>/modules?

That's a short-sighted approach.
you need to reboot the server to upgrade libraries
every app on the server must be okay with those libraries in their claspath
Weblogic has the concept of Shared JEE Libraries (example). In short, you add extra lines to MANIFEST.MF and configure the jar differently, then you can reference it in other apps using weblogic-application.xml or whatever.
The point is that you can upgrade the library without restarting the server (provided you gave it a version like 1.1 (there were bugs last time I named it 1.1.1 - it needed to be able to cast it to a floating-point number to seamlessly upgrade)).
If you just want to include some libraries but not share them outside the app, then just specify the correct <prefer-application-packages> or < prefer-web-inf-classes> element, depending on whether you have an EAR or a WAR.

WAS 6 steps to follow to support MQ 7 features

I have problem with EAR module deployed in WAS6.
To support the MQ 7 features in my App. I follow the below steps:
Put Class loader policy as PARENT_LAST.
Placed all MQ 7 related jars in the root of EAR.
EAR contains Web module. When I try to start the application, I got following exception:
javax.servlet.jsp.JspException: Can't get definitions factory from context.
at org.apache.struts.taglib.tiles.InsertTag.processDefinitionName(InsertTag.java:575)
at org.apache.struts.taglib.tiles.InsertTag.createTagHandler(InsertTag.java:474)
at org.apache.struts.taglib.tiles.InsertTag.doStartTag(InsertTag.java:436)
at com.ibm._jsp._home._jspx_meth_tiles_insert_0(_home.java:106)
at com.ibm._jsp._home._jspService(_home.java:81)
The War contains the following jars.
xstream-1.3.1.jar,xercesImpl.jar, xalan.jar,struts.jar, standard.jar,commons-validator.jar, commons-net-1.4.0.jar, commons-fileupload.jar, commons-digester.jar, commons-collections.jar, commons-beanutils.jar,resolver.jar,jstl.jar, jfreechart-1.0.2.jar, jcommon-1.0.5.jar, jaxen-full.jar, jakarta-oro.jar.
EAR contains the following Jars,
com.ibm.mqjms.jar, com.ibm.mq.jmqi.jar, com.ibm.mq.jar, com.ibm.mq.headers.jar, com.ibm.mq.commonservices.jar,log4j.jar,dhbcore.jar.
And I set the class-path attribute in my Manifest file of the WAR with log4j.jar
Please anyone suggest me how Websphere's classloading policy works for where I went wrong.
Karthik

Some time ago I did something similiar. I wanted to use a specific version of a library which was already used within the WebSphere Application Server. That is the reason why you have to put your libraries in the EAR file and set the application server to PARENT_LAST class loader order.
Correct me if I am wrong, but you also have to specify your custom MQ client libraries in Manifest of your WAR file. You only mentioned Log4J. It should look somehting like this:
Class-Path: com.ibm.mqjms.jar com.ibm.mq.jmqi.jar [...] log4j.jar
Anyway, you can always check what libraries are in the Classpath of you application if you log into the Integrated Solutions Console (aka Admin Console) and check the Troubleshooting section. There is a classloader viewer. Just click yourself through the tree and check which library path are mentioned and which you would expect.
Finally, as Dylan already mentioned in his comment: WebSphere Application Server version 6.1 runs out of support September 30, 2012. :)

Separated login config for JBoss?

I'm trying to create an RPM-packaged Ear file that should be installable together with other RPM-packagesd Ear files in a JBoss container. (I could probably create a separate container within JBoss, but that's a lot of overhead for one Ear.) This works fine, except for one issue.
My problem is that this Ear file expose web services that use their own authentication policy (login-config.xml policy/application-policy/authentication/login-module). Now that multiple RPMs want to supply authentication information through this file, we get into conflict with the RPM spec rule that no file can be owned by more than one RPM package (and anyway whichever RPM goes last would clobber the previous).
Is there any way that the application-policy/authentication block can be declared in a separate file or in some manner that places it outside login-config.xml? For example, is it possible to declare additional security mbeans (in separate files) that refer to a separate login XML definition?
This is JBoss v4.2, but I would be willing to consider later if it solved this issue.
Update:
Lukasz rules. Below is working config!
<?xml version='1.0'?>
<server>
<mbean code="org.jboss.security.auth.login.DynamicLoginConfig"
name="jboss.security.tests:service=LoginConfig">
<depends optional-attribute-name="SecurityManagerService">
jboss.security:service=JaasSecurityManager
</depends>
<depends optional-attribute-name="LoginConfigService">
jboss.security:service=XMLLoginConfig
</depends>
<attribute name="PolicyConfig" serialDataType="jbxb">
<jaas:policy
xsi:schemaLocation="urn:jboss:security-config:4.1 resource:security-config_4_1.xsd"
xmlns:jaas="urn:jboss:security-config:4.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<jaas:application-policy name="mySecurityDomain">
<jaas:authentication>
<jaas:login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<jaas:module-option name="unauthenticatedIdentity">noone</jaas:module-option>
<jaas:module-option name="dsJndiName">java:/myDataSource</jaas:module-option>
<jaas:module-option name="principalsQuery">SELECT password FROM WebServiceUser WHERE userName=?</jaas:module-option>
<jaas:module-option name="rolesQuery">SELECT role, 'Roles' FROM WebServiceUser WHERE userName=?</jaas:module-option>
</jaas:login-module>
</jaas:authentication>
</jaas:application-policy>
</jaas:policy>
</attribute>
</mbean>
</server>

You can try and setup login module using DynamicLoginConfig service. I never use it but it looks like something that can help you. It allows you to create login module configuration
in different file and deploy it during application installation.
Here you can find more info about it:
Dynamic configuration of JAAS login
AS5: Specifying Security Domain Configuration
Configuration DynamicLoginConfig
10.5.2. The DynamicLoginConfig service
using DynamicLoginConfig

Can I set the classloader policy for WebSphere in the ibm-web-bnd.xmi file?

I have a JEE application that runs on WAS 6. It needs to have the class loader order setting to "Classes loaded with application class loader first", and the WAR class loader policy option set to "Single class loader for application".
Is it possible to specify these options inside the EAR file, whether in the ibm-web-bnd.xmi file or some other file, so the admin doesn't need to change these setting manually?
Since the app is deployed via an automated script, and the guy who is in charge of deployment is off site, and also for some other political reasons, this would greatly help!

Thanks to #Matthew Murdoch's answer, I was able to come up with a solution. Here it is, in case it helps someone else.
I created a deployment.xml like this:
<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1241112964096">
<deployedObject xmi:type="appdeployment:ApplicationDeployment" xmi:id="ApplicationDeployment_1241112964096" startingWeight="1" warClassLoaderPolicy="SINGLE">
<classloader xmi:id="Classloader_1241112964096" mode="PARENT_LAST"/>
<modules xmi:type="appdeployment:WebModuleDeployment" xmi:id="WebModuleDeployment_1241112964096" startingWeight="10000" uri="AGS.war">
<classloader xmi:id="Classloader_1241112964097"/>
</modules>
</deployedObject>
</appdeployment:Deployment>
Make sure to change the name of your WAR file(s) to match (mine is called AGS.war).
I also changed the numbers in the xmi:id attributes, to be sure they are unique, though I'm not sure it it really matters that they be unique across applications.
Then, I put the deployment.xml file in the root of my EAR file, via ANT:
<ear destfile="${artifactsDir}/${earName}.ear" appxml="${projectName}_EAR/application.xml">
<fileset dir="${artifactsDir}" includes="${warName}.war"/>
<fileset dir="${projectName}_EAR/" includes="deployment.xml"/>
</ear>

Edit (2): The WebSphere Application Server Toolkit (AST) is a tool you can use to enhance an EAR file with this information (see for example the 'Configure an Enhanced EAR' section in this document).
Edit (1): This post suggests that the 'Classes loaded with application class loader first' (the PARENT_LAST setting) can be set in the deployment.xml file within the EAR.
If you have control over the automated deployment scripts this can be done. Below is some wsadmin jython code for setting the web module class loader order to 'Classes loaded with application class loader first' (interestingly the setting is called PARENT_LAST which is what it was labelled in previous versions of the admin console...).
wsadmin example (jython):
def getWebModule(config, applicationName):
webModules = config.list('WebModuleDeployment').
split(system.getProperty('line.separator'))
for webModule in webModules:
if (webModule.find(applicationName) != -1):
return webModule
return None
applicationName = "<Your application name here>"
webModule = getWebModule(AdminConfig, applicationName)
if (webModule != None):
AdminConfig.modify(webModule, "[[classloaderMode PARENT_LAST]]")
AdminConfig.save()
else:
print "Error: Cannot find web module for application: " + applicationName

Check out this link. There are different ways to set class loader policy using Jython based on your server version -
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frxml_7libapp4.html

Similar to the answer from pkaeding, I discovered as follows, not specific to a particular .war by name, but useful when applying to whatever is the default .war in the .ear file. (.ear files with one .war file in them have only that .war, so naming the .war isn't necessary in the entry.) This approach may be good for situations where you may need to re-name of the .war project later for some reason, and so you wouldn't need to worry about updating the deployment.xml file. I found the deployment.xml file buried inside a cell reference directory trail; dunno if it's fine as shown when the file is placed at directory level META-INF and no deeper.
In my particular case, I found deployment.xml in my .ear project at:
<project_root>\META-INF\ibmconfig\cells\defaultCell\applications\defaultApp\deployments\defaultApp\
The content of the file looks a lot like:
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi" xmi:id="Deployment_1262775196208">
<deployedObject xmi:type="appdeployment:ApplicationDeployment"
xmi:id="ApplicationDeployment_1262775196208" startingWeight="10">
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_LAST" />
</deployedObject>
</appdeployment:Deployment>
The line:
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_LAST" />
originally read:
<classloader xmi:id="Classloader_1262775196208" mode="PARENT_FIRST" />
Note no reference to any .war is being made. As pkaeding mentioned, you shouldn't expect the various id numbers to be the same for you.