Resource SPI proposal

[Andrey Kornev]

Hello,

Long story short, I'd love to be able to intercept the resource injection calls.

For example, in our application we do not use Spring, and also, we do not expect the developers to use Ignite-specific annotations in the application code. Instead, we use the standard javax.inject API's @Inject which makes integration with Ignite a bit painful since every application-level closure/class needs to be un-/wrapped before and after serialization. On the receiving node, the wrapper code looks up a local instance of injector (we use Guice) and finally injects the dependencies.

It would be nice to be able to define a custom injection callback (an SPI) to which Ignite would delegate at specific points during the resource injection flow. The current implementation of GridResourceProcessor makes no provision for such thing.

I also think this feature would allow to make the injector support pluggable: Spring, Guice, Dagger, whatever... Going forward, it would also be possible to gradually phase out all injection related Ignite annotations in favor of the standard javax.inject API.

Please share your thoughts!

Andrey
     

[Vladimir Ozerov]

+1

It is hard to understand why do we have so much different annotations for
injections while requierd resource type could be clearly derived from field
or method types. Looks like a single annotation will be enough. And it
should not be hard to abstract out injection logic into SPI.

On Thu, Aug 13, 2015 at 6:10 PM, Andrey Kornev <[hidden email]>
wrote:

> Hello,
>
> Long story short, I'd love to be able to intercept the resource injection
> calls.
>
> For example, in our application we do not use Spring, and also, we do not
> expect the developers to use Ignite-specific annotations in the application
> code. Instead, we use the standard javax.inject API's @Inject which makes
> integration with Ignite a bit painful since every application-level
> closure/class needs to be un-/wrapped before and after serialization. On
> the receiving node, the wrapper code looks up a local instance of injector
> (we use Guice) and finally injects the dependencies.
>
> It would be nice to be able to define a custom injection callback (an SPI)
> to which Ignite would delegate at specific points during the resource
> injection flow. The current implementation of GridResourceProcessor makes
> no provision for such thing.
>
> I also think this feature would allow to make the injector support
> pluggable: Spring, Guice, Dagger, whatever... Going forward, it would also
> be possible to gradually phase out all injection related Ignite annotations
> in favor of the standard javax.inject API.
>
> Please share your thoughts!
>
> Andrey
>

[yzhdanov]

+1

Andrey, can you please file a ticket and put the proposed design to it?



--Yakov

2015-08-13 21:37 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> +1
>
> It is hard to understand why do we have so much different annotations for
> injections while requierd resource type could be clearly derived from field
> or method types. Looks like a single annotation will be enough. And it
> should not be hard to abstract out injection logic into SPI.
>
> On Thu, Aug 13, 2015 at 6:10 PM, Andrey Kornev <[hidden email]>
> wrote:
>
> > Hello,
> >
> > Long story short, I'd love to be able to intercept the resource injection
> > calls.
> >
> > For example, in our application we do not use Spring, and also, we do not
> > expect the developers to use Ignite-specific annotations in the
> application
> > code. Instead, we use the standard javax.inject API's @Inject which makes
> > integration with Ignite a bit painful since every application-level
> > closure/class needs to be un-/wrapped before and after serialization. On
> > the receiving node, the wrapper code looks up a local instance of
> injector
> > (we use Guice) and finally injects the dependencies.
> >
> > It would be nice to be able to define a custom injection callback (an
> SPI)
> > to which Ignite would delegate at specific points during the resource
> > injection flow. The current implementation of GridResourceProcessor makes
> > no provision for such thing.
> >
> > I also think this feature would allow to make the injector support
> > pluggable: Spring, Guice, Dagger, whatever... Going forward, it would
> also
> > be possible to gradually phase out all injection related Ignite
> annotations
> > in favor of the standard javax.inject API.
> >
> > Please share your thoughts!
> >
> > Andrey
> >
>