We Keep Coding

How do I get data from a Flux in an AbstractGatewayFilterFactory

I have a ReactiveDiscoveryClient that provides a method Flux<ServiceInstance> getInstances(String serviceId). I want to use the result of that method in my GatewayFilterFactory's apply method. However,
ServiceInstance si = reactiveDiscoveryClient.getInstances(config.getServiceId()).block();
fails because the block operations are not allowed. Is there anyway around it?
What I've done is cheat since my ReactiveDiscoveryClient has an in-memory map that contains the services and I just provide an extra method that gets the value I need.

That's rare, as by default, those actions are allowed. From the Spring Cloud Documentation:
27.1. #EnableDiscoveryClient
Spring Cloud Commons provides the #EnableDiscoveryClient annotation. This looks for
implementations of the DiscoveryClient and ReactiveDiscoveryClient
interfaces with META-INF/spring.factories. Implementations of the
discovery client add a configuration class to spring.factories under
the org.springframework.cloud.client.discovery.EnableDiscoveryClient
key. Examples of DiscoveryClient implementations include Spring Cloud
Netflix Eureka, Spring Cloud Consul Discovery, and Spring Cloud
Zookeeper Discovery.
Spring Cloud will provide both the blocking and reactive service
discovery clients by default. You can disable the blocking and/or
reactive clients easily by setting
spring.cloud.discovery.blocking.enabled=false or
spring.cloud.discovery.reactive.enabled=false. To completely disable
service discovery you just need to set
spring.cloud.discovery.enabled=false.
At least for what it's told in the last paragraph, you should be able to perform a block(). Anyway, you could try by setting these params, as should be enough to be allowed to invoke it:
spring.cloud.discovery.blocking.enabled=true
spring.cloud.discovery.reactive.enabled=true
spring.cloud.discovery.enabled=true
Also, not sure if related, but note this warning as well (just in case)

Hystrix runtime configuration with Spring-Cloud-Config instead of Archaius?

I'm studying Spring-Cloud-Netflix and I learned that Archaius was used for Hystrix runtime configuration. (https://ahus1.github.io/hystrix-examples/manual.html#archaius)
I also found that Archaius was a soft-dependency since V1.5.0 (https://github.com/Netflix/Hystrix/pull/1083): "Archaius is now a soft-dependency of Hystrix, so you can supply your own configuration mechanism."
My question is, is it easy to configure Hystrix with Spring-Cloud-Config at runtime? I did some research but haven't found any examples.
Appreciate any ideas.

After several days' research, I managed to dynamically configure Hystrix properties with Spring Cloud Config. I also made a small demo on configuring the Hystrix instance property at runtime.
First, each Hystrix property has four levels of precendence:
Global default
Dynamic global default
Instance default
Dynamic instance property.
Where the 1st and 3rd levels only support static configurations. Since the 2nd level (dynamic global default) was not discussed a lot in the Hystrix Wiki, I choose the Dynamic Instance Property for runtime configuration. However, I believe my method should apply to Dynamic Global Default as well.
The practice is simple. First pull a config value from Spring Cloud Config using the #Value annotation:
#Value("{timeoutInMilliseconds:1500}")
String timeout;
Then use the string timeout in your Hystrix instance:
ConfigurationManager.getConfigInstance().setProperty("hystrix.command.HystrixHelloWorld.execution.isolation.thread.timeoutInMilliseconds", timeout);
Where the ConfigurationManager.getConfigInstance() is an Archaius method, returns a configuration instance. .setProperty() sets the property

How does the EnableAutoConfiguration spring annotation work?

I am no fan of gross over abstractions, And i think Spring has committed a major felony.
But I'm willing to overlook it this time if someone can explain the algorithm behind the 'auto' configuration.
Having a look at spring's own javadocs, It doesn't give much away other than saying that it will intelligently guess what you need and something to do about conditional beans.
Does someone know what algorithm is used to determine what needs to be loaded?

In my experience as a Spring Boot user the basic factors for Spring Boot to decide on what auto-configurations will be enabled are:
1) The classes present on the classpath. For example if RabbitMQ and Spring AMQP classes are present, then the RabbitAutoConfiguration will be enabled. The corresponding annotation is #ConditionalOnClass,
2) The presence or not of user defined beans. For example, if all the Spring Data JPA is present on the classpath, Spring Boot will register a LocalContainerEntityManagerFactoryBean bean only if the user has not already done so. The beans registered by the user will 'override' the default ones. The relevant annotation is #ConditionalOnMissingBean
As #DaveSyer mentions, you can of course use Spring Boot without #EnableAutoConfiguration if you want to include the relevant configuration on your own. Or you could use the less drastic solution of the exclude field of #EnableAutoConfiguration. If for example you want Spring Boot to autoconfigure everything except ActiveMQ, you would use #EnableAutoConfiguration(exclude=ActiveMQAutoConfiguration.class)
In my opinion, there is absolutely no felony here! You can use what you want from Spring Boot. When you don't want something it has to offer, you can easily opt out partially or completely!
Also if you want to get a look under the covers, you can add the property
logging.level.org.springframework.boot=DEBUG
to application.properties and Spring Boot will gladly give a detailed report of what was auto-configured and what wasn't

There is some documentation in the Spring Boot Reference Guide. It's not terribly complicated, and I hardly think it's a felony to just include a bunch of #Configuration that you might have written anyway (because that's all it does). Feel free not to use #EnableAutoConfiguration if you prefer to include the individual configurations individually.

Apache CXF web services problems

I have a multi-module project using Maven. On one of the modules I have several web services developed using Apache CXF Framework 2.5.4. At the moment I have two "problems" or questions.
First of all, if I call to a method of one of the web services that should return a List, if the list is empty, it returns "null" instead of the empty list.
I was trying to find out what could be the problem, if it's a bug of the CXF version I'm using or if I should use some annotation to modify the definition of the method or the response, but I couldn't find anything. I've seen some people with the same problem, but no solution.
The other thing I wanted to ask is: I'm developing a web application using MVC pattern. I'm wondering which way I should call the web service from the Controller instead of using ClasspathXmlCpplicationContext and then context.getBean().
For example, the bean definition for one of the web services on the client side is:
<jaxws:client id="deviceWSClient"
serviceClass="..IDeviceWebService"
address="http://localhost:8080/../DeviceWS" />
I've already tried usin #Autowired or #WebServiceRef annotations. With these it works but not doing a HTTP request to the web service, I guess it gets the dependency from the local repository. I think what I need is the way of injecting this bean on the Controller.

To answer your questions
For your first question: If the list is empty it is correctly handled by CXF version 2.6.1 - the service returns a empty. Just to demonstrate I have a sample service where types are defined this way:
#XmlAccessorType(XmlAccessType.FIELD)
#XmlRootElement(name = "MemberSearchResponse", namespace="http://bk.org/memberservice/" )
public class MemberSearchResponse {
#XmlElementWrapper(name="memberDetails")
private List<MemberDetail> memberDetails;
If I return a empty memberDetails above, the xml that goes over the wire is this:
<ns2:searchMemberResponse xmlns:ns2="http://bk.org/memberservice/">
<ns2:MemberSearchResponse>
<memberDetails/>
</ns2:MemberSearchResponse>
</ns2:searchMemberResponse>
EDIT
It is correctly handled as part of a wrapper type like above, but DOES return null if instead of returning a wrapper type, the list is directly returned.
Consider a Webservice interface defined this way:
#WebMethod(operationName = "searchMember")
List<MemberDetail> searchMember(#WebParam(name = "MemberSearchRequest") MemberSearchRequest memberSearchRequest);
If the List returned is an Empty list, it gets serialized as null by CXF 2.6.1 also.
The workaround is to use a wrapper type
EDIT END
For your second question:
You are creating a client bean this way:
<jaxws:client id="deviceWSClient"
serviceClass="..IDeviceWebService"
address="http://localhost:8080/../DeviceWS" />
Once you have created a Spring bean this way, you can treat it just like a normal Spring bean and inject it the way you would do with any normal Spring bean, for eg, either inject it this way:
<bean id="consumerBean" class="...">
<property name="deviceWS" ref="deviceWSClient">
</bean>
or use #Autowired
#Autowired IDWebService deviceWSClient
Or user #Resource
#Resource IDWebService deviceWSClient
These are the usual ways of injecting in a bean.
I have a sample application at this github location that you can play with:
https://github.com/bijukunjummen/memberservice-codefirst.git
Just start up the server using mvn tomcat:run and run a test org.bk.memberservice.TestCxfIntegrationTest which will make a request to the CXF service.

#WebServiceRef probably works if you follow this link on Spring forum. There you use different way for jaxws configuration. See the last post on the list.
Another ways to define the client are discussed on this SO question. There is e.g a solution where you finally use #Autowired annotation after you have given some extra configuration. See the last answer on the question.
The another issue you mentioned was about this cxf List related issue where also a solution is told for a workaround to the problem. So it is a bug. Version 2.2.7 has it fixed, but again in version 2.2.9 problem is arisen again. Wierd that until your version 2.5.4 it is back on error state. You could try the work around still, if it fixes the issue for you.

Can I use Spring Security annotations in ZKGrails composers?

Can I use Spring Security annotations in my ZKGrails composers to secure the ajax-callbacks, or can/do i have to inject springSecurityService (and check the principal's authorities, in every method manually)?
Update: According to http://felipecypriano.com/2009/10/26/tweak-zk-to-make-event-processing-call-groovys-invokemethod/ , the annotations should work, and I found the modification mentioned in this post in the current ZKGrails plugin version (1.0.4). Still, when I try to secure methods in my composer, they remain fully accessible.

Because "#Secured" annotation is not supported by spring security plug-in. I think you should implement your own method interceptor according http://felipecypriano.com/2009/10/19/enable-secured-annotation-with-grails-spring-security-plugin/ to enable it.