Develop Reference

Elasticsearch Client is defaulting to localhost

I am using spring.data.elasticsearch with Elasticsearch 7.14.1 in my Spring Boot (2.5.4) application.
My application.properties is something like this
spring.elasticsearch.rest.uris=elasticsearch:9200
spring.data.elasticsearch.cluster=elasticsearch:9200
spring.data.elasticsearch.repositories.enabled=true
This works fine as long as the invocation is from localhost, no issues. However, when I try to bring up my Spring Boot container, I see a failure with NoReachableHostException
reactor.core.Exceptions$ErrorCallbackNotImplemented: org.springframework.data.elasticsearch.client.NoReachableHostException: Host 'localhost:9200' not reachable. Cluster state is offline.
blah-blah-service
Caused by: org.springframework.data.elasticsearch.client.NoReachableHostException: Host **'localhost:9200'** not reachable. Cluster state is offline.
blah-blah-service
at org.springframework.data.elasticsearch.client.reactive.SingleNodeHostProvider.lambda$lookupActiveHost$3(SingleNodeHostProvider.java:101)
Clearly, my suggestion to use "elasticsearch" host (defined network, that is tested and accessible from within and outside docker containers), hasn't gone well with Spring Data for whatever reason. I have even used
#PropertySource("classpath:mysearch.properties")
in my application to try and coax these properties into the app, but doesn't look like anything works. Is there something I am missing in my Elasticsearch configuration or otherwise?
PS: I have exercised curl http://elasticsearch:9200 from within the container and find no issues

These configurations are Spring Boot specific, Spring Data Elasticsearch does not use them. But as far as I can see, you are configuring the transport client (cluster entry, should not be used anyway) and the imperative REST client, but according to the error message you are using the reactive REST client.
According to the Spring Boot documentation you would need to set spring.data.elasticsearch.client.reactive.endpoints

In the .properties file, I used the below and solved the issue for me;
spring.elasticsearch.rest.uris=http://localhost:<port_number>
spring.data.elasticsearch.client.reactive.endpoints=localhost:<port_number>

How to request https endpoints through quarkus

I am creating endpoint that is dependent on another endpoint,i have created interface and did all of that stuff but when i requested https://example.com to give me info it did not responded and request timeout exception came up.the quarkus is not supporting https request i also have added certificates kindly let me know what i am doing wrong or what i need to do.
quarkus.http.ssl.certificate.file=META-INF/dev.crt
quarkus.http.ssl.certificate.key-file=META-INF/dev.com.key
com.package.xyz/mp-rest/url=https://example.com

You need to specify some properties in your application.properties file:
quarkus.http.ssl-port=8443
quarkus.http.insecure-requests=enabled
quarkus.http.ssl.certificate.key-store-file=keystore.jks
quarkus.http.ssl.certificate.key-store-password=password
Documentation source I used for this was the Quarkus cookbook available from RedHat: https://developers.redhat.com/books/quarkus-cookbook see section 3.8

checking whether spring boot application is running or not

I've created a spring boot project and deployed it on a vm. I've added a command in local.rc that starts the spring boot application on reboot. I want to check whether the command got executed and the application is running. How do I do that?

There are two ways
On system level - you can run your project as a service, which is documented in the Official documentation - Deployments. Then you can query the application status service myapp status.
On application level - include Spring Boot Actuator in your app and use the Actuator endpoints such as /actuator/health as per Official documentation - Production Ready Endpoints. These endpoints can be exposed via HTTP or JMX.
Note: prior to spring boot 2.0 the actuator endpoint is /health

If it's a web project, it makes sense to include spring-boot-actuator (just add a dependency in maven and start the microservice).
In this case, it will automatically expose the following endpoint (for example, its actually can be flexibly set up):
http://<HOST>:<PORT>/health
Just issue an HTTP GET request, and if you get 200 - it's up and running.
If using an actuator is not an option (although it should be really addressed as a first bet), then you can merely telnet to http://<HOST>:<PORT>
The ratio behind this is that that PORT is exposed and ready to "listen" to external connections only after the application context is really started.

How to disable authorization for /restart endpoint?

I try to implement restart feature in my web application.
I've added following dependencies:
compile("org.springframework.boot:spring-boot-starter-actuator")
compile("org.springframework.cloud:spring-cloud-starter:1.2.4.RELEASE")
In start logs I found that post /restart was registered.
I decided to request this url:
But result is fail. I understand that this url should be protected but I have custom authorization/authentication mechanism and I don't have rights to change it.
Is there way to disable protection for this url? A better way - to have service which I can inject inside my controller and invoke. Is there something inside the spring to solve my problem?

Reason is that spring cloud enabled the security for endpoints by default.You need disable security for management (because /restart endpoint is an additional endpoint for management), in properties:
management.security.enabled=false
to remap endpoints from ../restart to /foo/restart, you need to add additional property:
management.context-path=/foo
To implement your custom end point, you just have to implement interface Endpoint and override its methods.
to disable default restart endpoint:
endpoints.restart.enabled=false

try this:
endpoints.restart.enabled = true
management.security.enabled=false

Camel 2.14.0/CXF 3.0.1 Jetty configuration: Protocol mismatch error

We have a couple of web services (REST+SOAP) running in Apache Camel 2.13.0 based on CXF version 2.7.10 which use SSL and basic authentication all the way, which worked pretty fine.
Due to a version upgrade of Camel to version 2.14.0, which internally uses now CXF 3.0.1, our services now stoped working as of a Protocol mismatch for port x: engine's protocol is http, the url protocol is https - the configuration however was untouched during the version-update.
...
Caused by: java.io.IOException: Protocol mismatch for port 8081: engine's protocol is http, the url protocol is https
at org.apache.cxf.transport.http_jetty.JettyHTTPServerEngineFactory.createJettyHTTPServerEngine(JettyHTTPServerEngineFactory.java:271)
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.retrieveEngine(JettyHTTPDestination.java:121)
at org.apache.cxf.transport.http_jetty.JettyHTTPDestination.finalizeConfig(JettyHTTPDestination.java:154)
... 48 more
I therefore created a new eclipse project which simplifies things to its bare minimum (just a simple SOAP service with two endpoints which both use either HTTP or HTTPS).
The configuration of the Jetty server can be seen here
The actual service is configured as bean to later on use this bean within Camel's route:
#Bean(name="endpoint1ServiceSSL")
public CxfSpringEndpoint endpoint1ServiceSSL() throws Exception
{
final CxfSpringEndpoint factoryBean = new CxfSpringEndpoint();
factoryBean.setServiceClass(EnhancedEndpoint1Endpoint.class);
factoryBean.setWsdlURL("classpath:/wsdl/test.wsdl");
factoryBean.setEndpointName(new QName(NAMESPACE, "Endpoint1ServicePort", PREFIX));
factoryBean.setServiceName(new QName(NAMESPACE, "Endpoint1_Service", PREFIX));
factoryBean.setAddress(env.getProperty("services.address.ssl")+"/endpoint1");
factoryBean.setDataFormat(DataFormat.POJO);
final Map<String, Object> properties = new HashMap<>();
properties.put("schema-validation-enabled", "true");
properties.put("allowStreaming", true);
factoryBean.setProperties(properties);
factoryBean.getInInterceptors().add(new LoggingInInterceptor());
factoryBean.getOutInterceptors().add(new LoggingOutInterceptor());
return factoryBean;
}
NAMESPACE and PREFIX are just some constants, nothing important for this example. The bean gets certain values like the service's base address from a property file which just contains values like:
services.address = http://0.0.0.0:8080/
services.address.ssl = https://0.0.0.0:8081/
and other ssl keystore related stuff. Note that CXF will use the jetty configuration beans during its initialization process and therefore create a SSL secured connection for HTTPS invoked URLs - at least it did before the version-upgrade.
The route now can access the service using this very simple route:
public class Endpoint1Route extends RouteBuilder
{
#Override
public void configure() throws Exception
{
from("cxf:bean:endpoint1Service")
.to("log:endpoint1Service");
from("cxf:bean:endpoint1ServiceSSL")
.to("log:endpoint1ServiceSSL");
}
}
This worked well with CXF 2.7.10 and Camel 2.13.0 - but as already stated above, after the upgrade there is a protocol mismatch for some reason (as hopefully can be seen from the github-project I've linked; after cloning the project, you need to execute generate-sources and then start ServicesApp as Java standalone application).
I've also created a new branch for the version-upgrade to simplify the switch between both versions.
Anyone has any idea why the configuration of Jetty, which worked before the version upgrade, now returns this protocol mismatch error? Am I missing any updated libraries I haven't figured out yet? Or am I configuring something wrong in first place?
#Edit:
After further testing I am now sure that some API changes inside CXF led to the problems as the bean which configures the SSL secured Jetty server is no longer executed on startup, while with version 2.7.10 the bean gets executed.
This changes the actual question to "How to configure a SSL secured Jetty Server in Apache CXF 3.0.1"
#Edit #2:
I managed to get a SSL secured Jetty server running in Camel 2.14.0/CXF 3.0.1 but only via XML configuration. As we prefer Java config over XML, we are still looking for a method to configure Jetty with SSL in CXF 3.0.1 - The skip of the jettySSLEngineFactory Spring bean, though, seems like a further CXF bug to me.
To clarify, in CXF 2.7.x a jetty server could get configured in Java on creating a Spring bean which returns a JettyHTTPServerEngineFactory instance, as showcased in the master-branch of the github project linked above. This bean was used by CXF while configuring the server instance and therefore set up the SSL secured Jetty server. However, in CXF 3.0.1 this bean no longer is invoked - only JettyDestinationFactory which I have no clue on how to set up a SSL secured server with. Also the XML example prestended in the docs gives no clue on how to set up Jetty with SSL using a destination factory.
As the engine-factory inside the XML example in the docs actually maps to a JettyHTTPServerEngineFactory and Jetty configuration over XML is working fine, this seems to pinpoint a Spring bean injection bug inside CXF 3.0.1 to me.

As the protocol mismatch error was caused due to CXF skipping the bean initialization of the jetty configuration bean. However, it turned out that through the internal Spring version change in CXF extending a Spring configuration class leads to certain issues.
On removing extends SoapSSLConfig in CxfEndpointConfig and injecting this configuration class using #Import(SoapSSLConfig.class) the bean initialization and therefore the Jetty server configuration is executed as before.
The code used to be:
#Configuration
#ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
public class CxfEndpointConfig extends SoapSSLConfig
{
...
}
which lead to injection failures. Replacing the above code with the below solved the problem.
#Configuration
#ImportResource({ "classpath:META-INF/cxf/cxf.xml" })
#Import(SoapSSLConfig.class)
public class CxfEndpointConfig
{
...
}