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" />

WFLYEE0040: A component named '...' is already defined in this module

I get this error in a Java maven project. The weird thing is, it doesn't appear on every machine so I assume it has something to do with a configuration issue.
The class RoleKeyCacheImpl is a #Startup #Singleton:
#Startup
#Singleton
public class RoleKeyCacheImpl implements RoleKeyCache { ... }
That's the error Wildfly triggers when deploying the service.
Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component
named 'RoleKeyCacheImpl' is already defined in this module at
org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:167)
at
org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:58)
I've tried:
installing a new Wildfly (V10, V13) on the same machine -> doesn't help
installing a completely new Eclipse on this machine -> doesn't help
cleaning & rebuilding all related projects
making sure the deployments-folder is empty and doesn't contain old versions of the same WAR
read the related question here which also didn't help (they use Spring): A component named 'XXX' is already defined in this module in JBoss 7.1.1
read and tried this q&a: Wrong dependencies with EJB in JBoss Wildfly (server-clean) -> doesn't help
deleted and rebuilt the local maven rep (".m2") -> no effect
checking out the same source on another computer -> does work on one machine, on another it gives the same error
I have absolutely no clue what the issue is or even could be. On one machine, we check it out and it runs without errors. On others, the exact same error happens.
Does anybody have an idea?

I had this same issue multiple times with EAP 7.1 and now again with WildFly 21.0.0. I know by experience this is an issue caused by Eclipse who tries to deploy automatically to a configured WildFly instance. During the deployment (or undeployment) some concurrent file issue arises and files who should be removed, are still on the filesystem, causing this error that a component is already defined.
In fact it is not already defined, it is just WildFly that is confused because it finds in his temporary directories some old files which shouldn't be there and reference your exact same component.
Solution: remove in the WildFly standalone directory the content in the 'deployments' directory and the 'tmp' directory. Rest assured, all what is there is okay to remove safely. Reboot and the error message will be gone ;-)

You should pay attention to not have two #Stateless EJB annotations on top of two classes with the same name - in the same module.
You may differentiate them by using the name attribute in the annotation and put different values in each class

Looks like the class already exists. Check if it does...you may have to rewrite that part of EEModuleDescription to use its own private methods (which would be what you would write) rather than overriding methods in RoleKeyCacheImpl. If the class actually does not exist then right-click on the project -> Maven 2 Tools -> Generate Eclipse Artifacts (Check for Updates). That will regenerate all of the dependencies that the project uses. Also please be sure that you have not added any new projects to the classpath by mistake as that may also cause this error.

I just ran into this today when a colleague added a maven dependency.
Turns out this dependency was a jar with a nasty classpath entry or "../" in the manifest.
I edited the jar's manifest.mf that was cached in my local maven repository using 7-zip and removed the "../" classpath entry.
Then re-packaged my war file (maven clean install) and bingo, it works!
In my case it was caused by org.libreoffice jurt version 5.4.2 (but other versions I checked also have the classpath nastiness).
Unfortunately I was lucky we pinpointed it to a dependency, YMMV!

JackRabbit setup on WAS for one of our REST application

We are trying to setup JackRabbit Oak on one of our Linux machine with IBM WAS application server and facing some issues starting the sever on WAS.
The Apache JackRabbit is a content repository which is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more. We are using it for storing digital assets in structured form (specifically, as a tree) as per our requirement.
We have a REST application and another application DAM (Digital Asset Management) which handles creation of repository, providing connection with the repo whenever requested (Singleton), creating nodes, etc. on the repository. In our local development setup we have exported this DAM as a JAR, say dam.jar and have put this in REST application’s class path. We have JackRabbit Oak’s JAR (oak-run-1.4.11.jar), which we have put in class path of DAM application.
While doing a similar setup on Linux machine on WAS application server, we are using the same dam.jar which is created by exporting the project as a JAR in eclipse on Windows machine. We put this in REST application’s class path on WAS by configuring this in the server on which REST app is deployed.
While debugging we found that application is able to access classes from dam.jar, but when DAM’s class tries to call JackRabbit’s classes it fails throwing java.lang.NoClassDefFoundError. We tried putting JackRabbit’s JAR (oak-run-1.4.11.jar) in the class path on WAS by configuring this for REST app’s server, but then server fails to start.
Attached is the log file: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/servers/RESTAPP/configuration/1489493294429.log
There is nothing much inside server logs from /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/RESTAPP (RESTAPP is the server name for our REST application), below is the snippet:
[3/14/17 17:38:04:872 IST] 00000001 ModelMgr I WSVR0801I: Initializing all server configuration models
[3/14/17 17:38:08:564 IST] 00000001 WorkSpaceMana A WKSP0500I: Workspace configuration consistency check is disabled.
[3/14/17 17:38:08:834 IST] 00000001 AdminTool A ADMU3200I: Server launched. Waiting for initialization status.
[3/14/17 17:38:18:241 IST] 00000001 AdminTool A ADMU3011E: Server launched but failed initialization. Server logs, startServer.log, and other log files under /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/RESTAPP should contain failure information.
We suspect dam.jar here, as this has been created from our eclipse workspace by exporting it as a JAR file and this might need some extra information to have this JackRabbit Oak libraries included in that.
We are putting classpath entries in Application servers > RESTAPP > Process definition > Java Virtual Machine of WAS.
Thanks

I would try creating a "Shared library" in Websphere and putting your JackRabbit dependency jars in there:
Environment -> Shared libraries -> New...
Set then name "Jackrabbit", and then in the Classpath box add the paths to your jars.
Then in your REST application (Applications -> Application Types -> WebSphere enterprise applications -> [your application name])
Click "Shared library references" under "References"
Select the application and click "Reference shared libraries"
Select the Jackrabbit shared library and click the right arrow to reference that shared library from the application.
Classloading in WebSphere is very complicated -- see chapter 22 of the WebSphere Application Server V8.5 Administration and Configuration Guide for the full description. Trying to add classpath entries at the JVM definition level definitely won't work.

To piggyback on Andrew's answer above, the real key is to make sure that both dam.jar and oak-run-1.4.11.jar are within the same class loader, and that they are NOT in a server-level class loader - putting custom code in the server JVM class path makes it visible to the server runtime and can actually override server classes (which is probably why your server init failed after doing that).
The very easiest answer, assuming this is a simple web application, is to put both jars in the WEB-INF directory of your WAR module. Both will be loaded by the web app class loader, and they'll be able to see each other. If there's some reason you don't want them in the application itself, then Andrew's shared library suggestion would have the same practical effect.

Eclipse WTP vs sydeo, " serves modules without publishing "

I have the problem to find the performances of the plugin sysdeo by using the integrated plugin WTP of eclipse.
To make the migration and thus the comparison, I installed both on separate projects within eclipse.
I noticed a difference of productivity, according to what I understood: WTP needs to publish sources in a directory build so that tomcat have them at arrangement. This "pulish" is long : need the recharging of the context so that the modifications are visible. (5 dry in most yard 15sec - 20sec in the longest).
Sysdeo no; it targets of the directory eclipse consequently build internal in the project as soon as a modification is made by a file, eclipse build and these modifications are available immediately (F5 on the browser and we have the result immediately).
Here is my configuration of server:
The option " Serves modules without publishing " allows to make exactly what makes sydeo: to choose the build directory of the project running. This configuration expresses himself in the file of context. (It is to be able to get back it that I have checked " Publish modulates contexts to serparate XML rows ")
Comparison of these files:
Here is the file of context to generate by sysdeo
< Context path="/tatoile _syseo" reloadable="false" docBase="D:\32bit\serveur32bit\workspace\tatoile _syseo" workDir="D:\32bit\serveur32bit\workspace\tatoile _syseo\work" />
The file context to generate by WTP
< ?xml version="1.0" encoding="UTF-8"?>
< Context
docBase="D:\32bit\serveur32bit\workspace\tatoile\web" path="/tatoile"
reloadable="true" source="org.eclipse.jst.jee.server:tatoile">
< Resources
className="org.eclipse.jst.server.tomcat.loader.WtpDirContext"
extraResourcePaths="/WEB-INF/classes|D:\32bit\serveur32bit\workspace\tatoile\build\classes"
virtualClasspath="D:\32bit\serveur32bit\workspace\tatoile\build\classes"/>
< Loader
className="org.eclipse.jst.server.tomcat.loader.WtpWebappLoader"
useSystemClassLoaderAsParent="false"
virtualClasspath="D:\32bit\serveur32bit\workspace\tatoile\build\classes"/>
< JarScanner scanAllDirectories="true"/> < /Context>
Later analyze those two files is alike.
Now let us return to the problem. I use the same server, consequently both files of context above are defined for this one. Experience: I launch the tomcat by the plugin sysdeo, the loads in two context is made the one to configure way WTP the other one by sysdeo. Both authorities reacts in the same way, the modifications are immediate in tatoile _syseo and tatoile.
On the other hand, I launch tomcat via the plugin WTP (tab server etc.) in eclipse, the modifications are not immediately made in both projects tatoile _syseo and tatoile. Note: Auto-reload has to be necessarily put in Enabled so that the modifications be taken into account. (When the server indicates us that it has reload the context we can see the modifications.)
I deduct that from it the configuration of contexts not is not the reason, but rather the way the plugin launches tomcat; and there or I dry …
Here is WTP project:

The answer quoted from #Vsplit
The problem was solved by adding MAVEN with WTP deployment. No
performance problems ... and I don't activate serve modules without
publishing

look in the plugin marketplace for a free plugin called m2e-wtp. That will take care of the provided scope issues. As for classes not being deployed, the usual places I look at are the deployment assembly and/or Java Build Path. Make sure that the entries (and the dependent modules) are all there and located in the right place.

Ejb lookup failing on WAS7.0 with NamingException

I have an application developed on RAD using WAS 6.0. I migrated the code to WID 7.0. After making some changes in the EJB modules(Had to remove the bnd.xmi file from each ejb module to deploy the application on Application Server)the application is running fine, but the EJB modules give the following error:
NamingException has Occured While Getting Local Home
javax.naming.NameNotFoundException:nullName ejb/com/igcc not found in context "local:".
I am not able to figure out what changes do it need to make to run the application on WID.
Any help is appreciated.
Thanks,
Ayush

Well, the "bnd.xmi" files you deleted are the WebSphere-specific deployment descriptors, containing binding information. One of the things that are mentioned there is the name under which to bind each individual EJB home.
You cannot possibly run an EJB module without this binding information existing somewhere.
If you delete these files (which are generated by RAD), you have to assign new binding information from within the administration console, or via your wsadmin-based deployment scripts.
In short... lets start by recovering those files that you erased. :-)