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

22nd
Jun 2017
smaudet
@smaudet
Jun 22 2017 12:32
So...I'm new to the spring-cloud - how can I add a bean to the spring-cloud applicationContext?
I'm in SCSt, I have a bean initialized in the main context, but it doesn't appear to be passed to the cloud context. I see there is some concept of separation - there is a bootstrap.yml, but I don't see how that can be told to include a POJO that I write in my app?
Dave Syer
@dsyer
Jun 22 2017 12:47
Your app is the main context. Not sure what you mean really.
smaudet
@smaudet
Jun 22 2017 12:53
@dsyer if it might help, I'm using Spring Cloud Stream - I declared a Bean in that main context, it was created, and stored in the app main context. I then used that same Bean in the config that spring cloud stream uses (from inside a yml file), however SCSt is unable to find that bean. I debugged the application, OutputBindingLifecycle wires a different application context to the RabbitMQ Binder than what is available to the rest of the application. Therefore, I have two application contexts...not one. I want to know how to tell that lifecycle "no, please use this bean from my main application context"
I know it is different, because the references to BeanFactory contain a wildly different number of beans (44 vs 320 something)
I haven't done a bunch of fancy configuration, all I wanted was a simple POJO, inside SCSt.
Dave Syer
@dsyer
Jun 22 2017 12:55
Spring Cloud Stream does create its own contexts. They have the main context as their parent.
smaudet
@smaudet
Jun 22 2017 12:55
So, is this a SCSt question, how to import beans from different contexts?
Dave Syer
@dsyer
Jun 22 2017 12:55
Sort of
Autowiring prefers beans from the local context before the parent
smaudet
@smaudet
Jun 22 2017 12:56
In this case there is no autowiring...my SCSt is mostly pure config.
Dave Syer
@dsyer
Jun 22 2017 12:57
That doesn't make sense
How are you referring to the custom bean?
By autowiring probably.
smaudet
@smaudet
Jun 22 2017 12:57
like this routing-key-expression: "@myCustomBean.resolve(property.somObj)"
nope
like the above
Dave Syer
@dsyer
Jun 22 2017 12:58
SpEL
smaudet
@smaudet
Jun 22 2017 12:58
yes
Dave Syer
@dsyer
Jun 22 2017 12:58
It's the same
But where is that expression?
smaudet
@smaudet
Jun 22 2017 12:58
in a yml file (in my config/application-local.yml)
Dave Syer
@dsyer
Jun 22 2017 12:58
Right
If "myCustomBean" is in the parent context I'd expect that to work. But I could be wrong. It comes down to how the "@" works in the SpEL.
Which is actually a spring Framework feature
smaudet
@smaudet
Jun 22 2017 13:01
Its in the parent context, there was a bug in the SpEL resolver previously were a BeanFactory was not consulted (in SCSt), one was added, but now it appears the BeanFactory doesn't attempt to resolve anything in the parent context.
Thats why I'm wondering if this is a bug, or a 'feature', since application contexts are split.
Dave Syer
@dsyer
Jun 22 2017 13:01
I guess you need to ask spring cloud stream how it resolves the SpEL
smaudet
@smaudet
Jun 22 2017 13:01
OK
thanks
Marius Bogoevici
@mbogoevici
Jun 22 2017 19:08
@jfuerth Sorry for missing your question, I was at Spring Days here y’day. So to your initial point, it is possible to have a setup where an application is both the message producer and the message consumer, but in that case you need to use separate channels (i.e. beans) for input and output - right now they are mapped as the same bean demo-events which leads to the error, ultimately. You can configure both channels to use the same destination, case in which the application will subscribe to its own (and others’ events). It feels like your use case would be covered very well by Spring Cloud Bus (which uses Stream under the hood), or at least you can reproduce the pattens there
Jonathan Fuerth
@jfuerth
Jun 22 2017 19:09
@mbogoevici great, thanks! we'll take a look at Spring Cloud Bus and also ensure apps use different channels when talking to themselves.