Native Spring Integration

[Cantor, Scott]

On 4/30/14, 11:16 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>This is quite important and I may have aluded to this elsewhere.   I
>haven't
>looked too hard, but I have yet to work out how to link the Application
>Context that we parse the embedded statement with to the Application
>Context
>we are parsing relying party with.  We are not in the right place to have
>access to the latter, indeed I would not be surprised if it was
>impossible.
>This of course means that the content of the <spring:beans> statement
>cannot
>reference beans defined elsewhere either.

Hmm, I assumed there'd be a parent child relationship. The parsers don't
have access to their own ApplicationContext so they can't set it as the
parent of the embedded one?

>As an aside: it does not look entirely impossible however to parse the
>embedded <spring:beans/> statement into the *same* context that we are
>parsing into.

And that would really have been my expectation, that or parent/child.

>At that point of course fixed names fall apart, as does any
>lookup by type since there is no isolation inferred by the <spring:beans/>
>statement.  On the other hand we get to play inside the global application
>context and have references to other beans.
>
>I'm wondering whether we need to defer this conversation to Friday?

Probably, but we probably need to know the various options to have a
decent chance of making a decision. I will say my least favorite trick is
fixing the bean names. The only reason I've done it is to split user from
system beans so I can create contracts between what the user edits and
what's not editable, as an API essentially. I would rather not have any
dependencies on fixed bean names otherwise.

As I said, I'm not sure giving up property replacement in specific cases
is too high a price to pay, it really depends on how unwieldy it is to
understand what's replaceable and what's not.

Or it may be that the details beyond just parsing the beans element make
inline definitions just too limiting and inconsistent, and we should just
do what Daniel did and make them external refs.

I just feel like at that point we're almost better off laying out the
whole RelyingParty list in native Spring, and treating the old schema as
compatibility only. I just know the ease of use will go way down doing
that, which isn't to say that I had any hope of improving ease of use here
anyway. We lost that possibility a long way back, too many feature needs
trumped any possibility of making that a goal.

-- Scott