We Keep Coding

How to make spring boot app run on alternate port?

I have a spring boot (2.5.3) app running on a centOS VM behind a firewall. I normally build a fat jar, then run it with a config passed via CLI:
mvn clean package spring-boot:repackage
java -jar target/service.jar --spring.config.location=/path/to/config.properties
run curl GET commands: curl --key /a/b --cert /x/y "https://server-name:8767/path?arg=..."
It works using port 8767 set in the config, and I chose this port a while back randomly.
Since then, I've tried to see if I could make it work with a different port. I opened more ports on the linux public firewall-cmd zone, including 8768 & 9000. Problem is that no matter what I try, the only port I can get the app to run on is 8767. Seems like I've somehow hard-wired it to that port!
Normally server.port is set in the config, but even if I pass another port --server.port=xxxx via cli, the app runs, and logs show it is exposed to xxxx; however, curl can consistently only access 8767, and other ports time out. Or if I set server.port=xxxx in the config, same outcome.
What do I need to do to use a different port? (I saw this...would it help me?)
Dependencies (nothing special)
Dependencies (nothing special)
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
</parent>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-lang3</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
UPDATE: #Vinit - my main class is exactly like yours, except a std println I have to let me know it's running:
System.out.println("Running...");
As for my application.properties, I cannot paste them as I'm behind a firewall, but they are basically below, and there are more than one of each:
logging.level
server.port=xxxx // as described above, i've tried declaring here or cli
server.ssl
# custom auth properties
customauth.url
spring.profiles.active
spring.application.name
spring.task.scheduling
spring.jmx.enabled
swagger
management.endpoints
sanitization
spring.jackson
On another note, I run
sudo netstat -nlp | grep "<port>"
...before I run the app (where is the port I have either in my config or passed CLI), and no results. Then I run the app, repeat the netstat call, and that port is listening sure enough. But same thing: if 8767, all is well; but if 8768, time out.

Spring boot takes into account cli arguments when you pass the arguments to SpringApplication.run method in the main method. Main class should look like this -
#SpringBootApplication
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
Pass args as argument to run method and it should take cli arguments into account. With this class, if --server.port=8080 is used as cli argument, then spring application should run on 8080 port.

this is the order of how spring boots evaluates the different approaches of setting the server port are:
embedded server configuration
command-line arguments
property files
main #SpringBootApplication configuration
so two typical issues if the server.port parameter does not work are overridden behavior in a WebServerFactoryCustomizer or in your main method of the SpringBootApplication

Could not create File Client. Mismatch found for java and native libraries java build version

I am trying to access mapr path remotely, using a spring boot application. I have set the fs.mapr.bailout.on.library.mismatch property to false, to avoid the error on version mismatch. Still whenever the getFileStatus() function gets called, the application stops with the following error:
2020-12-15 10:07:18,7377 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:691 Thread: 123145425235968 Mismatch found for java and native libraries java build version 6.0.1.20180404222005.GA, native build version 6.0.1.20190808152212.GA java patch vserion $Id: mapr-version: 6.0.1.20180404222005.GA 1aeeb6d3c17c777fcba0, native patch version $Id: mapr-version: 6.0.1.20190808152212.GA 1aeeb6d3c17c777fcba0
2020-12-15 10:07:18,7378 ERROR JniCommon fs/client/fileclient/cc/jni_MapRClient.cc:708 Thread: 123145425235968 Client initialization failed.
Code:
FileSystem fileSystem = FileSystem.newInstance(new Configuration());
Configuration conf = fileSystem.getConf();
conf.set("fs.mapr.bailout.on.library.mismatch", "false");
Path OffsetPath = new Path(filePath);
FileStatus file = fileSystem.getFileStatus(filePath); ====> This statement gives error
hbase dependencies used:
<dependency>
<groupId>com.mapr.fs</groupId>
<artifactId>mapr-hbase</artifactId>
<version>6.0.1-mapr</version>
</dependency>
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>1.1.8-mapr-1710</version>
</dependency>
How can I correct this?

So it isn't a great idea to just disable the version mismatch error. Some mismatch is OK for some tasks, but some mismatch can be fatal.
To say much more, it would be helpful to have a little bit of clarification.
when you say remote access, are you talking from one cluster to another? Or from a client machine that is outside the cluster?
assuming that you mean the second case (client outside the cluster), what did you install on the client machine?
why did you disable the version mismatch? What versions are you worried will not match?
does the POSIX interface or the local loopback NFS work from the problem node?
does the hadoop shell work from the problem node?

websocket code not working on Prod Tomcat Server - 404 Error

I am trying to run my first websocket app and refered this link to get some sample code . I simply created CustomEndPoint , WSClient class , html file and then ran it on netbeans IDE and it was working like a charm.
I tried to deploy it on tomcat server whose url is accessible using https by changing ws:// with wss:// and it worked on my dev environment but when I deployed the same code on Production env its throwing below error in console:
WebSocket connection to 'wss://xxxxxx-xxx.xxxx.com/websoc/ratesrv' failed: Error during WebSocket handshake: Unexpected response code: 404
For dev environment I below WS call is working :
wsocket = new WebSocket("wss://dev_ip:8443/websoc/ratesrv");
For Prod I am using(note the .com in url):
wss://xxxxx-xxxxx.xx.com/websoc/ratesrv
Do I need to explicitly provide the port number as well in PROD ?

Does your Tomcat version includes Websockets Runtime?
If it does you must delete all the Websockets dependencies from your WAR. Ensure that you call mvn clean after change scope to provided.
If not, you should include it. If you want to use Tyrus just put
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-container-servlet</artifactId>
<version>1.12</version>
</dependency>
<dependency>
<groupId>org.glassfish.tyrus</groupId>
<artifactId>tyrus-client</artifactId>
<version>1.12</version>
</dependency>
And check that that there are no errors in the Tomcat console when deploy.

Try to use the latest version of tomcat.
tomcat8.5.20 worked for me.

Unable to use OverthereConnection through commandline

I have enabled overthereconnection's through Spring IDE, but when I try running my maven-built application via commandline, I get this error:
Exception in thread "main" java.util.ServiceConfigurationError: jar (Unknown file system scheme! May be the class path doesn't contain the respective driver module or it isn't set up correctly?)
at de.schlichtherle.truezip.fs.FsAbstractCompositeDriver.newController(FsAbstractCompositeDriver.java:33)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController0(FsDefaultManager.java:95)
at de.schlichtherle.truezip.fs.FsDefaultManager.getController(FsDefaultManager.java:78)
at de.schlichtherle.truezip.file.TFile.getController(TFile.java:1497)
at de.schlichtherle.truezip.file.TFile.parse(TFile.java:687)
at de.schlichtherle.truezip.file.TFile.<init>(TFile.java:659)
at de.schlichtherle.truezip.file.TFile.<init>(TFile.java:601)
at nl.javadude.scannit.reader.TFiles.tFile(TFiles.java:23)
at nl.javadude.scannit.reader.ArchiveEntrySupplier.withArchiveEntries(ArchiveEntrySupplier.java:23)
at nl.javadude.scannit.Worker.scanFiles(Worker.java:59)
at nl.javadude.scannit.Worker.scanURI(Worker.java:53)
at nl.javadude.scannit.Worker.scan(Worker.java:46)
at nl.javadude.scannit.Scannit.<init>(Scannit.java:41)
at com.xebialabs.overthere.Overthere.boot(Overthere.java:74)
at com.xebialabs.overthere.Overthere.<clinit>(Overthere.java:69)
at com.emc.ondemand.agent.core.discovery.AnalyzeSelf.constructODEnvironmentForSingleHost(AnalyzeSelf.java:172)
at com.emc.ondemand.agent.core.discovery.DiscoverEnvironment.discoverEnvironment(DiscoverEnvironment.java:85)
at com.emc.ondemand.agent.core.discovery.DiscoverEnvironment.main(DiscoverEnvironment.java:48)
My code call looks like:
// establish winrm connection to target host
ConnectionOptions options = new ConnectionOptions();
options.set(ADDRESS, myHost.getIP());
options.set(USERNAME, user);
options.set(PASSWORD, pass);
options.set(OPERATING_SYSTEM, WINDOWS);
options.set(CONNECTION_TYPE, WINRM_NATIVE); // was not able to get WINRM_INTERNAL to work with processes
connection = Overthere.getConnection("cifs", options);
This is the only dependency I have:
<dependency>
<groupId>com.xebialabs.overthere</groupId>
<artifactId>overthere</artifactId>
<version>4.2.1</version>
</dependency>
It does pull in the correct Truezip classes so I'm at a loss as to what it means exactly.

I guess your dependency is an uber-JAR? Please check if there is a file named META-INF/services/de.schlichtherle.truezip.fs.spi.FsDriverService on the class path. Among others, it needs to contain the following entry:
de.schlichtherle.truezip.fs.archive.zip.ZipDriverService
If that's not the case, then please contact the creator of the overthere artifact and tell them that they appear to have incorrectly assembled their artifact from the TrueZIP dependencies.
In all cases, you should be able to fix this problem by adding another dependency to your class path:
<dependency>
<groupId>de.schlichtherle.truezip</groupId>
<artifactId>truezip-driver-zip</artifactId>
<version>7.7.9</version>
</dependency>

"XNIO001001: No XNIO provider found" error when deploying to Wildfly using Cargo Java API and Jenkins

I am working on a Jenkins plugin which manages the deployment of EAR files to Java EE containers using the Codehaus Cargo Java API, however I've hit an issue when using the API to deploy to a remote Wildfly container. The code works fine when deploying to other containers such as Glassfish, but when attempting to deploy the EAR file to a Wildfly container the error message XNIO001001: No XNIO provider found is returned.
I've spent several hours researching this problem but I cannot find anything that might resolve the problem. This issue occurs when trying to deploy to Wildfly 8.1 and 8.2 running on Windows and Ubuntu. I've also checked the Wildfly server log but it doesn't contain anything related to this issue.
My question is what can do I to prevent the XNIO001001: No XNIO provider found error when deploying to a Wildfly container whilst the code is part of a Jenkins plugin?
I know that Jenkins already has a similar plugin and that Cargo can be used with Maven to deploy to containers but neither option meets my specific requirements.
The code I've written to deploy the EAR file is as follows:
public void redeploy(String containerId, String deployFile, String hostname, String username, String password) {
DeployableFactory deployableFactory = new DefaultDeployableFactory();
Deployable deployable = deployableFactory.createDeployable(containerId, deployFile, DeployableType.EAR);
ConfigurationFactory configurationFactory = new DefaultConfigurationFactory();
Configuration configuration = configurationFactory.createConfiguration(containerId, ContainerType.REMOTE, ConfigurationType.RUNTIME);
configuration.setProperty("cargo.hostname",hostname);
configuration.setProperty("cargo.remote.username", username);
configuration.setProperty("cargo.remote.password", password);
ContainerFactory containerFactory=new DefaultContainerFactory();
Container container = containerFactory.createContainer(containerId, ContainerType.REMOTE, configuration);
DeployerFactory deployerFactory = new DefaultDeployerFactory();
Deployer deployer = deployerFactory.createDeployer(container);
deployer.redeploy(deployable);
}
When containerId is set to wildfly8x the error message XNIO001001: No XNIO provider found is returned along with the following stacktrace:
org.codehaus.cargo.util.CargoException: Cannot deploy deployable org.codehaus.cargo.container.deployable.EAR[hello-world-ear-0.0.1-SNAPSHOT.ear]
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:216)
at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:245)
at org.jenkinsci.plugins.cargo.CargoDeployer.redeploy(CargoDeployer.java:56)
at org.jenkinsci.plugins.cargo.DeployerRedeploy.perform(DeployerRedeploy.java:97)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1769)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:238)
at org.xnio.Xnio.getInstance(Xnio.java:193)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:101)
at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50)
at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79)
at org.codehaus.cargo.tools.jboss.JBossDeployer.executeAction(JBossDeployer.java:144)
at org.codehaus.cargo.tools.jboss.JBossDeployer.deploy(JBossDeployer.java:84)
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:212)
... 12 more
java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found
at org.xnio.Xnio.doGetInstance(Xnio.java:238)
at org.xnio.Xnio.getInstance(Xnio.java:193)
at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:112)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:101)
at org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50)
at org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79)
at org.codehaus.cargo.tools.jboss.JBossDeployer.executeAction(JBossDeployer.java:144)
at org.codehaus.cargo.tools.jboss.JBossDeployer.deploy(JBossDeployer.java:84)
at org.codehaus.cargo.container.jboss.JBoss5xRemoteDeployer.deploy(JBoss5xRemoteDeployer.java:212)
at org.codehaus.cargo.container.spi.deployer.AbstractDeployer.redeploy(AbstractDeployer.java:245)
at org.jenkinsci.plugins.cargo.CargoDeployer.redeploy(CargoDeployer.java:56)
at org.jenkinsci.plugins.cargo.DeployerRedeploy.perform(DeployerRedeploy.java:97)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:45)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:726)
at hudson.model.Build$BuildExecution.post2(Build.java:185)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:671)
at hudson.model.Run.execute(Run.java:1769)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
In the pom.xml file for my plugin I've included the following dependencies
<dependency>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-core-container-wildfly</artifactId>
<version>1.4.14</version>
</dependency>
<dependency>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-core-container-jboss</artifactId>
<version>1.4.14</version>
</dependency>
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-controller-client</artifactId>
<version>8.2.0.Final</version>
</dependency>
Update: I've done some further investigation and have found this is only an issue when running my code as a Jenkins plugin. If I use the same code in a standalone application then Cargo is able to deploy the EAR file to Wildfly without any problems.

It looks like you have xnio-api.jar but no xnio-nio.jar in the classpath when you run your code as a Jenkins plugin. You can run mvn dependency:tree and look what XNIO version is used and then bundle it with your plugin.

You can add a xnio-nio.jar to your classpath with this dependency in you pom.xml:
<dependency>
<groupId>org.jboss.xnio</groupId>
<artifactId>xnio-nio</artifactId>
<version>3.4.6.Final</version>
</dependency>
See also the version list here: https://mvnrepository.com/artifact/org.jboss.xnio/xnio-nio