I use springcloud with eureka. now I want to get more information from the center about provider, so How eureka provider carry custom metadata to eureka center? the information shouldn't in the application.properties but generates by the provider.
In springcloud, we can override the default bean which named EurekaInstanceConfigBean by this:
#Bean
public EurekaInstanceConfigBean eurekaInstanceConfig()
in this method, you can fill the metadata as you lik.
it provide springcloud a custom config bean.
reference:http://cloud.spring.io/spring-cloud-netflix/single/spring-cloud-netflix.html#_using_eureka_on_aws
Related
I'm running a Spring Boot Admin server (2.2.2) and using Spring Cloud Kubernetes discovery (with specific service labels to filter) to detect my client apps. None of my client apps are using the explicit Spring Boot Admin Client dependency mechanism.
One of my client apps has a non-standard actuator URL and uses different security credentials to access those endpoints. I understand that I could use static spring cloud discovery with instance metadata to achieve this, but I'd rather use the kubernetes discovery process for all my client apps.
I think by using a custom ServiceInstanceConverter I might be able to override the management context path, but I couldn't see a way to inject custom security credentials via that route.
Is there a better way to customise this kubernetes-driven discovery process? (e.g. can I declare instance metadata somewhere in the client app so that it's picked up even though I'm using Kubernetes discovery - I got the sense from the Spring Boot Admin docs that setting admin properties in clients applied only to the "push registration from client to server" case rather than the "server discovers" case.)
As a related general question, Spring Boot Admin is presumably using some default credential values for accessing actuator endpoints - where are they set up?
Thanks in advance
Alan
I think I figured this out for myself, but in case it's useful to anyone else here is what I did:
Declared custom values for the instance metadata management.context-path, user.name and user.password under the annotations section of the Kubernetes service for my client application.
e.g.
kind: Service
apiVersion: v1
metadata:
name: foo-service
annotations:
# The following are used to support monitoring and administration
user.name: mySpecialUsername
user.password: mySpecialPassword
management.context-path: /foo/manage
From observation it seems that the default credentials assumed by a Spring Boot Administration server are admin/admin.
I don't think it is advisable to put passwords into a service manifest.
The SBA refdoc documents some properties to configure default or per service usernames/passwords.
If this is not an option, you can always add some custom headers to the requests that are sent to the clients:
#Bean
public HttpHeadersProvider customHttpHeadersProvider() {
return (instance) -> {
HttpHeaders httpHeaders = new HttpHeaders();
httpHeaders.add("Authorization", "Basic bXlTcGVjaWFsVXNlcm5hbWU6bXlTcGVjaWFsUGFzc3dvcmQ=");
return httpHeaders;
};
}
Goal:
Call actuators refresh endpoint to reload an override specified in spring cloud config server
Background:
Spring cloud config server provides a way to push out default configuration to all clients through the overrides property (https://cloud.spring.io/spring-cloud-config/single/spring-cloud-config.html#_property_overrides)
spring.cloud.config.server.overrides.foo=bar
Spring actuator provides a /refresh endpoint to reload configuration properties while the application is running.
Problem:
When a new override is pushed into spring cloud config server and the refresh point refreshes that property, the override value is not updated.
Therefore, an update like spring.cloud.config.server.overrides.foo=baz shows baz under actuators /env endpoint, but the clients still see foo=bar.
Question:
Is this just a missing feature of spring cloud config server?
So i am trying to add claims to a service provider in Wso2. I have managed to create an IdentityApplication and connect it with some SSO configuration. The only problem is adding Claims to that SSO because i use those after the SSO login.
So what i have tried so far:
I have added an SSO configuration using the addRPServiceProvider soap function from the IdentitySAMLSSOConfigService
I have created a service provider using createApplication soap function from the IdentityApplicationManagementService and connected it to the SSO configuration i added earlier
At this point my external application connects correctly with Wso2 and do the SSO. The only thing i need is to return additional claim info with the SSO response.
I am trying to do that using the claimConfig part of the createApplication function parameters but i cant seem to make it right.
Is there somewhere some more info about how to set this up through the AdminServices? ( the official docs are not really helping
)
Please refer this documentation for more information on using the API. You can't add the claimConfig during the createApplication call as it only allows you to set the applicationName and description. Set the claimConfig during updateApplication method. The document has a sample request in Claim configuration level parameters section.
I have registered my jax-rs resource classes in my REST javax.ws.rs.core.Applicationclass, registering them in getSingleTons() method.
How can I get programatically reference to my registered resources instances ?
How can I create multiple instances of a bundle that consumes an external webservice?
An external webservice requires clients to logon before using the services. I have multiple accounts. The problem is I want to be able to add multiple instances; one for each account. Each instance is an osgi declarative service that consumes the external service.
Do I have to deploy a new bundle for each account? This does not feel like the right way to solve this.
What you need is multiple instances of an OSGi component or service, not multiple instances of a bundle.
I'd recommend a service factory, where each OSGi config that you create (account parameters in your case) for your service causes a new instance of a service to be created.
Neil Bartlett's tutorial at http://njbartlett.name/2010/07/19/factory-components-in-ds.html looks like a good starting point for that.
Is that bundle under your control - can you refactor it ?
If yes, it might be useful to expose a client factory service, rather than client service itself.
Then each instance can log into a different account.