You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Muhammad Gelbana <m....@gmail.com> on 2012/09/17 11:34:44 UTC
[5.3.5] Reference to injected symbols from POJOs
Just to paraphrase, *whenever* the symbol is referenced, it's looked up
from the SymbolProvider and not cached by service using the symbol or any
tapestry service, correct ? (I hope and think the answer is Yes)
Now assume a service with injected symbols (Most commonly immutable objects
like Strings), If I pass a symbol to a POJO through it's constructor or a
setter method (Not managed by tapestry), will the value of the variable in
the POJO change if the symbol value changes ? (i.e. assuming the answer to
the question at the top is *Yes*)
Thank you.
Re: [5.3.5] Reference to injected symbols from POJOs
Posted by Lance Java <la...@googlemail.com>.
Have you understood that:
1. @Symbol annotations are resolved by the SymbolSource. This resolution can
only happen AFTER the SymbolSource service has been instantiated
2. Any SymbolProvider contributed to the SymbolSource will be created before
the SymbolSource
Are you running into a "chicken or the egg scanerio"?
--
View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-5-Reference-to-injected-symbols-from-POJOs-tp5716339p5716357.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [5.3.5] Reference to injected symbols from POJOs
Posted by Muhammad Gelbana <m....@gmail.com>.
>
> Why don't you just @Inject your SymbolProvider implementation in the place
> you need the mutable configurations and use it directly instead of using
> SymbolSource?
You are talking about injecting a service and calling it's methods for
values, correct ? Anyway, I guess I don't have another option.
But I actually have 2 providers so I think I'll inject a symbol source
instead to make it easier for me (I'm REALLY enjoying this framework !). Is
it ok to contribute the SystemProperties to my symbol source ? Because some
of my symbols needs to get expanded based on a JVM option. I think it's ok.
Also having the service injected instead of the value (Which could be an
immutable object) is more practical I suppose. The thing is that I'll have
to rollback a very wide range of changes that I've just did today :(
One more thing, although I'll follow your advice, but I still want to know
how to do this the *@Symbol* way. I tried to contribute a symbol object
provider with it's own symbol source and the symbol source it self has my
own symbol providers dealing with the database, but it isn't working. I'm
just trying to figure out my mistake.
@Contribute(MasterObjectProvider.class)
> public static void
> setupDBSYmbolObjectProviders(OrderedConfiguration<ObjectProvider>
> configuration) {
> configuration.addInstance("DBSymbol", DBSymbolObjectProvider.class,
> OrderConstraintBuilder.before("AnnotationBasedContributions").build());
> }
*DBSymbolObjectProvider* implements *ObjectProvider* and actually get's
built with my own symbol source. My symbol source is built this way:
public SymbolSource buildDBSymbolSource(@Named("IpkConfig") SymbolProvider
> ipkConfig, @Named("IxProConfig") SymbolProvider ixProConfig) {
> return new DBSymbolSource(Arrays.asList(ipkConfig, ixProConfig));
> }
But still my *DBSymbolObjectProvider* doesn't resolve any of my symbols.
It's queried to resolve objects but it never gets an *AnnotationProvider* with
a *@Symbol* annotation so it doesn't query the *SymbolSource* for symbols.
Why is that ?
Finally, I'm messing with tapestry's core :)
Thanks a lot for you help :)
On Mon, Sep 17, 2012 at 4:38 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Mon, 17 Sep 2012 09:06:53 -0300, Muhammad Gelbana <m....@gmail.com>
> wrote:
>
> Ok this is a problem now since I did a mistake by *assuming* that the
>> value is being fetched from the provider *whenever* it's referenced and
>> this is
>> allover my application now.
>>
>> Is there a way to override the caching mechanism for my own
>> *SymbolProviders* only ?
>>
>
> Answering the same question again, no. Why don't you just @Inject your
> SymbolProvider implementation in the place you need the mutable
> configurations and use it directly instead of using SymbolSource?
>
> Also would someone please mention in the documentations that the default *
>> SymbolSource* *caches* resolved symbols.
>> http://tapestry.apache.org/**symbols.html<http://tapestry.apache.org/symbols.html>
>> http://tapestry.apache.org/**current/apidocs/org/apache/**
>> tapestry5/ioc/services/**SymbolSource.html<http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/SymbolSource.html>
>>
>
> Yeah, it could have been more explicit about that.
>
> --
> Thiago H. de Paula Figueiredo
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.**apache.org<us...@tapestry.apache.org>
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [5.3.5] Reference to injected symbols from POJOs
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Mon, 17 Sep 2012 09:06:53 -0300, Muhammad Gelbana <m....@gmail.com>
wrote:
> Ok this is a problem now since I did a mistake by *assuming* that the
> value is being fetched from the provider *whenever* it's referenced and
> this is
> allover my application now.
>
> Is there a way to override the caching mechanism for my own
> *SymbolProviders* only ?
Answering the same question again, no. Why don't you just @Inject your
SymbolProvider implementation in the place you need the mutable
configurations and use it directly instead of using SymbolSource?
> Also would someone please mention in the documentations that the default
> *
> SymbolSource* *caches* resolved symbols.
> http://tapestry.apache.org/symbols.html
> http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/SymbolSource.html
Yeah, it could have been more explicit about that.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [5.3.5] Reference to injected symbols from POJOs
Posted by Muhammad Gelbana <m....@gmail.com>.
Ok this is a problem now since I did a mistake by *assuming* that the value
is being fetched from the provider *whenever* it's referenced and this is
allover my application now.
Is there a way to override the caching mechanism for my own *SymbolProviders
* only ?
Also would someone please mention in the documentations that the default *
SymbolSource* *caches* resolved symbols.
http://tapestry.apache.org/symbols.html
http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ioc/services/SymbolSource.html
Thank you.
On Mon, Sep 17, 2012 at 11:57 AM, Lance Java <la...@googlemail.com>wrote:
> Symbols can not change after the app has been initialized. If you need a
> dynamic property, you will need to provide your own mechanism to handle
> this.
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/5-3-5-Reference-to-injected-symbols-from-POJOs-tp5716339p5716340.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [5.3.5] Reference to injected symbols from POJOs
Posted by Lance Java <la...@googlemail.com>.
Symbols can not change after the app has been initialized. If you need a
dynamic property, you will need to provide your own mechanism to handle
this.
--
View this message in context: http://tapestry.1045711.n5.nabble.com/5-3-5-Reference-to-injected-symbols-from-POJOs-tp5716339p5716340.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org