Is this the method responsible for injecting instance fields within
services ?
*org.apache.tapestry5.ioc.internal.util.InternalUtils.injectIntoFields(Object,
ObjectLocator, InjectionResources, OperationTracker)*
If it is,
if (ap.getAnnotation(Inject.class) != null ||
ap.getAnnotation(InjectResource.class) != null)
{
Object value = resources.*findResource*(fieldType,
f.getGenericType()); //
if (value != null)
{
inject(object, f, value);
return;
}
inject(object, f, locator.getObject(fieldType, ap));
return;
}
if (ap.getAnnotation(javax.inject.Inject.class) != null)
{
Named named = ap.getAnnotation(Named.class);
if (named == null)
{
inject(object, f, locator.getObject(fieldType, ap));
} else
{
inject(object, f, locator.getService(named.value(),
fieldType));
}
return;
}
If I didn't miss anything, and there is a huge chance I did because I don't
know about tapestry's internals, I guess that only tapestry's @Inject and
@InjectResource annotations are used to inject resources like
org.slf4j.Logger. Even after a quick look at the whole class, I can say
that injecting resources is only provided if tapestry's @Inject or
@InjectResource is on the field to be injected.
This class looks like it's treating tapestry's @Inject and java's exactly
the same but I think it's only concerned with transformable classes such as
components and pages.
*org.apache.tapestry5.internal.transform.InjectWorker*
On Thu, Jun 14, 2012 at 11:20 PM, Muhammad Gelbana <m.gelb...@gmail.com>wrote:
> I only provided abstract proofs for what I'm trying to question, not the
> whole thing of course as not to distract anyone away from the main point.
> I guess now the only thing is left is the difference between tapestry's
> @Inject and java's. I know Howard disagrees with that, did anyone else
> notice such a difference with injection ? field injection to be specific.
>
>
> On Thu, Jun 14, 2012 at 11:16 PM, Thiago H de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> On Thu, 14 Jun 2012 17:42:33 -0300, Muhammad Gelbana <m.gelb...@gmail.com>
>> wrote:
>>
>> *- Do you know you can use injection (no annotations needed) in build,
>>> contribute and advise methods in Tapestry-IoC module classes? ;) *
>>>
>>> You mean in the method signature ?
>>>
>>
>> Yes.
>>
>>
>> It's of course different from injecting services in the module
>>>
>>
>> No difference.
>>
>>
>> but how is it different tapestry-wise ?
>>>
>>
>> Just two different ways to get access to services. No difference
>> Tapestry-wise. If you're going to use a service in just one or two methods
>> in your module class, I'd use injection in their parameters. Otherwise,
>> field injection.
>>
>> *- Another option is to contribute to the RegistryStartup configuration a
>>>
>>> Runnable that invokes your service. Just calling it directly in
>>> contributeRegistryStartup() makes the call to happen before the registry
>>> was actually started up. *
>>>
>>> Well that is what I'm actually doing.
>>>
>>
>> The code you provided us tells that's *not* what you're doing.
>>
>>
>> Only that I'm injecting services in
>>> the module, while it looks like injecting the service through the
>>> contribute method signature is a better practice.
>>>
>>
>> It isn't a better practice, just a different way of doing the same thing.
>> Your module class, as posted here, had just one use of the service, so the
>> most appropriate way of injecting it, IMHO, was in the method signature.
>>
>> Also you are saying that the runnable will run *before* the registry
>>> starts up, isn't that a problem if I'm calling injected services ? I know
>>> it isn't as I'm already doing it.
>>>
>>
>> The code you provided does *not* use a Runnable, so I what I wrote was
>> based on it. If your code actually invokes the service inside a Runnable
>> contributed to the RegistryStartup service configuration, then it was right
>> but, again, that's not what you posted here.
>>
>>
>> --
>> Thiago H. de Paula Figueiredo
>>
>
>
>
> --
> *Regards,*
> *Muhammad Gelbana
> Java Developer*
>
>
--
*Regards,*
*Muhammad Gelbana
Java Developer*
