Home » Modeling » TMF (Xtext) » Inject a different StaticMethodsFeatureForTypeProvider
| Inject a different StaticMethodsFeatureForTypeProvider [message #692217] |
Sun, 03 July 2011 19:53  |
Eclipse User |
|
|
|
Originally posted by:
Hi,
I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
ScopeProvider that extends XbaseScopeProvider. In this class, a
StaticMethodsFeatureForTypeProvider gets injected with
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
I want to inject a different instance (my own one), and guess this
should be possible using some trick in my RuntimeModule. I have tried
the following:
@Provides
public
org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
provideStaticMethodsFeatureForTypeProvider() {
return new StaticMethodsFeatureForTypeProvider(); // this is my own
class, not the existing Xbase one
}
This works, but the values that should be injected into this instance
aren't! I think that I somehow must make the Injector create the
StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
can enlighten me!
Hallvard
|
|
| | |
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692329 is a reply to message #692218] |
Mon, 04 July 2011 04:25  |
| Eclipse User |
|
|
|
Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
To change the binding for a specific interface type, it should be enough
to write
Class<? extends interfaceType> bind<interfaceType>() {
return YourImplType.class;
}
So in your case
Class<? extends StaticMethodsFeatureForTypeProvider>
bindStaticMethodsFeatureForTypeProvider() {
return <your impl>.class;
}
Guice's Provider<?> enables you to get multiple instances of the type by
calling get(). It relies on default constructors or constructors with
injected parameters only. Explicit binding of a Guice Provider<?> should
only be necessary if you want to customize the instantiation /
initialization behavior, e.g. when wrapping a external singleton such as
the workspace or the workbench.
Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
> I think I found the answer:
>
> @Override
> public void configure(Binder binder) {
> super.configure(binder);
> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>
> }
>
> I hope!
>
> Hallvard
>
> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>> Hi,
>>
>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>> StaticMethodsFeatureForTypeProvider gets injected with
>> @Inject
>> private Provider<StaticMethodsFeatureForTypeProvider>
>> implicitStaticFeatures;
>>
>> I want to inject a different instance (my own one), and guess this
>> should be possible using some trick in my RuntimeModule. I have tried
>> the following:
>> @Provides
>> public
>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>
>> provideStaticMethodsFeatureForTypeProvider() {
>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>> class, not the existing Xbase one
>> }
>> This works, but the values that should be injected into this instance
>> aren't! I think that I somehow must make the Injector create the
>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>> can enlighten me!
>>
>> Hallvard
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692361 is a reply to message #692329] |
Mon, 04 July 2011 05:37 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 10.25, Jan Koehnlein wrote:
> Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
>
> To change the binding for a specific interface type, it should be enough
> to write
>
> Class<? extends interfaceType> bind<interfaceType>() {
> return YourImplType.class;
> }
>
> So in your case
>
> Class<? extends StaticMethodsFeatureForTypeProvider>
> bindStaticMethodsFeatureForTypeProvider() {
> return <your impl>.class;
> }
>
> Guice's Provider<?> enables you to get multiple instances of the type by
> calling get(). It relies on default constructors or constructors with
> injected parameters only. Explicit binding of a Guice Provider<?> should
> only be necessary if you want to customize the instantiation /
> initialization behavior, e.g. when wrapping a external singleton such as
> the workspace or the workbench.
I think I understand this. However, XbaseScopeProvider declares a
provider of a provider class:
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
And it uses get to get a new instance:
protected StaticMethodsFeatureForTypeProvider
newImplicitStaticFeaturesProvider() {
return implicitStaticFeatures.get();
}
Hence, I thought I needed to make the default creation use my
StaticMethodsFeatureForTypeProvider class instead of Xbase's.
Correct me if I'm wrong.
Hallvard
>
> Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
>> I think I found the answer:
>>
>> @Override
>> public void configure(Binder binder) {
>> super.configure(binder);
>> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>>
>>
>> }
>>
>> I hope!
>>
>> Hallvard
>>
>> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>>> Hi,
>>>
>>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>>> StaticMethodsFeatureForTypeProvider gets injected with
>>> @Inject
>>> private Provider<StaticMethodsFeatureForTypeProvider>
>>> implicitStaticFeatures;
>>>
>>> I want to inject a different instance (my own one), and guess this
>>> should be possible using some trick in my RuntimeModule. I have tried
>>> the following:
>>> @Provides
>>> public
>>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>>
>>>
>>> provideStaticMethodsFeatureForTypeProvider() {
>>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>>> class, not the existing Xbase one
>>> }
>>> This works, but the values that should be injected into this instance
>>> aren't! I think that I somehow must make the Injector create the
>>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>>> can enlighten me!
>>>
>>> Hallvard
>>
>
>
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692412 is a reply to message #692361] |
Mon, 04 July 2011 07:37 |
| Eclipse User |
|
|
|
Using a Guice Provider<>or not is usually the client's choice.
You need to *bind* a Guice Provider<> only if you want to change Guice's
default instantiation strategy.
Am 04.07.11 11:37, schrieb Hallvard Trætteberg:
> On 04.07.11 10.25, Jan Koehnlein wrote:
>> Don't mix up Guice's Provider<?> concept with your SMFFTProvider!
>>
>> To change the binding for a specific interface type, it should be enough
>> to write
>>
>> Class<? extends interfaceType> bind<interfaceType>() {
>> return YourImplType.class;
>> }
>>
>> So in your case
>>
>> Class<? extends StaticMethodsFeatureForTypeProvider>
>> bindStaticMethodsFeatureForTypeProvider() {
>> return <your impl>.class;
>> }
>>
>> Guice's Provider<?> enables you to get multiple instances of the type by
>> calling get(). It relies on default constructors or constructors with
>> injected parameters only. Explicit binding of a Guice Provider<?> should
>> only be necessary if you want to customize the instantiation /
>> initialization behavior, e.g. when wrapping a external singleton such as
>> the workspace or the workbench.
>
> I think I understand this. However, XbaseScopeProvider declares a
> provider of a provider class:
>
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> And it uses get to get a new instance:
>
> protected StaticMethodsFeatureForTypeProvider
> newImplicitStaticFeaturesProvider() {
> return implicitStaticFeatures.get();
> }
>
> Hence, I thought I needed to make the default creation use my
> StaticMethodsFeatureForTypeProvider class instead of Xbase's.
>
> Correct me if I'm wrong.
>
> Hallvard
>
>>
>> Am 04.07.11 01:59, schrieb Hallvard Trætteberg:
>>> I think I found the answer:
>>>
>>> @Override
>>> public void configure(Binder binder) {
>>> super.configure(binder);
>>> binder.bind(org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider.class).to(StaticMethodsFeatureForTypeProvider.class);
>>>
>>>
>>>
>>> }
>>>
>>> I hope!
>>>
>>> Hallvard
>>>
>>> On 04.07.11 01.53, Hallvard Trætteberg wrote:
>>>> Hi,
>>>>
>>>> I extend the Xbase grammar and with the XbaseGeneratorFragment i get a
>>>> ScopeProvider that extends XbaseScopeProvider. In this class, a
>>>> StaticMethodsFeatureForTypeProvider gets injected with
>>>> @Inject
>>>> private Provider<StaticMethodsFeatureForTypeProvider>
>>>> implicitStaticFeatures;
>>>>
>>>> I want to inject a different instance (my own one), and guess this
>>>> should be possible using some trick in my RuntimeModule. I have tried
>>>> the following:
>>>> @Provides
>>>> public
>>>> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider
>>>>
>>>>
>>>>
>>>> provideStaticMethodsFeatureForTypeProvider() {
>>>> return new StaticMethodsFeatureForTypeProvider(); // this is my own
>>>> class, not the existing Xbase one
>>>> }
>>>> This works, but the values that should be injected into this instance
>>>> aren't! I think that I somehow must make the Injector create the
>>>> StaticMethodsFeatureForTypeProvider, but I don't know how! Can someone
>>>> can enlighten me!
>>>>
>>>> Hallvard
>>>
>>
>>
>
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
| | |
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692470 is a reply to message #692446] |
Mon, 04 July 2011 09:46 |
| Eclipse User |
|
|
|
Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
> On 04.07.11 13.37, Jan Koehnlein wrote:
>> Using a Guice Provider<>or not is usually the client's choice.
>
> In this case XbaseScopeProvider has made the choice to use a Provider<>,
> so I believe I must comply with it.
No, as I said, it's the clients choice (the one who gets the component
injected). You just bind an implementation class to an interface or
class. The latter is what the client uses as its API to access this
service. So if a client wants a
@Inject
private Provider<StaticMethodsFeatureForTypeProvider>
implicitStaticFeatures;
it gets a Guice Provider that delivers objects whose type is assignable
to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
class and not an interface. The only difference is that we don't have to
bind a default implementation in this case, as the class itself is bound
by default. You can override that default binding using the same
mechanism as for an interface binding.
>> You need to *bind* a Guice Provider<> only if you want to change Guice's
>> default instantiation strategy.
>
> I think the default strategy for a Provider<X> is to instantiate X,
> while I want it to instantiate a specific subclass.
No, Guice creates an instance of the class that is bound to the specific
interface type. This binding is what you want to change. By default
instantiation strategy I meant calling the default constructor or the
one with only injected parameters.
>
> Anyway, it works, so I'm happy!
>
> Hallvard
Maybe it is a good idea to re-read the documentation on dependency
injection now, and get more familiar with Guice?
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692518 is a reply to message #692470] |
Mon, 04 July 2011 12:15 |
| Eclipse User |
|
|
|
Originally posted by:
On 04.07.11 15.46, Jan Koehnlein wrote:
> Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
>> On 04.07.11 13.37, Jan Koehnlein wrote:
>>> Using a Guice Provider<>or not is usually the client's choice.
>>
>> In this case XbaseScopeProvider has made the choice to use a Provider<>,
>> so I believe I must comply with it.
>
> No, as I said, it's the clients choice (the one who gets the component
> injected). You just bind an implementation class to an interface or
> class. The latter is what the client uses as its API to access this
> service. So if a client wants a
>
> @Inject
> private Provider<StaticMethodsFeatureForTypeProvider>
> implicitStaticFeatures;
>
> it gets a Guice Provider that delivers objects whose type is assignable
> to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
> will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
> class and not an interface. The only difference is that we don't have to
> bind a default implementation in this case, as the class itself is bound
> by default. You can override that default binding using the same
> mechanism as for an interface binding.
As follows, you mean:
public Class<? extends
org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider>
bindStaticMethodsFeatureForTypeProvider() {
return no.hal.ecoretypes.x.StaticMethodsFeatureForTypeProvider.class;
}
>>> You need to *bind* a Guice Provider<> only if you want to change Guice's
>>> default instantiation strategy.
>>
>> I think the default strategy for a Provider<X> is to instantiate X,
>> while I want it to instantiate a specific subclass.
>
> No, Guice creates an instance of the class that is bound to the specific
> interface type. This binding is what you want to change. By default
> instantiation strategy I meant calling the default constructor or the
> one with only injected parameters.
>
>> Anyway, it works, so I'm happy!
>>
>> Hallvard
>
> Maybe it is a good idea to re-read the documentation on dependency
> injection now, and get more familiar with Guice?
I tend to read just enough to get things done. In this case, the
strategy I used worked, but wasn't the cleanest solution. Over time,
misunderstandings like this will be fewer, partly thanks to patient
experts like you!
Hallvard
|
|
| |
| Re: Inject a different StaticMethodsFeatureForTypeProvider [message #692852 is a reply to message #692518] |
Tue, 05 July 2011 06:52 |
| Eclipse User |
|
|
|
Am 04.07.11 18:15, schrieb Hallvard Trætteberg:
> On 04.07.11 15.46, Jan Koehnlein wrote:
>> Am 04.07.11 14:42, schrieb Hallvard Trætteberg:
>>> On 04.07.11 13.37, Jan Koehnlein wrote:
>>>> Using a Guice Provider<>or not is usually the client's choice.
>>>
>>> In this case XbaseScopeProvider has made the choice to use a Provider<>,
>>> so I believe I must comply with it.
>>
>> No, as I said, it's the clients choice (the one who gets the component
>> injected). You just bind an implementation class to an interface or
>> class. The latter is what the client uses as its API to access this
>> service. So if a client wants a
>>
>> @Inject
>> private Provider<StaticMethodsFeatureForTypeProvider>
>> implicitStaticFeatures;
>>
>> it gets a Guice Provider that delivers objects whose type is assignable
>> to StaticMethodsFeatureForTypeProvider. Any subtype or the type itself
>> will do. It doesn't matter that StaticMethodsFeatureForTypeProvider is a
>> class and not an interface. The only difference is that we don't have to
>> bind a default implementation in this case, as the class itself is bound
>> by default. You can override that default binding using the same
>> mechanism as for an interface binding.
>
> As follows, you mean:
>
> public Class<? extends
> org.eclipse.xtext.xbase.scoping.featurecalls.StaticMethodsFeatureForTypeProvider>
> bindStaticMethodsFeatureForTypeProvider() {
> return no.hal.ecoretypes.x.StaticMethodsFeatureForTypeProvider.class;
> }
>
Exactly.
>>>> You need to *bind* a Guice Provider<> only if you want to change
>>>> Guice's
>>>> default instantiation strategy.
>>>
>>> I think the default strategy for a Provider<X> is to instantiate X,
>>> while I want it to instantiate a specific subclass.
>>
>> No, Guice creates an instance of the class that is bound to the specific
>> interface type. This binding is what you want to change. By default
>> instantiation strategy I meant calling the default constructor or the
>> one with only injected parameters.
>>
>>> Anyway, it works, so I'm happy!
>>>
>>> Hallvard
>>
>> Maybe it is a good idea to re-read the documentation on dependency
>> injection now, and get more familiar with Guice?
>
> I tend to read just enough to get things done. In this case, the
> strategy I used worked, but wasn't the cleanest solution. Over time,
> misunderstandings like this will be fewer, partly thanks to patient
> experts like you!
>
> Hallvard
No problem. I was just starting to get a bit impatient :-)
--
Need professional support for Eclipse Modeling?
Go visit: http://xtext.itemis.com
|
|
|
Goto Forum:
Current Time: Mon Jul 07 10:39:06 EDT 2025
Powered by FUDForum. Page generated in 0.12341 seconds |
Home