My goal is to create a strategy of different steps to get from a point-to-point communication between 2 components to a "full blown netflix" style of communication using eureka, ribbon, hystrix. With each iteration I want to add more while I try to limit the amount of changes to the actual code. Feign is my preferred client side framework to make this happen. First step is to create a FeignClient to communicate to the server:
#FeignClient(url = "http://localhost:9000")
interface Client {
#RequestMapping(method = RequestMethod.GET, value = "/author/{author}/addedValue/{addedValue}")
Result addToTotal(#RequestParam(value="author") String author, #RequestParam(value="addedValue") long addedValue);
}
This works but I don't want the URL to be hardcoded in the annotation. I would like to have this: #FeignClient()
and have a properties construct like: client.url: http://localhost:9000
So far I couldn't find any clues on how to configure that and I couldn't find a solution in the spring-cloud sources.
Can it be done and if yes; how?
It can be done with a "serviceId" instead of a "url". E.g.
#FeignClient("foo")
interface Client { ... }
and
foo.ribbon.listOfServers: localhost:9000
e.g. see http://projects.spring.io/spring-cloud/spring-cloud.html#spring-cloud-ribbon-without-eureka for docs.
This can be done like this:
#FeignClient(name="fd-mobileapi-service",url="${fdmobile.ribbon.listOfServers}")
Where fdmobile.ribbon.listOfServers : value is a property in application.properties.
I have tested it and it is working.
I got a way to pass the environment variables in a very simple way interface FeignClient,
#FeignClient(url = "https://"+"\${url}")
interface Client {
#RequestMapping(method = RequestMethod.GET, value = "/author/{author}/addedValue/{addedValue}")
Result addToTotal(#RequestParam(value="author") String author, #RequestParam(value="addedValue") long addedValue);
properties
#URL
url.client=${URL}
.env
URL=https:localhost:9000
Related
I am struggling to set-up infrastructure in my solution to send and retrieve the custom header for REST WCF Service. Basically, we need this to send UserID, password, token value from client to service and if provided values are valid then operation will continue to execute otherwise throw exception.
We already have few classes inherited from interfaces like IDispatchMessageInspector, IClientMessageInspector, IEndPointBehaviour, MessageHeader, etc., This is working fine for WCF with soap request. I tried to use these classes for my new REST WCF Service, but was not working as MessageHeader derived class supports only Soap.
I also tried using WebOperationContext, but no luck :(
Please provide a solution along with sample project to solve this problem.
Thank you so much!
Seems in your case it might be easier to interogate the ASPNET pipeline
if you add the following to your WCF service to allow it to hookup into the ASPNET pipeline
[AspNetCompatibilityRequirements(RequirementsMode =
AspNetCompatibilityRequirementsMode.Allowed)]
Then you can simply now use the HttpContext object and just get the headers as you would from a normal aspnet application, e.g
System.Web.HttpContext.Current.Request.Headers["CustomHeader"]
If you want to add http header in wcf rest service , you should use HttpRequestMessageProperty, it has a Headers property , you could set http Header through its Headers property
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
HttpRequestMessageProperty property;
// if OutgoingMessageProperties already has HttpRequestMessageProperty, use the existing one , or initialize a new one and
// set OutgoingMessageProperties's HttpRequestMessageProperty.Name key's value to the initialized HttpRequestMessageProperty so that the HttpRequestMessageProperty will work
if (OperationContext.Current.OutgoingMessageProperties.ContainsKey(HttpRequestMessageProperty.Name)){
property = OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] as HttpRequestMessageProperty;
}
else
{
property = new HttpRequestMessageProperty();
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = property;
}
// add headers to HttpRequestMessageProperty, it will become the http header of the reuqest
property.Headers.Add(System.Net.HttpRequestHeader.Authorization, "myAuthorization");
string re = client.HelloWorld();
}
About getting the Header , just use WebOperationContext.Current.Headers.
WebOperationContext.Current.IncomingRequest.Headers["MyCustomHttpHeader"]
Please refer to http://kenneththorman.blogspot.com/2011/02/wcf-rest-client-using-custom-http.html
We would like to fetch the payment configuration from Order in Java class (OrderBO extension). So far we have managed to fetch the service like this:
final OrderBOPaymentExtension<OrderBO> paymentExtension = getExtendedObject().getExtension(OrderBOPaymentExtension.EXTENSION_ID);
final PaymentBO paymentBO = paymentExtension.getPaymentBOs().stream().findFirst().orElse(null);
PaymentServiceBO paymentServiceBO = paymentBO.getPaymentServiceBO();
Now we need to fetch the configuration, so we can read certain configuration parameters from the payment method. What is the best way to do that?
We know it is possible to fetch the payment configuration through the PO Factory like this:
PaymentConfigurationPOFactory f = (PaymentConfigurationPOFactory)NamingMgr.getInstance().lookupFactory(PaymentConfigurationPO.class);
PaymentConfigurationPO r = f.getConfigForIDAndDomain(iD, domain);
But we would like to avoid using deprecated code.
UPDATE:
What we are trying to achieve is access these BO parameters in Java code:
I'd suggest you write a PaymentServiceBO extension. Within that extension you can write getter methods to query for certain config values. The java code for accessing service configuration object is:
PaymentConfiguration paymentConfig = paymentServiceBO.getExtension(PersistentObjectBOExtension.class).getPersistentObject();
ServiceConfigurationBO serviceConfigurationBO = repository.getServiceConfigurationBOByID(paymentConfig.getManagedServiceConfiguration().getUUID());
ConfigurationProvider configProviderExtension = serviceConfigurationBO.getExtension(ConfigurationProvider.class);
Configuration configuration = configProviderExtension.getConfiguration();
Logger.debug(this, "payment service config keys = {}", configuration.getKeys());
I believe PaymentConfiguration is deprecated. See PaymentConfigurationBO javadoc:
Deprecated since 7.6. Payment configurations are now represented via PaymentServiceBOs.
So you need to use PaymentServiceBO methods or write a business object extension that does what you want.
I have a Spring Clound Feign Client mapping defined as following
#RequestMapping(method = RequestMethod.GET, value = "/search/findByIdIn")
Resources<MyClass> get(#RequestParam("ids") List<Long> ids);
when I call
feignClient.get(Arrays.asList(1L,2L,3L))
according to what I can see in the debugger, the feign-core library forms the following request:
/search/findByIdIn?ids=1&ids=2&ids=3
instead of expected
/search/findByIdIn?ids=1,2,3
which would be correct for the server Spring Data REST endpoint declared in the same way as my Feign client method.
Thus, because of this issue, the request always returns empty set.
I have seen similar question, but it looks like the Feign client was working as I expect back in 2015.
I am using:
spring-cloud-starter-feign version 1.2.4.RELEASE
feign-httpclient version 9.4.0
feign-core version 9.4.0
Is there a way to correct the behaviour and "marry" the Spring Cloud Feign Client with the Spring Data REST defined endpoints?
I had the same issue with multiple occurence of the parametre instead of the expected comma separated sequence of items. The solution was really simple:
In my feign client I used arrays
feignClient.get(new Long[]{1L,2L,3L})
instead of collection/list:
feignClient.get(Arrays.asList(1L,2L,3L))
In Feign you can annotate your controller with the following
#CollectionFormat(feign.CollectionFormat.CSV) and it will process collections in
the CSV format findByIdIn?ids=1&ids=2&ids=3
Thanks #prola for your answer.
Just to add an explicit example, #CollectionFormat(feign.CollectionFormat.CSV) annotation targets a method; you can't apply globally to your Feign Client interface.
So each method will be similar to:
#RequestMapping(value = ["/objects"], method = [RequestMethod.GET])
#CollectionFormat(feign.CollectionFormat.CSV)
fun findById(
#RequestParam(value = "object.id", required = true) id: String,
#RequestParam(value = "object.fields", required = false) objectFields: List<String> = DEFAULT_FIELDS_LIST,
#RequestParam(value = "format") format: String = FORMAT,
): ResponseEntity<ObjectsDTO>
The result will be
/objects?object.fields=size,weight,location
instead of
/objects?object.fields=size&object.fields=weight&object.fields=location
You can also refer to:
1.16.Feign CollectionFormat support
OpenFeign #542: Support Multiple Collection Formats
I've just battled with this today, and the solution for me was surprisingly simple.
If you use brackets [] for denoting query array:
Resources<MyClass> get(#RequestParam("ids[]") List<Long> ids);
it will create a request that looks like this
/search/findByIdIn?ids[]=1&ids[]=2&ids[]=3
Most server side frameworks will interpret this as an array.
If your server is also in spring then you can pick this up like this
#GetMapping("/search/findByIdIn")
public ResponseEntity findByIdIn(#RequestParam("ids[]") List<Long> ids) { ... }
Just keep in mind that the query has to be encoded, [] gets encoded to %5B%5D.
I am following the directions in the docs, here:
http://grails.org/doc/2.3.8/guide/webServices.html#hypermedia
Why won't grails produce HAL-formatted output, as shown in the documentation?
I have a domain object which I have mapped with the #Resource annotation:
#Resource(uri='/documentCatalogs', formats = ['json', 'xml'], readOnly = true)
class DocumentCatalog {
String entityType
String actionCode
...
}
...and in my conf/spring/resources.groovy, I have configured the HAL JSON renderer beans:
import com.cscinfo.platform.api.formslibrary.DocumentCatalog
import grails.rest.render.hal.HalJsonCollectionRenderer
import grails.rest.render.hal.HalJsonRenderer
// Place your Spring DSL code here
beans = {
halDocumentCatalogRenderer(HalJsonRenderer, DocumentCatalog)
halDocumentCatalogCollectionRenderer(HalJsonCollectionRenderer, DocumentCatalog)
}
Using the debugger, I confirmed that the initialize() method on HalJsonRenderer is called and that it is constructed with the correct targetType.
I send a rest call using Postman:
http://localhost:8080/formslibrary/documentCatalogs/3
Accept application/hal+json
And I get back a response which is regular JSON and doesn't contain any links:
{
"class": "com.cscinfo.platform.api.formslibrary.DocumentCatalog",
"id": 3,
"actionCode": "WITH",
"entityType": "LLP",
...
}
What did I miss? Is there some plugin or configuration setting I have to enable for this behavior? Is there some additional mapping property somewhere that's not documented?
Figured it out! There are multiple aspects of the fix...
I had to add "hal" as one of the listed formats in the #Resource annotation:
#Resource(uri='/documentCatalogs', formats = ['json', 'xml', 'hal'])
Some hunting around in the debugger revealed that Grails will blithely ignore the Accept header, based on the UserAgent string that is sent from the client. (In my case, since I'm using Postman, it was the Google Chrome UA string.)
One workaround for the Accept header issue is to add ".hal" to the end of the URL:
http://localhost:8080/formslibrary/documentCatalogs/3.hal
This isn't a very good solution IMO, since the HAL URLs generated by the renderer don't end in ".hal" by default.
A better solution is to fix Grails' handling of the accept header by updating the config. In Config.groovy, you will see a line that says:
grails.mime.disable.accept.header.userAgents = ['Gecko', 'WebKit', 'Presto', 'Trident']
Change it to:
grails.mime.disable.accept.header.userAgents = ['None']
This forces Grails to honor the Accept header, regardless of the user agent.
Hope this helps somebody else who's hitting the same issue.
P.S. It's really helpful to put a breakpoint in the ResponseMimeTypesApi#getMimeTypesFormatAware(...) method.
I'm upgrading a custom solution where I can dynamically register and unregister Web Api controllers to use the new attribute routing mechanism. However, it seems to recent update to RTM break my solution.
My solution exposes a couple of Web Api controllers for administration purposes. These are registered using the new HttpConfigurationExtensions.MapHttpAttributeRoutes method call.
The solution also allows Web Api controllers to be hosted in third-party assemblies and registered dynamically. At this stage, calling HttpConfigurationExtensions.MapHttAttributeRoutes a second time once the third-party controller is loaded would raise an exception. Therefore, my solution uses reflection to inspect the RoutePrefix and Route attributes and register corresponding routes on the HttpConfiguration object.
Unfortunately, calling the Web Api results in the following error:
"No HTTP resource was found that matches the request URI".
Here is a simple controller that I want to use:
[RoutePrefix("api/ze")]
public sealed class ZeController : ApiController
{
[HttpGet]
[Route("one")]
public string GetOne()
{
return "One";
}
[HttpGet]
[Route("two")]
public string GetTwo()
{
return "Two";
}
[HttpPost]
[Route("one")]
public string SetOne(string value)
{
return String.Empty;
}
}
Here is the first solution I tried:
configuration.Routes.MapHttpRoute("ZeApi", "api/ze/{action}");
Here is the second solution I tried:
var type = typeof(ZeController);
var routeMembers = type.GetMethods().Where(m => m.IsPublic);
foreach (MethodInfo method in routeMembers)
{
var routeAttribute = method.GetCustomAttributes(false).OfType<RouteAttribute>().FirstOrDefault();
if (routeAttribute != null)
{
string controllerName = type.Name.Substring(0, type.Name.LastIndexOf("Controller"));
string routeTemplate = string.Join("/", "api/Ze", routeAttribute.Template);
configuration.Routes.MapHttpRoute(method.Name, routeTemplate);
}
}
I also have tried a third solution, whereby I create custom classes that implement IHttpRoute and trying to register them with the configuration to no avail.
Is it possible to use legacy-style route mapping based upon the information contained in the new routing attributes ?
Update
I have installed my controller in a Web Application in order to troubleshoot the routing selection process with the Web Api Route Debugger. Here is the result of the screenshot:
As you can see, the correct action seems to be selected, but I still get a 404 error.
Update2
After further analysis, and per Kiran Challa's comment below, it seems that the design of Web Api prevents mixing attribute routing and conventional routing, and that what I want to do is not possible using this approach.
I have created a custom attribute [RouteEx] that serves the same purpose of the Web Api [Route] attribute, and now my code works perfectly.
I guess, since this is not possible using the conventional attribute routing, none of the answers on this question could legitimately be consisered valid. So I'm not nominating an answer just yet.
You shouldn't be required to use reflection and inspect the attribute-routing based attributes yourself. Attribute routing uses existing Web API features to get list of controllers to scan through.
Question: Before the switch to attribute routing, how were you loading these assemblies having the
controllers?
If you were doing this by IAssembliesResolver service, then this solution should work even with attribute routing and you should not be needing to do anything extra.
Regarding your Update: are you calling MapHttpAttributeRoutes?