OK, thanks.
Ruwan
On Fri, Jan 7, 2011 at 10:21 AM, Supun Kamburugamuva wrote:
> Yeah, it was a mistake to make it protected. I'll make it private.
> Thanks for pointing out.
>
> We already had the concept of endpoint properties. But these
> properties were accessed only within the LoadBalancing
Yeah, it was a mistake to make it protected. I'll make it private.
Thanks for pointing out.
We already had the concept of endpoint properties. But these
properties were accessed only within the LoadBalancing algorithms. But
some properties like HTTP_METHOD, or FORCE_HTTP_1_0 are more suitable
in t
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
insta
Supun,
On Thu, Jan 6, 2011 at 12:34 PM, wrote:
> Author: supun
> Date: Thu Jan 6 07:04:10 2011
> New Revision: 1055765
>
> URL: http://svn.apache.org/viewvc?rev=1055765&view=rev
> Log:
> adding scope to the properties and evaluating the properties before sending
> a message through an endpoint
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, 201
Thanks! That looks like a good example.
Paul
On Thu, Jan 6, 2011 at 10:13 AM, indika kumara wrote:
> The thread at [1] may also be a use-case.
>
> Thanks,
>
> Indika
>
> [1] http://wso2.org/forum/thread/10462
>
> On Thu, Jan 6, 2011 at 2:54 PM, Paul Fremantle wrote:
>>
>> Can you give an exampl
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 XSL
The thread at [1] may also be a use-case.
Thanks,
Indika
[1] http://wso2.org/forum/thread/10462
On Thu, Jan 6, 2011 at 2:54 PM, Paul Fremantle wrote:
> Can you give an example use-case?
>
> Thanks
> Paul
>
> On Thu, Jan 6, 2011 at 7:18 AM, Ranga Siriwardena wrote:
> > Hi All,
> >
> > Current
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
conten
Can you give an example use-case?
Thanks
Paul
On Thu, Jan 6, 2011 at 7:18 AM, Ranga Siriwardena 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 dynam
On Thu, Jan 6, 2011 at 12:48 PM, Ranga Siriwardena 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
11 matches
Mail list logo
