Hi!
> If you're injecting conversation-scoped beans you're actually
> injecting a bean being tied to a specific conversation (i.e. you'd
> also have to copy bean definitions just referencing
> conversation-scoped beans, not only pages!).
This is how spring works, no? You always put a bean in a scope and
injection that somewhere else then. The only exception is the
"prototype" scope. But this effectively means that this
"prototype-scoped" bean shares the same lifetime of the bean it gets
injected into.
> In my opinion that's a major impact in the architecture of Orchestra
> applications!
Pretty much exclamation marks, having use-case descriptions would be
more helpful to me ;-)
I'd like to learn what makes this such a major impact that an Orchestra
application needs to be coded differently?
What beans do you put into conversation scope? I normally put just
backing beans into any Orchestra scope - and you wouldn't share backing
beans between pages, would you?
Or are you work on service objects? But then Orchestra might not fit
well indeed.
But I have an idea how this could be solved eventually.
Image such a config:
<bean name="pageA" class="my.backing.Bean" scope="conversation.access">
<property name="service">
<orchestra:elevate conversationName="pageA-service"
scope="conversation.manual" ref="serviceBean" />
</property>
</bean>
<bean name="serviceBean" class="my.service.Bean" scope="prototype" />
The trick is the conversationName here. The only "thing-to-discuss" is
that if the pageA bean dies due to no longer being accessed any new
instance of this page bean will reuse the same serviceBean instance
(given it has not yet timed-out).
I still would consider this as feature.
You can fix that by using conversation.manual on the service bean too I
think.
At a start we can support something like that just with API calls
(ConversationManager.elevate()) and then lets figure out how
orchestra:elevate could be implemented.
Volunteers?
Ciao,
Mario
