I've got a Spring Boot application that uses AOP rules. These rules depend on application properties.
Now I have to make this application use Spring Cloud Config Server. But the problem is - AOP rules demand properties before my application fetches configuration from the Config Server. Is there any way to fetch properties from the server before AOP rules are being resolved?
Did you put Spring Cloud Config server properties in bootstrap.properties or bootstrap.yml?
Related
I am using apache camel as my integration framework. I need to modify routes in runtime, So I am trying to read camel context and routes from database. I am developing a spring boot app. Is there any way to read routes from database and add to my spring boot app.
I have a react frontend project and I am using mongo DB as my database. I want to implement rest api with both spring boot and express JS. It means some of the api calls should done by spring boot and others should done by express js. Is there any option to do this?
I don't see why not. You will have two separate servers running - one NodeJS + ExpressJS, and the other would be Spring Boot. Your client does not need to know what the implementation of these servers are (i.e. Spring Boot, ExpressJS, Java, Python, whatever). The client will just need the URL of the endpoint that is being served by your servers.
This is the beauty of REST - de-coupled client and server.
I am trying to deploy a jax-ws webservice on Websphere 8.5.5.12. I am using CXF as my jax-ws engine. I have gone through the prerequisites and changed the class loader as well as desabled the JaxWs engine in websphere. I have set the property to disable Jax-WS engine in the manifest file of my war file.
My application is a Spring boot application. I am also using apache camel 2.20.1 and using the cxf end point to consume the messages.
As a spring boot application my application is working fine.
When I deploy on Websphere my application starts without any issues. But when it intercepts any incoming requests, it throws class not found exception for javax.servlet.WriteListener class. This class is part of the servlet api. It should have been part of the Websphere j2ee library.
Need to know what I did wrong. I don't want to take the shared library route. I have been suggested, that I need to move all my cxf dependencies, into a shared library and set my class loader for this library. I am not comfortable with this solution.
javax.servlet.WriteListener is a Servlet 3.1 / Java EE7 API.
WebSphere Application Server 8.5.5 implements Servlet 3.0 / Java EE6.
You should use either WebSphere Application Server 9.0.0.x or any recent WebSphere Liberty release (which has been versioned differently for quite some time).
(or, remove the 3.1 dependencies from your app if you must run it on WebSphere Application Server 8.5.5)
Related Reference Issue: Redeploying OpenAPI spec into App Engine standard environment
When using Cloud Endpoints via App Engine, what would be the best way to approach continuous deployments? If the OpenApi spec changes, the backend service tied to the endpoint needs to be redeployed meaning that modifications to a "v1" of an endpoint would require downtime in the service while the service is in deployment.
Does this mean that any time a new spec is generated a "breaking change" occurred and I should increment the version, redeploy the backend service, and update the url on any services that use that endpoint to allow more seamless transitioning in modifications to the endpoint? Because as of now working with endpoints I'm having trouble seeing in what instances redeploying the spec doesn't break the backend service and vice-versa.
I realized that when a new spec is generated, there is an ENDPOINTS_SERVICE_VERSION that is generated which seems to be persistent. So the act of deploying a new spec does not cause a breaking change in the API endpoint AFAIK as the backend service will still be pointing to a valid previous deployment.
I don't know how many ENDPOINTS_SERVICE_VERSIONs are persistent as I could not find this in the docs but if the backend service is updated with the latest endpoint service version soon afterwards, updates to the api can be seamless without disruption of the service as far as deployments go.
I'm trying to solve some of my question regarding the architecture of a system consisting of the following:
AngularJS web application frontend
MapServer generating & serving map images through WMS
Lumen REST API backend containing all the business logic
PostgreSQL database with PostGIS to store spatial data
Which is the proper way to dockerize that kind of stack?
Currently i'm thinking of the following containers to be created:
Web Server containing:
Apache web server
AngularJS frontend application
Map Server containing:
Apache web server with CGI support
MapServer CGI application
MapCache/TileCache
Application Server container:
Apache web server
Lumen API backend
Database containing:
PostgreSQL relational database
PostGIS add-on
The list of components of each container has not been yet finalized, so some of them may not fit exactly where they have been placed. For example, should Apache be on a separate container?
Let's think about docker philosophy, Microservices.
Microservices is an approach to application development in which a
large application is built as a suite of modular services. Each module
supports a specific business goal and uses a simple, well-defined
interface to communicate with other modules.
Meaning we need to split our system into microservices, and put each microservice into a container. This will help you significantly when you try to upgrade your application.
In your case, I would separate apache from angular js container.