Re: [Architecture] [Siddhi] Extension Support

[Sachini Jayasekara]

Hi all,

Created a jira at [1].

[1]https://wso2.org/jira/browse/CEP-964


Thanks
Sachini



On Thu, Oct 2, 2014 at 4:30 PM, Sriskandarajah Suhothayan 
wrote:

> Its a good addition
>
> @Sachini can you create a jira for this?
>
> We'll add this when we have stabilised the basic functionalities.
>
>
> On Thu, Oct 2, 2014 at 3:26 PM, Manoj Gunawardena  wrote:
>
>> Hi,
>>
>> This is a suggestion, I think its useful to have a version with the
>> siddhi extension name, The same extension can exists with different
>> versions. Idea is if extension get change and new version arrives, no need
>> to change existing queries.
>>
>> Ex -: currency_1.0.siddhiext
>>
>> In the query should call the extension with the version.
>> Then currency new extension arrives it may be 2.0.
>>
>> Will this be useful?
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 30, 2014 at 5:52 PM, Sachini Jayasekara 
>> wrote:
>>
>>> Hi all,
>>>
>>> New Siddhi implementation supports custom functions and custom output
>>> aggregators.
>>>
>>> Custom functions can be written extending the FunctionExecutor class.
>>>
>>> Custom output aggregators can be written implementing
>>> AttributeAggregator interface. In earlier version, to write a custom output
>>> aggregator,  user had to implement both OutputAttributeAggregatorFactory
>>> and OutputAttributeAggregator interfaces. (Now there is no need to
>>> implement 2 interfaces user can simply add the logic to one class which
>>> implements AttributeAggregator interface).
>>>
>>> Then the implemented custom classes has to be compiled and the jar files
>>> should be added to the class path.
>>> User then has to add the custom function name and  fully-qualified class
>>> name of the custom extension to a file named  "namespace of the
>>> function/aggregator . siddhiext". (eg:- if namespace of a
>>> function/aggregator is "currency"  function/aggregator name and
>>>  fully-qualified class name should be added to a file named
>>> currency.siddhiext ). For each extension .siddhiext should be created. This
>>> file should also be added to class path.
>>>
>>> In earlier version, jars and siddhiext files have to be added to
>>> specific locations but now user can and those to anywhere in class path.
>>>
>>> Extension loading process of  Siddhi will search for files ending with
>>>  .siddhiext in class path and add them as extensions.
>>> User can refer to the custom classes giving the namespace and function
>>> name.
>>>
>>> Thanks
>>>
>>> --
>>>
>>>
>>>
>>> *Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *
>>>
>>> *lean . enterprise . middleware |  http://wso2.com  *
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Manoj Gunawardena
>> Tech Lead
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> Mobile : +94 77 2291643
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *S. Suhothayan*
> Technical Lead & Team Lead of WSO2 Complex Event Processor
>  *WSO2 Inc. *http://wso2.com
> * *
> lean . enterprise . middleware
>
>
> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
> http://suhothayan.blogspot.com/ twitter:
> http://twitter.com/suhothayan  | linked-in:
> http://lk.linkedin.com/in/suhothayan *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 



*Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *

*lean . enterprise . middleware |  http://wso2.com  *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Siddhi] Extension Support

[Sriskandarajah Suhothayan]

Its a good addition

@Sachini can you create a jira for this?

We'll add this when we have stabilised the basic functionalities.


On Thu, Oct 2, 2014 at 3:26 PM, Manoj Gunawardena  wrote:

> Hi,
>
> This is a suggestion, I think its useful to have a version with the siddhi
> extension name, The same extension can exists with different versions. Idea
> is if extension get change and new version arrives, no need to change
> existing queries.
>
> Ex -: currency_1.0.siddhiext
>
> In the query should call the extension with the version.
> Then currency new extension arrives it may be 2.0.
>
> Will this be useful?
>
> Thanks
>
>
>
>
>
>
> On Tue, Sep 30, 2014 at 5:52 PM, Sachini Jayasekara 
> wrote:
>
>> Hi all,
>>
>> New Siddhi implementation supports custom functions and custom output
>> aggregators.
>>
>> Custom functions can be written extending the FunctionExecutor class.
>>
>> Custom output aggregators can be written implementing AttributeAggregator
>> interface. In earlier version, to write a custom output aggregator,  user
>> had to implement both OutputAttributeAggregatorFactory and
>> OutputAttributeAggregator interfaces. (Now there is no need to implement 2
>> interfaces user can simply add the logic to one class which implements
>> AttributeAggregator interface).
>>
>> Then the implemented custom classes has to be compiled and the jar files
>> should be added to the class path.
>> User then has to add the custom function name and  fully-qualified class
>> name of the custom extension to a file named  "namespace of the
>> function/aggregator . siddhiext". (eg:- if namespace of a
>> function/aggregator is "currency"  function/aggregator name and
>>  fully-qualified class name should be added to a file named
>> currency.siddhiext ). For each extension .siddhiext should be created. This
>> file should also be added to class path.
>>
>> In earlier version, jars and siddhiext files have to be added to specific
>> locations but now user can and those to anywhere in class path.
>>
>> Extension loading process of  Siddhi will search for files ending with
>>  .siddhiext in class path and add them as extensions.
>> User can refer to the custom classes giving the namespace and function
>> name.
>>
>> Thanks
>>
>> --
>>
>>
>>
>> *Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *
>>
>> *lean . enterprise . middleware |  http://wso2.com  *
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Manoj Gunawardena
> Tech Lead
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> Mobile : +94 77 2291643
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
 *WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Siddhi] Extension Support

[Manoj Gunawardena]

Hi,

This is a suggestion, I think its useful to have a version with the siddhi
extension name, The same extension can exists with different versions. Idea
is if extension get change and new version arrives, no need to change
existing queries.

Ex -: currency_1.0.siddhiext

In the query should call the extension with the version.
Then currency new extension arrives it may be 2.0.

Will this be useful?

Thanks






On Tue, Sep 30, 2014 at 5:52 PM, Sachini Jayasekara 
wrote:

> Hi all,
>
> New Siddhi implementation supports custom functions and custom output
> aggregators.
>
> Custom functions can be written extending the FunctionExecutor class.
>
> Custom output aggregators can be written implementing AttributeAggregator
> interface. In earlier version, to write a custom output aggregator,  user
> had to implement both OutputAttributeAggregatorFactory and
> OutputAttributeAggregator interfaces. (Now there is no need to implement 2
> interfaces user can simply add the logic to one class which implements
> AttributeAggregator interface).
>
> Then the implemented custom classes has to be compiled and the jar files
> should be added to the class path.
> User then has to add the custom function name and  fully-qualified class
> name of the custom extension to a file named  "namespace of the
> function/aggregator . siddhiext". (eg:- if namespace of a
> function/aggregator is "currency"  function/aggregator name and
>  fully-qualified class name should be added to a file named
> currency.siddhiext ). For each extension .siddhiext should be created. This
> file should also be added to class path.
>
> In earlier version, jars and siddhiext files have to be added to specific
> locations but now user can and those to anywhere in class path.
>
> Extension loading process of  Siddhi will search for files ending with
>  .siddhiext in class path and add them as extensions.
> User can refer to the custom classes giving the namespace and function
> name.
>
> Thanks
>
> --
>
>
>
> *Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *
>
> *lean . enterprise . middleware |  http://wso2.com  *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Manoj Gunawardena
Tech Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
Mobile : +94 77 2291643
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Siddhi] Extension Support

[Srinath Perera]

+1

On Tue, Sep 30, 2014 at 5:52 PM, Sachini Jayasekara 
wrote:

> Hi all,
>
> New Siddhi implementation supports custom functions and custom output
> aggregators.
>
> Custom functions can be written extending the FunctionExecutor class.
>
> Custom output aggregators can be written implementing AttributeAggregator
> interface. In earlier version, to write a custom output aggregator,  user
> had to implement both OutputAttributeAggregatorFactory and
> OutputAttributeAggregator interfaces. (Now there is no need to implement 2
> interfaces user can simply add the logic to one class which implements
> AttributeAggregator interface).
>
> Then the implemented custom classes has to be compiled and the jar files
> should be added to the class path.
> User then has to add the custom function name and  fully-qualified class
> name of the custom extension to a file named  "namespace of the
> function/aggregator . siddhiext". (eg:- if namespace of a
> function/aggregator is "currency"  function/aggregator name and
>  fully-qualified class name should be added to a file named
> currency.siddhiext ). For each extension .siddhiext should be created. This
> file should also be added to class path.
>
> In earlier version, jars and siddhiext files have to be added to specific
> locations but now user can and those to anywhere in class path.
>
> Extension loading process of  Siddhi will search for files ending with
>  .siddhiext in class path and add them as extensions.
> User can refer to the custom classes giving the namespace and function
> name.
>
> Thanks
>
> --
>
>
>
> *Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *
>
> *lean . enterprise . middleware |  http://wso2.com  *
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Siddhi] Extension Support

[Sachini Jayasekara]

Hi all,

New Siddhi implementation supports custom functions and custom output
aggregators.

Custom functions can be written extending the FunctionExecutor class.

Custom output aggregators can be written implementing AttributeAggregator
interface. In earlier version, to write a custom output aggregator,  user
had to implement both OutputAttributeAggregatorFactory and
OutputAttributeAggregator interfaces. (Now there is no need to implement 2
interfaces user can simply add the logic to one class which implements
AttributeAggregator interface).

Then the implemented custom classes has to be compiled and the jar files
should be added to the class path.
User then has to add the custom function name and  fully-qualified class
name of the custom extension to a file named  "namespace of the
function/aggregator . siddhiext". (eg:- if namespace of a
function/aggregator is "currency"  function/aggregator name and
 fully-qualified class name should be added to a file named
currency.siddhiext ). For each extension .siddhiext should be created. This
file should also be added to class path.

In earlier version, jars and siddhiext files have to be added to specific
locations but now user can and those to anywhere in class path.

Extension loading process of  Siddhi will search for files ending with
 .siddhiext in class path and add them as extensions.
User can refer to the custom classes giving the namespace and function name.

Thanks

-- 



*Thanks & Regards,Sachini JayasekaraSoftware Engineer; **WSO2 Inc. *

*lean . enterprise . middleware |  http://wso2.com  *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture