These are chat archives for spring-cloud/spring-cloud

9th
May 2016
Tommy Ludwig
@shakuzen
May 09 2016 04:40
Is it expected that using the Spring Boot parent (1.3.4) and spring-cloud-dependencies BOM (Brixton.RC2) leads to version mismatches of Spring Framework 4.2.5 and 4.2.6? I thought this was fixed by the switch to spring-cloud-dependencies which isn't supposed to declare/manage non-cloud dependencies.
(You can reproduce easily by using Spring Initializr and selecting basically any Spring Cloud dependency with Spring Boot 1.3.4 and look at the resolved Spring framework dependencies)
Stéphane Nicoll
@snicoll
May 09 2016 04:41
There was a glitch in RC1 that @dsyer fixed. Is the mistmatch on spring-core or something else?
Spencer Gibb
@spencergibb
May 09 2016 04:42
Isn't this the ID behavior where you need to include the boot BOM as well?
Stéphane Nicoll
@snicoll
May 09 2016 04:43
No.
Spencer Gibb
@spencergibb
May 09 2016 04:43
Odd not ID
Raj
@rajjaiswalsaumya
May 09 2016 04:43
No
Tommy Ludwig
@shakuzen
May 09 2016 04:43
spring-core is actually the only one that resolves to 4.2.6
Stéphane Nicoll
@snicoll
May 09 2016 04:43
It should work as long as cloud doesn’t bring boot’s dependency management
Tommy Ludwig
@shakuzen
May 09 2016 04:43
spring-context and others all resolve to 4.2.5
Stéphane Nicoll
@snicoll
May 09 2016 04:43
yeah well then that’s the only dependency management problem we haven’t figured out yet
I need to have a look this week. This is really odd and maybe a bug in Maven actually
@shakuzen that’s not new I am afraid, that glitch has been with us since the beginning.
Tommy Ludwig
@shakuzen
May 09 2016 04:46

The following note at the bottom of the Spring Cloud page is what mislead me then. I was under the impression (and thought I tested with M4) that this was fixed by switching to the spring-cloud-dependencies BOM.

NOTE: starting after Brixton.M4 the release train contains a spring-cloud-starter-dependencies as well as the spring-cloud-starter-parent. Use the parent as you would the spring-boot-starter-parent (if you are using Maven). If you only need dependency management, the "dependencies" version is a BOM-only version of the same thing (it just contains dependency management and no plugin declarations or direct references to Spring or Spring Boot). If you are using the Spring Boot parent POM, then you can use the BOM from Spring Cloud.

Stéphane Nicoll
@snicoll
May 09 2016 04:48
Everybody is confused I am afraid
so I am not surprised that you are as well. There are two different issues really
Initially, the cloud BOM/parent was a single pom file and we fix that (can’t remember in which release). There was an additional glitch in RC1 that got fixed in RC2
but the spring-core thing has always been there but was left unnoticed for quite some time.
Tommy Ludwig
@shakuzen
May 09 2016 04:58
I see. So is this something that will be fixed before Brixton GA? Otherwise, Brixton GA only works out of the box with framework 4.2.6 and to use a new bugfix version of the framework, an explicit import of the framework BOM (before the cloud BOM) would be required, right? Assuming one is using the Boot Parent
Stéphane Nicoll
@snicoll
May 09 2016 04:59
you can fix it now by adding boot’s BOM before cloud’s bom. I have no idea if that will be fixed before GA. If that’s a bug in Maven, we’ll have to wait for 3.4 (assuming they’ll fix it)
Tommy Ludwig
@shakuzen
May 09 2016 05:01
Yes, that should work. I just didn't want to also declare the boot BOM, since I'm already using the parent, and that isn't something generated by initializr out-of-the-box. Not ideal, but it'll work for now. Thank you for the advice @snicoll
Stéphane Nicoll
@snicoll
May 09 2016 05:02
We already submitted a bug in Maven regarding the bom override (yet another issue) and that’ll be fixed in 3.4
Maybe we’ll switch to parentless + bom import on start.spring.io. We’re still discussing that issue and haven’t decided yet
Tommy Ludwig
@shakuzen
May 09 2016 05:03
I saw that one from Dave's blog post.
Yea, it's certainly not easy to work out what is best in the general case here.
Stéphane Nicoll
@snicoll
May 09 2016 05:04
exactly. and start.Spring.io generates like a crazy amount of projects every month so if we change it, we better be right
Spencer Gibb
@spencergibb
May 09 2016 05:04
:+1:
Tommy Ludwig
@shakuzen
May 09 2016 05:04
I'm all for getting it right :)
Koizumi85
@Koizumi85
May 09 2016 09:38
hi guys... did you make any changes in the last few days which could cause that it is no longer possibly to clear the "sensitive-headers" list in a zuul proxy route like the following:
zuul:
  routes:
    user-service: 
      service-id: user-service
      path: '/user-service/**'
      sensitive-headers:
it worked last week (and several weeks before), but with the actual snapshot builds, the Authorization header seems to be dropped in zuul proxy
Koizumi85
@Koizumi85
May 09 2016 09:48
Setting "sensitiveHeaders: SomeUnusedHeaderName" works, but is... dirty... ^^
Dave Syer
@dsyer
May 09 2016 09:58
Nothing changed in Spring Cloud as far as I know
Maybe Spring Boot 1.3.4
does something differently
Koizumi85
@Koizumi85
May 09 2016 09:59
hmm.. so you did update to 1.3.4 in the latest snapshots?
then this could be possible
Dave Syer
@dsyer
May 09 2016 09:59
Should be easy to test
Stéphane Nicoll
@snicoll
May 09 2016 09:59
@Koizumi85 you could also use 1.3.3.RELEASE locally (override spring.version)
this doesn’t ring a bell
Dave Syer
@dsyer
May 09 2016 10:00
Not with me either
Koizumi85
@Koizumi85
May 09 2016 10:00
@snicoll yes. but I think then I will ask on the spring-boot channel and live with the "sensitiveHeaders: SomeUnusedHeaderName" workaround for now ^^
Stéphane Nicoll
@snicoll
May 09 2016 10:00
I don’t think asking on the boot channel will help
I would reply you exactly the same thing there. If you try with 1.3.3 and it doesn’t break, we can follow up there
I meant use 1.3.3.RELEASE for testing, not as a solution to your issue
Koizumi85
@Koizumi85
May 09 2016 10:01
okay... then I will try it out later and give you feedback ^^
Dave Syer
@dsyer
May 09 2016 10:05
I can't see any difference with 1.3.4
Koizumi85
@Koizumi85
May 09 2016 10:07
@snicoll @dsyer can't be 1.3.4... just saw, that we fixed spring boot on 1.3.3 at the moment...
but 5 days ago there was a commit in spring-cloud-netflix which changed something in sensitive-headers behaviour: spring-cloud/spring-cloud-netflix@ea1a4c5
Dave Syer
@dsyer
May 09 2016 10:10
That's probably it then
Do you want to propose a fix?
It looks like all you need as a workaround (or possibly longer term) is to set the default value to empty.
Koizumi85
@Koizumi85
May 09 2016 10:12
yes... seems so.. but this would cause, that I would have to add the sensitive-headers on all other microservices (because there I want to remove them from the request)
Dave Syer
@dsyer
May 09 2016 10:13
Yeah
I guess we need to make the default value null in the individual route
and then check for null in the filter
Koizumi85
@Koizumi85
May 09 2016 10:14
hmm... so null means "apply default values" and empty list means "don't apply any sensitive-headers"?
Dave Syer
@dsyer
May 09 2016 10:14
Yes
Either that or we would add a flag "enableDefaultSensitiveHeaders" or something
per route
Koizumi85
@Koizumi85
May 09 2016 10:15
yes.. thought about a new flag too...
would be clearer I think?
Dave Syer
@dsyer
May 09 2016 10:16
Not sure
It's only needed when the supplied value is empty
which seems a bit awkward
Koizumi85
@Koizumi85
May 09 2016 10:16
yes.. I agree
Dave Syer
@dsyer
May 09 2016 10:19
I think it would be better to encapsulate the concern inside Route
Can you open an issue please?
Koizumi85
@Koizumi85
May 09 2016 10:19
yes
Koizumi85
@Koizumi85
May 09 2016 10:28
here it is: spring-cloud/spring-cloud-netflix#1012
Enough informations or did I forget something?
Dave Syer
@dsyer
May 09 2016 10:28
That's fine. I get it.
Koizumi85
@Koizumi85
May 09 2016 10:28
okay. thanks :)
KenavR
@KenavR
May 09 2016 20:10

@KenavR

Hi, I am trying to structure my app using microservices, I have a Eureka instance and register clients with @EnableDiscoveryClient. The eureka server endpoint tells me that the service is successfully registered, but when I try calling the service with a RestTemplate I get java.net.UnknownHostException: My-Service. Does anyone have an idea what could be the issue?

Hi, I posted this a couple of days ago, but only had now time to take a look at the suggested solutions, sadly I couldn't get it to work. I created an example repo where I reproduced my error, maybe someone could take a look at it. - https://github.com/KenavR/spring-boot-microservices-example thanks

Spencer Gibb
@spencergibb
May 09 2016 20:18
@KenavR I might be able to take a look today. That error means that rest template didn’t translate the serviceid “hostname” to a real host and port. I’ll have to look to se why.
KenavR
@KenavR
May 09 2016 20:19
thanks, really appreciate it
Daco
@dacofr
May 09 2016 22:51
Hi SpringCloud team, any idea how to i can workaround this issue spring-cloud/spring-cloud-netflix#918 cc @dsyer @spencergibb