Cannot reference to bean ElasticSearch - elasticsearch

I have one question, because I can't find anywhere information which version of elasticsearch is compatible with 1.5.2.RELEASE spring boot app generate by jhipster.
Everything works perfectly when I run it on windows with properties in my application-dev.yml
elasticsearch:
cluster-name:
cluster-nodes:
properties:
path:
logs: target/elasticsearch/log
data: target/elasticsearch/data
On production I have only warning that my app cant connect with elasticsearch service. It is normal, because I didn't run it on port 9300... But I have another problem. When I try deploy it to my linux server (debian) I have several errors 'Cannot resolve reference to bean elasticsearchTemplate' and another errors with nested exceptions etc... all errors about elasticsearch and constructor parameters.
I tried download elasticsearch on widows and test it, so I done it. I downloaded elasticsearch version 5.4.1 and configured it... But it is still invisible for my web app.
My actually property for elastic is
elasticsearch:
cluster-name: elasticsearch
cluster-nodes: localhost:9300
Any solutions and suggests?
Thanks

You don't need to worry about versioning, because that's the work of spring-boot.
Spring Boot -> Dependency management
Each release of Spring Boot provides a curated list of dependencies it supports. In practice, you do not need to provide a version for any of these dependencies in your build configuration as Spring Boot is managing that for you. When you upgrade Spring Boot itself, these dependencies will be upgraded as well in a consistent way.
And back to JHipster as noted in the Elasticsearch documentation:
Using in Production
In production, JHipster expects an external Elasticsearch instance. By default, the application looks for an Elasticsearch instance running on localhost. This can be configured by using the standard Spring Boot properties, in the application-prod.yml file.
When you create a JHipster project and specify that will be using ElasticSearch than a docker configuration file is created under /src/main/docker/ named elasticsearch.yml containing:
version: '2'
services:
jhipsterelasticsearchsampleapplication-elasticsearch:
image: elasticsearch:2.4.1
# volumes:
# - ~/volumes/jhipster/jhipsterElasticsearchSampleApplication/elasticsearch/:/usr/share/elasticsearch/data/
ports:
- 9200:9200
- 9300:9300
The above example is extracted from an example of an ElasticSearch project by JHipster team at jhipster-sample-app-elasticsearch
So before starting your app on production make sure that you have started ElasticSearch instance. A solution is to start it with docker-compose and you can use that config file like this: docker-compose -f path-to/elasticsearch.yml up -d

Related

Spring Boot 2.7.8 or 3.x upgrade - Tomcat HTTP Status 404 - Not Found on Azure

I'm currently upgrading an application from Spring Boot 2.7.7 to Spring Boot 3.0.2 and hit a 404 at the tomcat.
The interesting thing is that the application works fine on my local machine, but not in the Azure Cloud.
I have the log-level set to DEBUG for org.springframework.web and with Spring Boot 2.7.7 I see the call received in the logs (on Azure) for actuator/info, whereas in Spring Boot 3 I see the application starting successfully but then no further logs.
Any ideas what it could be or what I can try out to debug further?
The problem is related to a change in Tomcat version in Spring 2.7.8 (and therefore also Spring Boot 3.x) in relation to the Java-Agent used in Docker / within Azure.
Update to the latest java-agent version in the Docker-Image:
DockerFile
FROM eclipse-temurin:17
COPY "myBuiltApplication.jar" "app.jar"
ADD "https://github.com/microsoft/ApplicationInsights-Java/releases/download/**3.4.8**/applicationinsights-agent-*3.4.8*.jar" "agent.jar"
EXPOSE 80
ENTRYPOINT [ "java", "-javaagent:agent.jar", "-jar", "app.jar"]
Make sure that no other agent is active from Azure
I had to remove the JAVA_TOOL_OPTIONS and StartupBootstrapper from the docker run:
- docker run -d --expose=80 --name myapp
JAVA_TOOL_OPTIONS=-javaagent:/agents/java/applicationinsights-agent-codeless.jar -e StartupBootstrapper=Microsoft.ApplicationInsights.StartupBootstrapper -e
I experienced the same issue with Spring Boot version 2.7.8 with the exact same behavior: Starting the app local in IDE as well as starting the docker image locally worked perfect. When running this image in Azure as an App Service no http call is going to spring. For me it looks like Tomcat has an issue as the 404 seems to be produced by Tomcat.
Downgrading to Spring Boot 2.7.7 fixed the issue again.

ELK APM Framework - APM Server identity could not be verified

I am trying to integrate my application with the APM Framework. I've already done it for a series of other applications and everything worked accordingly. This specific Java SpringBoot application gives me the following error:
I've checked that the TLS certificate is valid in the container that the application is running. As I understand TLS 1.2 is used everywhere. I have checked and updated some http dependencies (okhttp) in case there was an issue with TLS there. No luck. I've checked that the APM SECRET TOKEN I am using is the correct one - and validated the APM environmental variables I've enetered.
I am calling ElasticApmAttacher.attach(); on the main of my Application class.
I have a elasticapm.properties file as follows:
enable_log_correlation=true
service_name=my-api-name
The following env vars:
ELASTIC_APM_APPLICATION_PACKAGES=my_classpath_here
ELASTIC_APM_SERVER_URL=apm_addresss_here
ELASTIC_APM_SECRET_TOKEN=token_here
Any ideas for what more to look for will be greatly appreciated.
I added the following env var:
ENV JAVA_OPTIONS=“-Dhttps.protocols=TLSv1.1,TLSv1.2”
Dockerfile base image change:
from java:8-jdk-alpine to openjdk:8u272-jdk
And it worked.

Google App Engine ignoring Springboot application properties

I'm deploying a pretty basic web app to Google App Engine. I'm using Springboot and I can run the app locally just fine, but when I deploy to Google, the App Engine does not start up the instance. I have a Cloud SQL datasource being configured on startup.
I have the cloud sql configuration properties configured in src/main/resources/application.properties. It seems that App Engine cannot find these properties so it is failing to properly setup the Cloud sql datasource.
Has anyone ran into this issue? It seems like something so basic. I'm hoping a second pair of eyes and brain can shed some light. Thanks!
EDIT:
Thank you for your responses. Here is a snippet of the properties file:
#################### DATABASE SETTINGS
#POSTGRES connection parameters
application.postgres.driver-name=org.postgresql.Driver
application.postgres.url=jdbc:postgresql://<url>:5432/<db>
application.postgres.max-pool-size=5
application.postgres.min-pool-size=1
application.postgres.connection-wait-time-seconds=60
application.postgres.schema=dev
application.postgres.preparedstatement-cache-queries-size=256
application.postgres.preparedstatement-cache-size=500
application.postgres.preparedstatement-cache-sql-limit=5
application.postgres.preparedthreshold=5
application.postgres.ssl.enabled=true
#################### GOOGLE CLOUD SETTINGS
application.google.project.id=<our project>
application.google.project.region=us-central1
application.google.project.cloud.sql.instance.name=<cloud sql instance>
application.google.project.cloud.sql.instance=${application.google.project.id}:${application.google.project.region}:${application.google.project.cloud.sql.instance.name}
I have this located in the src/main/resources (as usual).
I've tried running in a flex and standard environment. I wanted to make sure one or the other wasn't causing the issue.
my appengine-web.xml looked like this for the standard env:
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>my app name</application>
<service>my service name</service>
<version>1</version>
<threadsafe>true</threadsafe>
<runtime>java8</runtime>
</appengine-web-app>
And here was my yaml file for the flex environment (nothing fancy. pretty bare bones setup.):
runtime: java
env: flex
service: my service name
handlers:
- url: /.*
script: this field is required, but ignored
I would post the stack traces, but they are not very helpful. It's basically just the error that I cannot load my cloud sql datasource (ie: because it's not picking up the properties). If I hardcode the values in my Config class that initializes the datasource, it works so I can definitely tell it's just not wanting to pick up the application.properties).
My app setup is typical:
src/main/java
src/main/resources
src/main/webapp
*src/main/appengine (yaml location for flex env)
Note: I'm attempting to pass the postgres (ie: cloud sql) username and password in my maven deploy command:
mvn package -DskipTests appengine:deploy -Dapp.deploy.projectId=myproject -Dapp.deploy.version=1 -Dapplication.postgres.username= -Dapplication.postgres.password=
I faced the similar issue. just add the following in app.yml
resources:
cpu: 2
memory_gb: 3
disk_size_gb: 10
volumes:
- volume_type: tmpfs
size_gb: 2
name: ramdisk1

Intellij, Spring dev tools remote, Docker, error Unexpected 404 response uploading class files

Im trying to use Spring Boot Dev tools (Spring Remote), and automatically upload recompiled files to my docker container.
I keep receiving
Unexpected 404 response uploading class files
This is my docker file:
FROM java:8
WORKDIR /first
ADD ./build/libs/first.jar /first/first.jar
EXPOSE 8080
RUN bash -c 'touch /first/first.jar'
ENTRYPOINT ["java","-Dspring.data.mongodb.uri=mongodb://mongodb/micros", "-Djava.security.egd", "-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005","-jar", "first.jar"]
This is my configuration and the configuration
And this is the error I'm receiving:
As of Spring Boot 1.5.0, devtools defaults were changed to exclude the devtools from fat jars.
If you want to include them, you have to set the excludeDevtools flag to false.
However, the devtools documentation doesn't explain how to do this. The necessary documentation is actually in the spring-boot-gradle-plugin documentation.
To do it, you can put this snippet of code in your build.gradle file:
bootRepackage {
excludeDevtools = false
}
Unfortunately, this was buggy at first and had no effect as of Spring Boot 1.5.0. The workaround was to do this instead:
springBoot {
excludeDevtools = false
}
However, I have verified that the bootRepackage approach works for Spring Boot 1.5.8 .
I got the same issues as yours while using docker-compose to compose my application ( a web service + redis server + mongo server ).
As the Spring developer tools document point out "Developer tools are automatically disabled when running a fully packaged application. If your application is launched using java -jar or if it’s started using a special classloader, then it is considered a “production application”."
I think when we running Spring Web Application inside Docker container, the developer tool is disabled then we cant remotely restart it.
Currently, I'm running my web application on the host machine and set the redis server, mongo server inside containers so I can restart the web app quickly when the code is changing in development process.
In my case I had to put the application context on the argument of the IDE RemoteSpringApplication configuration.
For example, my application root context was /virtue so I had to configure it like so:

spring boot takes like forever to start up in Openshift

I'm running a spring boot 1.4.3 app in openshift origin 1.3.
It takes more than 20 minutes to bring spring bootup.
the docker base container I'm using is alpine:3.4 with opendk8-jre.
the spring boot embedded container is using default tomcat one. I've installed the haveged and set -Djava.security.egd=file:/dev/./urandom
but if I run the image itself with docker run(I'm not using openshift), it can start up..
any idea why ?
Could it be the case that you don't have a maven proxy setup and are downloading all dependencies?
If it's the case your logs likely show that you are donwloading the same deps over and over.
run this command to see the logs:
oc logs _POD_NAME_
Also, have you tried the same in OpenShift Dev Preview and got similar results?

Resources