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

8th
Jul 2016
Dave Syer
@dsyer
Jul 08 2016 07:17
@JonathanAaron no, it doesn't (normally anyway). But the 404 is coming from eureka server isn't it?
I think it should try to update the registration. So actually maybe that involves unregistering.
It's not really clear where you see that log and when
David Steiman
@xetys
Jul 08 2016 08:46
good morning :)
one think I was talking about yesterday is described here: spring-cloud/spring-cloud-netflix#1100
this is not really solving my annotation problem, but when using feign clients as described in docs, you cant really configure more then one client
Dave Syer
@dsyer
Jul 08 2016 09:08
Thanks
That's probably a bug
I'm going to look now
David Steiman
@xetys
Jul 08 2016 09:20
i am currently building a small setup
Dave Syer
@dsyer
Jul 08 2016 09:28
Great
I'll wait for that
Tomasz Juchniewicz
@tjuchniewicz
Jul 08 2016 09:39
Hi All. Anyone can fix this pom: https://repo.spring.io/release/org/springframework/cloud/spring-cloud-starter-parent/Brixton.SR2/spring-cloud-starter-parent-Brixton.SR2.pom (SNAPSHOT dependency inside). Probably some manual work is needed. It stops me from testing Spring Cloud Brixton SR2 ;-)
Dave Syer
@dsyer
Jul 08 2016 09:41
Sorry about that.
We can't really change SR2 now (it's in Maven Central)
SR3 is coming today (probably)
Tomasz Juchniewicz
@tjuchniewicz
Jul 08 2016 09:42
OK. I will wait for SR3. Thanks!
Dave Syer
@dsyer
Jul 08 2016 09:43
Actually it's fixed in Maven Central isn't it?
I can try and make sure the one in Artifactory is the same as Maven Central if that helps
Tomasz Juchniewicz
@tjuchniewicz
Jul 08 2016 09:45
Yes it is fixed in Maven Central but I'm using repository repo.spring.io currently as a main repo
I can wait for SR3
This is not a problem for me
Dave Syer
@dsyer
Jul 08 2016 09:47
It's fixed now anyway
$ curl https://repo.spring.io/release/org/springframework/cloud/spring-cloud-starter-parent/Brixton.SR2/spring-cloud-starter-parent-Brixton.SR2.pom | grep SNAPSHOT
Tomasz Juchniewicz
@tjuchniewicz
Jul 08 2016 09:49
Thanks!
David Steiman
@xetys
Jul 08 2016 10:38
well...we are still on looking for how to reproduce the feign clients problem....which suddenly works...so we try to figure out what is going wrong there...but
my annotation error is easily reproducable
the SpringClient is annotated with a meta-annotation @CustomFeignClient
@CustomFeignClient(name = "spring", url = "https://spring.io")
if you change name to value, the attribute never reaches FeignClient
David Steiman
@xetys
Jul 08 2016 10:44
#1100 is present in a greater setups, but I don't know at the moment, what is causing that....its some more code, i shared it yesterday to you....there both errors occur, the value attribute and that the SecondFooClient is still on accessing the oauth endpoint to fetch a token, despite a empty feignconfiguration is set explicitly
Dave Syer
@dsyer
Jul 08 2016 11:00
I think the issue there is just that you are component scanning all the feign configs
Your test passes for me anyway
Is there supposed to be a failing test?
David Steiman
@xetys
Jul 08 2016 11:01
yes, as i provide false oauth creds
but change name to value, then it fails on bean creation
Dave Syer
@dsyer
Jul 08 2016 11:02
Well the test passes for me as it stands
Maybe it's fragile enough to fail for you and not for me
Your component scan is definitely wrong
David Steiman
@xetys
Jul 08 2016 11:02
in which application?
Dave Syer
@dsyer
Jul 08 2016 11:02
You are scanning all of your configurations into the main context
xetys/FeignBugDemo
David Steiman
@xetys
Jul 08 2016 11:02
FeignBug or app3=
ok

@ComponentScan(basePackages = "com.example.client")

isn't that saying to scann down from that pkg?

Dave Syer
@dsyer
Jul 08 2016 11:03
Yes
But you have @SpringBootApplication as well
which scans all packages
David Steiman
@xetys
Jul 08 2016 11:04
ok right...but this app is showing the annotation problem...the scanning works here for me....but when you go to SpringClient and change "name" to "value", then it fails
i pushed the working state
not the failing
Dave Syer
@dsyer
Jul 08 2016 11:04
Well don't rely on that component scan
David Steiman
@xetys
Jul 08 2016 11:04
is that not happening with your clone?
Dave Syer
@dsyer
Jul 08 2016 11:05
I get green tests on master
David Steiman
@xetys
Jul 08 2016 11:05
ok wait
Dave Syer
@dsyer
Jul 08 2016 11:06
Probably google.com/ is not protected
so it doesn't matter that you are sending bad credentials?
David Steiman
@xetys
Jul 08 2016 11:06
i pushed again
so now its failing
Dave Syer
@dsyer
Jul 08 2016 11:07
Yes
But not the feign configuration problem
David Steiman
@xetys
Jul 08 2016 11:07
yes
Dave Syer
@dsyer
Jul 08 2016 11:07
The context won't start
David Steiman
@xetys
Jul 08 2016 11:07
the annotation problem
Dave Syer
@dsyer
Jul 08 2016 11:07
You have a workaround for this one right?
David Steiman
@xetys
Jul 08 2016 11:08
the configuration problem is in app3, and it seems to be a bug on my side...
the work around is not to use value
Dave Syer
@dsyer
Jul 08 2016 11:08
OK. I'll assume that the other problem (#1000) is pilot error and we can concentrate on the custom attribute aliases
David Steiman
@xetys
Jul 08 2016 11:10
in app3 from yesterday, i got the configuration bug, where as soon my custom annotation gets loaded and loads itself the custom feign configuration, than this configuration is applied to all feign clients
despite the fact, the custon feign configuration is not visible to component scan, and additonally banned with exludedFilter on top
Dave Syer
@dsyer
Jul 08 2016 11:11
Well I haven't seen that bug yet.
There's no failing test at least.
David Steiman
@xetys
Jul 08 2016 11:11
the same happens, when i remove my custom annotation, and directly use that config inside @FeignClient
I didn't manage it to reproduce that in my FeignBug application yet
Dave Syer
@dsyer
Jul 08 2016 11:12
I think you must have the feign config in your parent context.
David Steiman
@xetys
Jul 08 2016 11:12
btw...a "little" bug is still present: xetys/FeignBugDemo@2d6cedd
Dave Syer
@dsyer
Jul 08 2016 11:12
If you can reproduce it we can fix it I guess
David Steiman
@xetys
Jul 08 2016 11:13
there i am using two different logger levels
but actually one wins the match
the tests are green, but you can see that on log
it's not that big fish bug from yesterday, but at least reproducable in simple setup
Dave Syer
@dsyer
Jul 08 2016 11:14
I only see logs from the Spring client I think
Is that expected?
David Steiman
@xetys
Jul 08 2016 11:14

but this is okay, since at the moment the doc is warning that both Logger.Level and RequestInterceptor are still not "really" supported by spring
if i interpret this section correctly:

"Spring Cloud Netflix does not provide the following beans by default for feign, but still looks up beans of these types from the application context to create the feign client"

on master, yes
if you checkt out that commit i pushed, you should see 2 logs, both showing the feign headers
but one clientconfiguration has level "FULL"
and this gets ignored...
Dave Syer
@dsyer
Jul 08 2016 11:16
I don't see any logs from the google client in any case
and the Spring one only logs what I tell it
(changes in the google one don't affect it)
David Steiman
@xetys
Jul 08 2016 11:19
feigntests.png
this is how it looks at me
i checked out the commit hash 2d6cedded5cc6e4eeb62aa12a23bf80be78a5b05
the google client should log the body, too
Dave Syer
@dsyer
Jul 08 2016 11:22
That's weird then
I don't see any output from the google client at all
I think the value= bug is in Spring
David Steiman
@xetys
Jul 08 2016 11:23
ok
Dave Syer
@dsyer
Jul 08 2016 11:23
AnnotationMetadataReadingVisitor is supposed to deliver all the attributes but it doesn't
David Steiman
@xetys
Jul 08 2016 11:23
but if you dont see any output, this is even more wrong
Dave Syer
@dsyer
Jul 08 2016 11:23
Can you raise an issue in Spring JIRA?
We can sort out there whether we interpreted the contract right (and there's a bug)
Now I'll check the log configuration thing...
David Steiman
@xetys
Jul 08 2016 11:24
ok i will do that...
Dave Syer
@dsyer
Jul 08 2016 11:26
I think you've still got some issues with the component scan somehow
Maybe an old class file in your classpath or something
When I allow the google client to actually connect (remove the OAuth configuration) it logs stuff
and I can configure it independently to the Spring client
David Steiman
@xetys
Jul 08 2016 11:27
you should have any Oauth in that commit
i added it later
maybe gradle clean?
it really looks like you are testing the master, not the commit
David Steiman
@xetys
Jul 08 2016 11:39
ok, i reproduced #1100 now
but it is tricky to setup
in short...while using feign with hard wired urls...it works as expected
but when i use my own oauth2 server and a second app, and setup feign not with "url" but with "name" to get the url for the service, the configuration issue
Dave Syer
@dsyer
Jul 08 2016 11:48
I see oauth stuff in master
David Steiman
@xetys
Jul 08 2016 11:49
yes, and i was talking about commit 2d6cedded5cc6e4eeb62aa12a23bf80be78a5b05
i am trying to setup a test showing the #1100 issue
it is present, when feign is discovering the services
it working for hard wired urls
Dave Syer
@dsyer
Jul 08 2016 11:51
OK, but 2d6ced has the component scan issue
(you scan everything)
I'm not sure I can reproduce the problem even looking at that commit
Let me know when you have something new
David Steiman
@xetys
Jul 08 2016 11:55
i have
as i said...#1100 is reproducable
i am on the tests right now
Dave Syer
@dsyer
Jul 08 2016 11:56
Thanks
David Steiman
@xetys
Jul 08 2016 11:56
writing a test that setups 3 apps with SpringAPplicationBuilder is not that fast :D
i hope it will work there
Dave Syer
@dsyer
Jul 08 2016 11:56
I doubt it needs to be that complicated
But I'm happy to work with whatever you have
David Steiman
@xetys
Jul 08 2016 11:57
this is the way i learned spring ;)
and with craigs book :P
actually a test seems to be the best thing for you to to show you the missbehaviour

but the test i am writing is
start a eureka server + oauth server + remote app with secured endpoint and than
configure 2 clients, one with client credential flow and one with just no special configuration.

so i would expect the first client to work, while the second fails because the endpoint is 401

the reality is...both clients work
maybe it is sufficient to show with just basicauth
Dave Syer
@dsyer
Jul 08 2016 12:07
You don't need 3 apps to demonstrate that (I would suggest)
But let me know when you have finished hacing and I'll grab your code anyway
David Steiman
@xetys
Jul 08 2016 12:10
i am not sure i will manage to write the test
is it okay if i just make 3 apps to show that?
so you would have to start them off and access the endpoint to see it false working
Dave Syer
@dsyer
Jul 08 2016 13:33
OK
I'm pretty sure you won't need 3 apps. But as long as they are simple I can fix it.
bitsofinfo
@bitsofinfo
Jul 08 2016 14:47
slueth: is there anyway in my code (i.e. beyond spring.sleuth.keys.http.headers) to get ahold of the current span and add my own custom keys and custom values (beyond just whats in the http headers)? Is this in a thread local? For example I'd like to decorate the span with a value that is only available once my code is being invoked down in a spring-data-rest repository etc
i.e. docs state things like this.tracer..... but not sure how to get an instance of this tracer. Just inject a @Authowired Tracer?
bitsofinfo
@bitsofinfo
Jul 08 2016 15:10
or can this only be done at the ingress/egress point with the spaninjector/extractors?
Dave Syer
@dsyer
Jul 08 2016 15:18

Just inject a @Authowired Tracer?

Yes

This message was deleted
If you are only adding tags you shouldn't care about the injectors and extractors
bitsofinfo
@bitsofinfo
Jul 08 2016 15:20
thx, yeah i interpreted those to be used if you are messing w/ the span definition itself, or adding more global customizations to all spans in a trace
i.e the interchange contract
bitsofinfo
@bitsofinfo
Jul 08 2016 16:53
is this redis binder in development/not released supported yet? https://github.com/spring-cloud/spring-cloud-stream-binder-redis
Dave Syer
@dsyer
Jul 08 2016 17:59
It's only for development use
We can't support it in production
Redis messaging doesn't really work in an HA environment
A few XD early adopters pushed into places it couldn't come back from.
JonathanAaron
@JonathanAaron
Jul 08 2016 18:34
@dsyer I resolved that issue I was having with the my Eureka Server and RefreshScope by making sure both the Server and Client were using Brixton...They were using Angel.