Re: [Carbon-dev] [Architecture] Revamping Message Routing Mediators in ESB

2011-10-03 Thread Amila Suriarachchi 
On Tue, Oct 4, 2011 at 11:45 AM, Srinath Perera  wrote:

> +1 .. if we can replace all with one mediator .. that is great! but we
> have to carefully design the syntax to make sure final result is
> natural for all cases.
>

I think there are two ends for this. One is making it general. Other think
is make common case simple.

Current filter (it actually does some thing like if) mediator configurations
can be as follows.

 
  
  
   
   
  
  
   

former 'xpath' is referred to an xpath returning a boolean while the
'source' attribute refer to an xpath returning a text value. Here it has
tried to cover different specific scenarios which make that particular
occasion to use it easily.

But we if follow an method like BPEL by using another copy mediator (in fact
I think these are not mediators but some language constructs). It would have
written like this.




  
  



  
  


then it is more generic. And no need to repeat the xpath, source veriables
with each mediator. But for a simple xpath based filter need to use another
copy mediator etc ..

thanks,
Amila.






> --Srinath
>
> On Fri, Sep 30, 2011 at 3:03 PM, Kasun Indrasiri  wrote:
> > Hi all,
> > In the current ESB implementation we have couple of mediators for message
> > routing. While 'Filter' and 'Switch' mediators provide basic level of
> > message filtering, router mediator is also doing very similar to what
> > filter/switch mediators do. The usage of Router mediator is rare and
> often
> > got replaced by filter/switch mediators. So, IMO, Router Mediator is
> > redundant, unless it provides some advance/complex routing logic support.
> > In the ESB 4.0.0 release, we introduces 'Conditional Router', which is
> > intended to route messages based on HTTP headers, query parameters and
> url.
> > However, this doesn't support routing based on message payload. But
> unlike
> > 'Router', the 'Conditional Router' introduces uses the concepts of
> > 'Evaluators' (And, Or, Match, Equal, Not) that can be utilize to
> construct
> > complex routing logics.
> > eg:
> >  
> > 
> > 
> > 
> >  > source="my_custom_header1" regex="foo.*"/>
> >  > regex="/services/StockQuoteProxy.*"/>
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  > source="my_custom_header2" regex="bar.*"/>
> >  > value="qpv_foo"/>
> > 
> >  > regex="/services/StockQuoteProxy.*"/>
> >  > source="my_custom_header3" regex="foo.*"/>
> > 
> > 
> >  > value="qpv_bar"/>
> > 
> > 
> > 
> > 
> > 
> > 
> > So, we can easily add message level routing capability(so that we can
> drop
> > Router mediator) to Conditional Router and with that we'll get the power
> of
> > using evaluators for message level routing as well. Having bunch of
> > mediators that's doing the similar thing, cause a negative effect on
> ESB's
> > usability.
> > (Most of the pointed listed here, were discussed during last code-review
> of
> > Group-D.)
> >
> >
> > [1] http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html
> >
> > Thanks,
> > --
> > Kasun Indrasiri
> > Associate Technical Lead
> > WSO2, Inc.; http://wso2.com
> > lean.enterprise.middleware
> >
> > cell: +94 71 536 4128
> > Blog : http://kasunpanorama.blogspot.com/
> >
>
>
>
> --
> 
> Srinath Perera, Ph.D.
>   Senior Software Architect, WSO2 Inc.
>   Visiting Faculty, University of Moratuwa
>   Member, Apache Software Foundation
>   Research Scientist, Lanka Software Foundation
>   Blog: http://srinathsview.blogspot.com/
> ___
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [Architecture] Revamping Message Routing Mediators in ESB

2011-10-03 Thread Srinath Perera 
+1 .. if we can replace all with one mediator .. that is great! but we
have to carefully design the syntax to make sure final result is
natural for all cases.
--Srinath

On Fri, Sep 30, 2011 at 3:03 PM, Kasun Indrasiri  wrote:
> Hi all,
> In the current ESB implementation we have couple of mediators for message
> routing. While 'Filter' and 'Switch' mediators provide basic level of
> message filtering, router mediator is also doing very similar to what
> filter/switch mediators do. The usage of Router mediator is rare and often
> got replaced by filter/switch mediators. So, IMO, Router Mediator is
> redundant, unless it provides some advance/complex routing logic support.
> In the ESB 4.0.0 release, we introduces 'Conditional Router', which is
> intended to route messages based on HTTP headers, query parameters and url.
> However, this doesn't support routing based on message payload. But unlike
> 'Router', the 'Conditional Router' introduces uses the concepts of
> 'Evaluators' (And, Or, Match, Equal, Not) that can be utilize to construct
> complex routing logics.
> eg:
>  
>                     
>                         
>                             
>                                  source="my_custom_header1" regex="foo.*"/>
>                                  regex="/services/StockQuoteProxy.*"/>
>                             
>                         
>                         
>                     
>                     
>                         
>                             
>                                  source="my_custom_header2" regex="bar.*"/>
>                                  value="qpv_foo"/>
>                                 
>                                      regex="/services/StockQuoteProxy.*"/>
>                                      source="my_custom_header3" regex="foo.*"/>
>                                 
>                                 
>                                      value="qpv_bar"/>
>                                 
>                             
>                         
>                         
>                     
> 
> So, we can easily add message level routing capability(so that we can drop
> Router mediator) to Conditional Router and with that we'll get the power of
> using evaluators for message level routing as well. Having bunch of
> mediators that's doing the similar thing, cause a negative effect on ESB's
> usability.
> (Most of the pointed listed here, were discussed during last code-review of
> Group-D.)
>
>
> [1] http://wso2.org/project/esb/java/4.0.0/docs/mediator_guide.html
>
> Thanks,
> --
> Kasun Indrasiri
> Associate Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 71 536 4128
> Blog : http://kasunpanorama.blogspot.com/
>



-- 

Srinath Perera, Ph.D.
  Senior Software Architect, WSO2 Inc.
  Visiting Faculty, University of Moratuwa
  Member, Apache Software Foundation
  Research Scientist, Lanka Software Foundation
  Blog: http://srinathsview.blogspot.com/
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Updated Invitation: [Code Review] [Group B] Message box core - connection reuse @ Tue Oct 4 10:30am - 11:30am (nu...@wso2.com)

2011-10-03 Thread Nuwan Bandara 
GROUP B, Reminder !!!

On Tue, Oct 4, 2011 at 10:02 AM, Shammi Jayasinghe  wrote:

>  This event has been changed.
> more details 
> »
> [Code Review] [Group B] Message box core - connection reuse
> *Changed: *crcuible link : 
> https://wso2.org/crucible/cru/COMPONENT-63
>  *When*
> Tue Oct 4 10:30am – 11:30am Colombo
> *Where*
> #59 - Board Room (map
> )
> *Calendar*
> nu...@wso2.com
> *Who*
> •
> sha...@wso2.com - organizer
> •
> Chamara Ariyarathne
> •
> Achala Aponso
> •
> Deependra Ariyadewa
> •
> Dimuthu Leelarathne
> •
> Manjula Rathnayake
> •
> Nuwan Bandara
> •
> carbon-dev@wso2.org
> •
> Krishantha Samaraweera
> •
> Nuwan Wimalasekara
> •
> Sanjeewa Malalgoda
> •
> Anjana Fernando
> •
> Nandika Jayawardana
> •
> Ajith Vitharana
> •
> Thilini Ishaka
> •
> Jasintha Dasanayake
>
> Going?   
> ***Yes-
> Maybe-
> No
> ***more options 
> »
>
> Invitation from Google Calendar 
>
> You are receiving this email at the account nu...@wso2.com because you are
> subscribed for updated invitations on calendar nu...@wso2.com.
>
> To stop receiving these notifications, please log in to
> https://www.google.com/calendar/ and change your notification settings for
> this calendar.
>



-- 
*Thanks & Regards,

Nuwan Bandara
Senior Software Engineer
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware

http://nuwan.bandara.co
*

___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] Updated Invitation: [Code Review] [Group B] Message box core - connection reuse @ Tue Oct 4 10:30am - 11:30am (carbon-dev@wso2.org)

2011-10-03 Thread Shammi Jayasinghe 
BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20111004T05Z
DTEND:20111004T06Z
DTSTAMP:20111004T043202Z
ORGANIZER;CN=sha...@wso2.com:mailto:sha...@wso2.com
UID:18khuh0nbpcr03n0tp6u7c4...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Ajith Vitharana;X-NUM-GUESTS=0:mailto:aji...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Thilini Ishaka;X-NUM-GUESTS=0:mailto:thil...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Achala Aponso;X-NUM-GUESTS=0:mailto:ach...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Nuwan Bandara;X-NUM-GUESTS=0:mailto:nu...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=carbon-dev@wso2.org;X-NUM-GUESTS=0:mailto:carbon-dev@wso2.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Nuwan Wimalasekara;X-NUM-GUESTS=0:mailto:nuw...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Manjula Rathnayake;X-NUM-GUESTS=0:mailto:manju...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Jasintha Dasanayake;X-NUM-GUESTS=0:mailto:jasin...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Deependra Ariyadewa;X-NUM-GUESTS=0:mailto:d...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Shammi Jayasinghe;X-NUM-GUESTS=0:mailto:sha...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Sanjeewa Malalgoda;X-NUM-GUESTS=0:mailto:sanje...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Chamara Ariyarathne;X-NUM-GUESTS=0:mailto:chama...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Krishantha Samaraweera;X-NUM-GUESTS=0:mailto:krishan...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=Nandika Jayawardana;X-NUM-GUESTS=0:mailto:nand...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Dimuthu Leelarathne;X-NUM-GUESTS=0:mailto:dimut...@wso2.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=Anjana Fernando;X-NUM-GUESTS=0:mailto:anj...@wso2.com
CREATED:20110927T055351Z
DESCRIPTION:crcuible link : https://wso2.org/crucible/cru/COMPONENT-63\nVie
 w your event at http://www.google.com/calendar/event?action=VIEW&eid=MThraH
 VoMG5icGNyMDNuMHRwNnU3YzRuMjAgY2FyYm9uLWRldkB3c28yLm9yZw&tok=MTUjc2hhbW1pQH
 dzbzIuY29tMGIxNjM4MDk5Y2U3MzVmODNmMWY4NjliZjBlMWUzNmMzNGVhODI5Mw&ctz=Asia%2
 FColombo&hl=en.
LAST-MODIFIED:20111004T043201Z
LOCATION:#59 - Board Room
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:[Code Review] [Group B] Message box core - connection reuse
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [AS] Go to URL in Web app UI always assume an index.jsp

2011-10-03 Thread Afkham Azeez 
Webapp listing page only links go the webapp's context. So if a welcome page
is specified, the proper home page will show up.


Sent from my phone
On Oct 4, 2011 6:56 AM, "Sumedha Rubasinghe"  wrote:
> On Tue, Oct 4, 2011 at 6:41 AM, Samisa Abeysinghe  wrote:
>
>> It would be nice to be able to map my go to URL to a non index page.
>>
>
> You can get this customized by using welcome page in web.xml. As a default
> setting, we have assumed it to be the index.jsp when creating the link on
> Web App listing page (which is pretty much standard).
>
> But of course we do not read the web.xml & change the url in web app
listing
> page accordingly.
> /sumedha
>
>
>> Thanks,
>> Samisa...
>>
>> Samisa Abeysinghe
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>>
>>
>> ___
>> Carbon-dev mailing list
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] [AS] Go to URL in Web app UI always assume an index.jsp

2011-10-03 Thread Sumedha Rubasinghe 
On Tue, Oct 4, 2011 at 6:41 AM, Samisa Abeysinghe  wrote:

> It would be nice to be able to map my go to URL to a non index page.
>

You can get this customized by using welcome page in web.xml. As a default
setting, we have assumed it to be the index.jsp when creating the link on
Web App listing page (which is pretty much standard).

But of course we do not read the web.xml & change the url in web app listing
page accordingly.
/sumedha


>  Thanks,
> Samisa...
>
> Samisa Abeysinghe
> VP Engineering
> WSO2 Inc.
> http://wso2.com
> http://wso2.org
>
>
> ___
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] [AS] Go to URL in Web app UI always assume an index.jsp

2011-10-03 Thread Samisa Abeysinghe 
It would be nice to be able to map my go to URL to a non index page.

Thanks,
Samisa...

Samisa Abeysinghe
VP Engineering
WSO2 Inc.
http://wso2.com
http://wso2.org
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

[Carbon-dev] [CS] Refactoring CS branch and trunk to remove jars from svn

2011-10-03 Thread Harshana Martin 
Hi All,

Currently we have included a set of third party jars to CS and included them
in the svn as well. This was a requirement with our previous build system.
Since we moved to Tycho recently, now we do not need to commit the jars to
svn. Therefore I'm planning on doing a refactoring both CS branch and Trunk
to remove these jars.

This will reduce the time to checkout the CS branch and trunk significantly.
Meantime please note that there might be CS build failures time to time.

Thanks and Regards,
Harshana
-- 
Harshana Martin
Software Engineer
WSO2 Inc.
Web:http://wso2.com
  http://wso2.org

Mobile: +94 716062650
Blog: http://harshana05.blogspot.com
Profile: https://www.google.com/profiles/harshana05
Twitter: http://twitter.com/harshana05
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] equinox 3.7 migration effort.

2011-10-03 Thread Pradeep Fernando 
Hi,

On Sat, Sep 10, 2011 at 11:17 PM, Paul Fremantle  wrote:

> Can we have a short review to help me understand!?


scheduled a meeting on 6 th Oct 2011, 1.30 - 2.10 pm (SL time). please feel
free to change the meeting times, if you have any other commitments.

thanks,
--Pradeep
___
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Re: [Carbon-dev] Making scheduled-tasks feature self contained

2011-10-03 Thread Tharindu Mathew 
Hi Hiranya,

We managed to fix the bam2 build with minimum requirements.

Realize that we need:

   - task server feature
   - synapse feature
   - mediation initializer feature

to be able to run tasks. I believe it should come down to,

   - task server feature
   - synapse tasks feature


On Sun, Oct 2, 2011 at 10:09 AM, Hiranya Jayathilaka wrote:

>
>
> On Sat, Oct 1, 2011 at 11:53 PM, Tharindu Mathew wrote:
>
>> From what I've seen, everyone uses their own job implementation. Ex: BAM
>> uses AnalyzerJob.class
>>
>> The pain points maybe coming from re-using scheduled tasks. It does not
>> seem to work in an OSGI environment, without having Synapse. Because we do
>> not directly use synapse tasks, we re-use scheduled-tasks.
>>
>> I feel defining the carbon-tasks feature alone, will fix the problem.
>> According to your explanation, Carbon tasks may have a dependency to
>> synapse-core, so that it can use SimpleQuartzJob.
>>
>
> Ok makes sense. So may be the culprit is the scheduled tasks component. It
> may be tightly coupled with rest of Synapse/ESB. Will look into that.
>
> Thanks,
> Hiranya
>
>
>>
>>
>> On Sat, Oct 1, 2011 at 11:41 PM, Hiranya Jayathilaka wrote:
>>
>>> I just tried to develop a little Java program using the Synapse tasks
>>> module (just a learning exercise to see where the pain points are). However
>>> I was able to do it without much of a hassle and without adding any Synapse
>>> libraries except for the synapse-tasks.jar. Here's my code in the main
>>> method:
>>>
>>> TaskScheduler scheduler = new TaskScheduler("scheduler1");
>>> scheduler.init(new Properties());
>>> scheduler.start();
>>> TaskDescription desc = new TaskDescription();
>>> desc.setName("task1");
>>> desc.setInterval(2000);
>>> scheduler.scheduleTask(desc, new HashMap(), *
>>> TestJob.class*, *new MyTask()*);
>>>
>>> Here TestJob is an implementation of the Quartz Job interface. MyTask is
>>> an implementation of the Task interface from Synapse. All other Task*
>>> classes are from Synapse tasks module. Libraries in my classpath are:
>>>
>>>- synapse-tasks
>>>- quartz
>>>- commons-logging
>>>- geronimo-jta (Quartz dependency)
>>>- commons-collections (Quartz dependency)
>>>
>>> So it's not that bad after all. I think the trick here is I'm using my
>>> own Job implementation. The default implementation that comes with Synapse
>>> (SimpleQuartzJob) is in the synapse-core module and if you try to use that
>>> you will have to add a whole bunch of other Synapse related stuff. I don't
>>> think anything other than Synapse are supposed to use it since it clearly
>>> has some Synapse specific stuff in there. We use that as the bridge between
>>> Synapse and Quartz.
>>>
>>> I think any component trying to use the Synapse tasks component should
>>> simply write their own Job implementation and use the framework provided by
>>> Synapse tasks component to run it. You can put any component specific logic
>>> in the Job impl. Here's my Job implementation BTW (used in above example):
>>>
>>> public void execute(JobExecutionContext ctx) throws JobExecutionException
>>> {
>>>Task task = (Task)
>>> ctx.getMergedJobDataMap().get(TaskDescription.INSTANCE);
>>>task.execute();
>>> }
>>>
>>> What are the other issues faced while trying to use the Synapse tasks
>>> component?
>>>
>>> Thanks,
>>> Hiranya
>>>
>>> On Sat, Oct 1, 2011 at 10:47 PM, Tharindu Mathew wrote:
>>>


 On Sat, Oct 1, 2011 at 10:17 PM, Hiranya Jayathilaka 
 wrote:

>
>
> On Sat, Oct 1, 2011 at 7:38 PM, Anjana Fernando wrote:
>
>> Hiranya agreed to refactor the Synapse tasks component to have a
>> simpler API, which will make it more easier to use.
>
>
> Yes will get started on this asap.
>
> Great!

> Thanks,
> Hiranya
>
>
>> I'm also looking into creating a "coordination" component, by using
>> Apache ZooKeeper, to do the coordination scenarios in a cluster, which 
>> are
>> required in situations like scheduling a task.
>>
>> These efforts can be parellel, i.e. making it self contained will
 actually help after the task tracker component as well, otherwise you will
 have to inclue all of synapse as well, just to get task dependencies.

> Cheers,
>> Anjana.
>>
>>
>> On Sat, Oct 1, 2011 at 1:27 PM, Tharindu Mathew wrote:
>>
>>>
>>>
>>> On Sat, Oct 1, 2011 at 1:18 PM, Samisa Abeysinghe 
>>> wrote:
>>>


 On Sat, Oct 1, 2011 at 1:03 PM, Tharindu Mathew 
 wrote:

> Hi ESB folks,
>
> Right now, if we just import the carbon.task.server feature, the
> tasks do not start up during run time due to unsatisfied dependencies.
>
> So, we have to import whole of synapse as well just to make tasks
> work. So, can we do $subject urgently?
>

 This I thought was done by the new