(Re-resend): About Native-Spring DataConnector definition and the version policy

[Cantor, Scott]

On 9/7/16 6:26 AM, Rod Widdowson wrote:
> Apologies if this is the third (or more) copies of this (even if it is the
> first of three).  My ISP appears to have gotten itself blacklisted, so I've
> changed to a backup SMTP server and am resending.

Our spam filter has been pretty screwed up but usually more in the "let
anything through" direction. If you can send me a sample I'll take a look.

> My question was what that means for the implementation status of the
> DataConnectors?  Do we have to bite the bullet and make them -api and if so
> do we therefore have to move them to the -api tree?  I have a feeling that
> they will bring a great deal of detritus over with them in terms of classes
> that they require.  As an alternative we could add some sort of comment to
> all of the DataConnnector setters to say "change the name but not the type".

I think if we were exposing the actual class itself (meaning you'd have
to instantiate a bean of that type), I'd feel fairly uncomfortable about
it not being API, but the types thing feels a bit more fuzzy, like
something that really is more about documentation.

> Related to (and this is why this mail took so long) I want to open the
> question again about hybrid native spring configuration.  It has been
> possible for quite some time to configure Data Connectors entirely in native
> spring (the move to services forced us to make changes to the outer parser
> which in turn makes this possible) but to do this the native spring had to
> be in a different file.

And to be clear, that's an example of what I mean: if you wanted to
define a "native" LDAP or JDBC connector, you'd have to use the impl
class, and that would be out of bounds. I think our view there was
"caveat emptor" and that the native support was really there for people
defining custom connectors.

> Obviously exploiting this would have as a precondition moving the data
> connectors out to api.

Does it? I think the same thing applies: use it for custom beans as you
like, but using it for our connectors implies you're coloring outside
the lines right now.

> FWIW my feeling is that 
> 
> - We probably want to move the DataConnectors to the api tree (if we do so
> we need to do it properly).

I would agree that if we did move them to API, we should literally do
that, not try and make it a weird case. But I'm not convinced we should.

> - OTOH making yet another (albeit entirely backwards compatible) change to
> the Attribute resolver language may not be the thing for now, since we may
> be talking about changes the way that dependency is defined in V4.  Also
> there is the whole thorny issue of having data connectors export "encoder
> ready" attribute [3]

I don't know that I'm against the idea of supporting the <beans> thing
inline, but I thought we had explored that originally and concluded it
didn't work reliably. Were we trying to do something slightly different
in that case? Maybe embedding Spring inside the <DataConnector> element
didn't work?

-- Scott