Indika,

You cannot put the key as the index as the same key would result in
different XSLT's for different messages.

I don't think Springs case is dynamic, it is just a matter of selecting
among a set of predefined XSLT's and also they have a static key it seems.

Further, I don't see a need for a cache, as the SynapseConfiguration entries
already supports this, may be we need to create another type of an entry
type called cached entry, which are not getting serialized to configuration
file.

Thanks,
Ruwan

On Fri, Jan 7, 2011 at 10:44 PM, indika kumara <indika.k...@gmail.com>wrote:

> Ruwan,
>
> I have not tried multiple template caching but I feel that it should be
> possible.  The value resulted from evaluating a key expression (key) vs a
> template instance(value). It is just key-value. Do we need to create an
> index? if so, what are the parameter for calculating the index? I believe it
> is a simple cache. A generic cache that can keep any domain
> object(application data - template, schema, etc) would be ideal. I believe a
> cache should be able to keep any application data. Such a cache can be put
> in the synapse configuration level, registry level, or any other place.
>
> BTW, It seems that Spring does multiple XSLT template caching [1] - it
> looks like their scenario is identical to ours.
>
> Thanks,
>
> Indika
>
> [1] http://forum.springsource.org/archive/index.php/t-13862.html
>
>
> On Fri, Jan 7, 2011 at 8:37 PM, Ruwan Linton <ruwan.lin...@gmail.com>wrote:
>
>> Indika,
>>
>> I agree about the other mediators, but XSLT this cannot be done I guess.
>>
>> being able to cache multiple templates on its own would not solve the
>> problem as it requires some indexing mechanism. In dynamic key case, the
>> XSLT is going be dynamic and caching the template with a key expression will
>> not work, I expect caching over the evaluated XSLT is not going to be that
>> effective too.
>>
>> Ruwan
>>
>>
>> On Fri, Jan 7, 2011 at 9:53 AM, indika kumara <indika.k...@gmail.com>wrote:
>>
>>> I have not checked the code. But I believe it is possible to modify the
>>> XSLT mediator to cache multiple templates. In the worst case, caching
>>> multiple transformer instances. We have to evaluate tradeoff between a
>>> mediator with multiple transformer (or templates) instances vs multiple
>>> mediator instances.
>>>
>>> BTW, the use case at [1] might be worth : use a single validate mediator
>>> instead of a filter mediator + multiple validate mediators. That applies for
>>> many mediators.
>>>
>>>
>>> Thanks,
>>>
>>> Indika
>>>
>>> [1] http://wso2.org/forum/thread/10462
>>>
>>> On Fri, Jan 7, 2011 at 7:21 AM, Ruwan Linton <ruwan.lin...@gmail.com>wrote:
>>>
>>>> I agree with Paul 100%.
>>>>
>>>> Supun/Ranga, if you carefully look at the XSLT mediator, it caches the
>>>> XSLT template, template creation in XSLT (basically compiling it) is an
>>>> expensive task, with this approach we cannot cache the XSLT as the XSLT is
>>>> dynamic in this case.
>>>>
>>>> Thanks,
>>>> Ruwan
>>>>
>>>>
>>>> On Thu, Jan 6, 2011 at 3:44 PM, Paul Fremantle <pzf...@gmail.com>wrote:
>>>>
>>>>> Ok. I can see a few scenarios where this might be useful, but in
>>>>> general if there are a well-defined set of XSLTs (e.g. say we are
>>>>> choosing between 10) it would be more efficient to have separate
>>>>> mediators because they will do the initialization and this might
>>>>> include a compilation step for the XSLT.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Thu, Jan 6, 2011 at 10:03 AM, Supun Kamburugamuva <
>>>>> supu...@gmail.com> wrote:
>>>>> > As an example lets take a XSLT transformation.
>>>>> >
>>>>> > Depending on the message content user may have several XSLT
>>>>> > transformations specified.
>>>>> >
>>>>> > With the current language user has to have several XSLT mediators
>>>>> > refereeing these XSLT's.
>>>>> >
>>>>> > But by calculating the XSLT key dynamically based on the message
>>>>> > content, user can use only one XSLT mediator.
>>>>> >
>>>>> > Thanks,
>>>>> > Supun..
>>>>> >
>>>>> > On Thu, Jan 6, 2011 at 2:24 PM, Paul Fremantle <pzf...@gmail.com>
>>>>> wrote:
>>>>> >> Can you give an example use-case?
>>>>> >>
>>>>> >> Thanks
>>>>> >> Paul
>>>>> >>
>>>>> >> On Thu, Jan 6, 2011 at 7:18 AM, Ranga Siriwardena <ra...@wso2.com>
>>>>> wrote:
>>>>> >>> Hi All,
>>>>> >>>
>>>>> >>> Currently we are supporting only static registry keys with
>>>>> mediators.
>>>>> >>> For an example, XSLT Mediators only allows static keys when
>>>>> creating
>>>>> >>> the mediator. How about having dynamic keys with these kind of
>>>>> >>> mediators. In that case we can support dynamic keys and with that,
>>>>> >>> user will able to use XPath kind of approach to dynamically
>>>>> generate
>>>>> >>> the key instead of a static key. WDYT?
>>>>> >>>
>>>>> >>> Following is an example for that.
>>>>> >>>
>>>>> >>> <!-- using static key -->
>>>>> >>> <xslt key="xslt-key-req"/>
>>>>> >>>
>>>>> >>> <!-- using Dynamic key -->
>>>>> >>> <xslt key={ } />
>>>>> >>>
>>>>> >>> If we are supporting this kind of dynamic key approach, what should
>>>>> be
>>>>> >>> the proper way of representing the dynamic key?
>>>>> >>> Thoughts are welcome.
>>>>> >>>
>>>>> >>> Thank You.
>>>>> >>>
>>>>> >>> --
>>>>> >>> Ranga Siriwardena
>>>>> >>> Software Engineer
>>>>> >>> WSO2 Inc.
>>>>> >>>
>>>>> >>>
>>>>> ---------------------------------------------------------------------
>>>>> >>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
>>>>> >>> For additional commands, e-mail: dev-h...@synapse.apache.org
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Paul Fremantle
>>>>> >> Co-Founder and CTO, WSO2
>>>>> >> Apache Synapse PMC Chair
>>>>> >> OASIS WS-RX TC Co-chair
>>>>> >>
>>>>> >> blog: http://pzf.fremantle.org
>>>>> >> p...@wso2.com
>>>>> >>
>>>>> >> "Oxygenating the Web Service Platform", www.wso2.com
>>>>> >>
>>>>> >>
>>>>> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
>>>>> >> For additional commands, e-mail: dev-h...@synapse.apache.org
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Technical Lead, WSO2 Inc
>>>>> > http://wso2.org
>>>>> > supunk.blogspot.com
>>>>> >
>>>>> > ---------------------------------------------------------------------
>>>>> > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
>>>>> > For additional commands, e-mail: dev-h...@synapse.apache.org
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Paul Fremantle
>>>>> Co-Founder and CTO, WSO2
>>>>> Apache Synapse PMC Chair
>>>>> OASIS WS-RX TC Co-chair
>>>>>
>>>>> blog: http://pzf.fremantle.org
>>>>> p...@wso2.com
>>>>>
>>>>> "Oxygenating the Web Service Platform", www.wso2.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
>>>>> For additional commands, e-mail: dev-h...@synapse.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ruwan Linton
>>>> Software Architect & Product Manager
>>>>
>>>> WSO2 Inc.; http://wso2.org
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>> phone: +1 408 754 7388 ext 51789
>>>> email: ru...@wso2.com; cell: +94 77 341 3097
>>>> blog: http://blog.ruwan.org
>>>> linkedin: http://www.linkedin.com/in/ruwanlinton
>>>> google: http://www.google.com/profiles/ruwan.linton
>>>> tweet: http://twitter.com/ruwanlinton
>>>>
>>>
>>>
>>
>>
>> --
>> Ruwan Linton
>> Software Architect & Product Manager
>> WSO2 Inc.; http://wso2.org
>>
>> Lean . Enterprise . Middleware
>>
>> phone: +1 408 754 7388 ext 51789
>> email: ru...@wso2.com; cell: +94 77 341 3097
>> blog: http://blog.ruwan.org
>> linkedin: http://www.linkedin.com/in/ruwanlinton
>> google: http://www.google.com/profiles/ruwan.linton
>> tweet: http://twitter.com/ruwanlinton
>>
>
>


-- 
Ruwan Linton
Software Architect & Product Manager
WSO2 Inc.; http://wso2.org

Lean . Enterprise . Middleware

phone: +1 408 754 7388 ext 51789
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://blog.ruwan.org
linkedin: http://www.linkedin.com/in/ruwanlinton
google: http://www.google.com/profiles/ruwan.linton
tweet: http://twitter.com/ruwanlinton

Reply via email to