Re: [Dev] BRS 2.1.0 Alpha testing update

[Chathurika De Silva]

Hi

We are testing BRS Alpha (2.1.0) pack with ELB Alpha release. The
previously mentioned issue is now closed.

Best Regards


On Wed, May 7, 2014 at 5:22 PM, Sandapa Handakumbura wrote:

> Hi All,
>
> We have set up the BRS W/M separated cluster with ELB 2.1.0 and started
> functional testing in the clustered setup. We will be following [1] as our
> test plan (during testing more scenarios will be added if required).
>
> [1]
> https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0AnpVKBDCKX9ldERGSzFZaUxJMWFKVlVObEh0akJYRnc&usp=sharing#gid=1
>
> Regards,
> Sandapa
>
>
> On Wed, May 7, 2014 at 11:55 AM, Chathurika De Silva  > wrote:
>
>> Hi All
>>
>> We tried to set up the cluster for above mentioned BRS version using ELB
>> 2.1.1. We encountered the following blocker which we reported under LB-147
>>
>> Due the above issue, we are moving to ELB 2.1.0 for our further testing
>> process until the issue is fixed.
>>
>> Best Regards
>>
>> --
>> *Chathurika Erandi*
>> Software Engineer,
>> WSO2 Inc.
>>
>> *E-mail:* chathuri...@wso2.com
>> *Mobile: *+94714 328 612
>> *Blog*: chathurikaerandi.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sandapa Handakumbura
> Associate Technical Lead
> WSO2.Inc. ; http://wso2.com/
> M : +94777115866
>



-- 
*Chathurika Erandi*
Software Engineer,
WSO2 Inc.

*E-mail:* chathuri...@wso2.com
*Mobile: *+94714 328 612
*Blog*: chathurikaerandi.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Kernel commit in javax.cache

[Malintha Adikari]

Hi Kishanthan,

Please commit following attached patches to kernel ->core -> javax.cache
module (to patch008)

[1]https://wso2.org/jira/browse/CARBON-14795


Regards,
Malintha Adikari
-- 
*Malintha Adikari*
 Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

Mobile: +94 71 2312958
Blog:http://malinthas.blogspot.com
Page:   http://about.me/malintha
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 ESB Connector Store Icons

[Chanaka Jayasena]

580 x 300 banner
220 x 200 icon thumb

thanks,
Chanaka


On Thu, May 8, 2014 at 8:49 AM, Malaka Silva  wrote:

> Hi Chanaka,
>
> What is the resolution you have used for log and banner.
>
> We may need to use the same for other connectors?
>
> Best Regards,
> Malaka
>
>
> On Sun, May 4, 2014 at 11:26 AM, Chanaka Jayasena wrote:
>
>> Hi Dushan, the Google drive is updated with the latest.
>>
>> thanks,
>> Chanaka
>>
>>
>> On Fri, May 2, 2014 at 5:35 PM, Chanaka Jayasena wrote:
>>
>>> Noted. I will update and provide you with the remaining connector icons
>>> as well.
>>>
>>> Thanks,
>>> Chanaka
>>>
>>>
>>> On Fri, May 2, 2014 at 1:20 PM, Dushan Abeyruwan wrote:
>>>
 Hi ChanakaJ

 On Fri, May 2, 2014 at 9:00 AM, Malaka Silva  wrote:

> Hi All,
>
> IMO we should not modify the backgroung color and layout outside what
> vendors(Third parties) are using.
>
> Eg: - Salesforce logo is in green color whereas standard is blue.
>

Yes, I feel the same as we should not modify exiting vendors layout
 colors, overall felt only salesforce has such issue.

 meantime, can we get the remaining connector images as well [1] shows
 you the connectors we have at the moment

 https://github.com/wso2-dev/esb-connectors

   we should add, facebook,gmail.amazon s3,google drive,suvaymonkey,
 sugerCRM.

>
> Best Regards,
> Malaka
>
>
> On Fri, May 2, 2014 at 8:08 AM, Chanaka Jayasena wrote:
>
>> Hi Dushan,
>>
>> [1] contains the images you requested for the Connector Store. Amazon
>> s3 and Survey Monkey icons are missing. I will upload those ones they are
>> done.
>>
>> 1 -
>> https://drive.google.com/a/wso2.com/folderview?id=0B_CCkDYHWyB9VGlJc0MzWnRpYkU&usp=sharing#grid
>>
>> thanks,
>> Chanaka
>>
>> --
>> Chanaka Jayasena
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> email: chan...@wso2.com; cell: +94 77 785 5565
>> blog: http://chanaka3d.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Tech Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
>
> Save a tree -Conserve nature & Save the world for your future. Print
> this email only if it is absolutely necessary.
>



 --
 Dushan Abeyruwan | Associate Tech Lead
  Integration Technologies Team
 PMC Member Apache Synpase
 WSO2 Inc. http://wso2.com/
 Blog:http://dushansview.blogspot.com/
 Mobile:(0094)713942042


>>>
>>>
>>> --
>>> Chanaka Jayasena
>>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>>> email: chan...@wso2.com; cell: +94 77 785 5565
>>> blog: http://chanaka3d.blogspot.com
>>>
>>
>>
>>
>> --
>> Chanaka Jayasena
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> email: chan...@wso2.com; cell: +94 77 785 5565
>> blog: http://chanaka3d.blogspot.com
>>
>
>
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Tech Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it is absolutely necessary.
>



-- 
Chanaka Jayasena
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
email: chan...@wso2.com; cell: +94 77 785 5565
blog: http://chanaka3d.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Need migration scripts for IS 5.0.0

[Suneth Ranasinghe]

Reminder, on $subject.


On Thu, Apr 17, 2014 at 11:28 AM, Pavithra Madurangi wrote:

> Hi Darshana,
>
> Can we have $subject before IS 5.0.0 is released. Created a jira [1] to
> keep track of this.
>
> [1] https://wso2.org/jira/browse/IDENTITY-2150
>
> Thanks,
> Pavithra
>
>


-- 
Suneth Ranasinghe
Senior Software Engineer - QA
Mobile: +94717387198

wso2.com
Lean Enterprise Middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [C5] Kernel build fails when using org.osgi.framework.wiring package

[Aruna Karunarathna]

Hi Kishanthan,

Thanks for the reply. It worked.

I think using
org.osgi.framework.*;version="${osgi.framework.import.version.range}"
masks the *org.osgi.framework.wiring.* *import also.


Regards,


On Mon, May 5, 2014 at 12:52 PM, Kishanthan Thangarajah  wrote:

> You need to import only the required packages. ".*" imports all the sub
> packages with the defined version. Try removing that and check again.
>
>
> On Fri, May 2, 2014 at 1:36 PM, Aruna Karunarathna  wrote:
>
>> Hi all,
>>
>> I'm using the org.osgi.framework.wiring in a carbon component and the
>> following error occurs when I try to build.
>>
>> Cannot complete the install because one or more required items could not
>> be found.
>> Software being installed: WSO2 Carbon Kernel - Carbon Server Feature
>> 5.0.0.SNAPSHOT (org.wso2.carbon.core.server.feature.group 5.0.0.SNAPSHOT)
>> Missing requirement: WSO2 Carbon Kernel - Patching 5.0.0.SNAPSHOT
>> (org.wso2.carbon.patching 5.0.0.SNAPSHOT) requires '*package
>> org.osgi.framework.wiring [1.7.0,1.8.0)*' but it could not be found
>>  Cannot satisfy dependency:
>>   From: WSO2 Carbon Kernel - Carbon Server Feature 5.0.0.SNAPSHOT
>> (org.wso2.carbon.core.server.feature.group 5.0.0.SNAPSHOT)
>>   To: org.wso2.carbon.patching [5.0.0.SNAPSHOT]
>> Application failed, log file location:
>> /home/aruna/.m2/repository/org/eclipse/tycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1399013930201.log
>>
>> [INFO]
>> 
>> [INFO] Reactor Summary:
>> [INFO]
>> [INFO] WSO2 Carbon Kernel - Parent Pom ... SUCCESS
>> [0.120s]
>> [INFO] WSO2 Carbon Kernel - Dependent Projects ... SUCCESS
>> [0.006s]
>> [INFO] WSO2 Carbon Kernel - Maven P2 Profile Gen Plugin .. SUCCESS
>> [2.329s]
>> [INFO] WSO2 Carbon Kernel - Launcher . SUCCESS
>> [1.418s]
>> [INFO] WSO2 Carbon Kernel - Configuration and Context Model  SUCCESS
>> [0.782s]
>> [INFO] WSO2 Carbon Kernel - Server Configuration . SUCCESS
>> [1.053s]
>> [INFO] WSO2 Carbon Kernel - Utils  SUCCESS
>> [0.206s]
>> [INFO] WSO2 Carbon Kernel - Deployment Engine  SUCCESS
>> [0.824s]
>> [INFO] WSO2 Carbon Kernel - Samples / Hello World Bundle . SUCCESS
>> [0.173s]
>> [INFO] WSO2 Carbon Kernel - Samples / Webapp Bundle .. SUCCESS
>> [0.216s]
>> [INFO] WSO2 Carbon Kernel - Runtime Manager .. SUCCESS
>> [0.650s]
>> [INFO] WSO2 Carbon Kernel - Clustering ... SUCCESS
>> [37.122s]
>> [INFO] WSO2 Carbon Kernel - Transport  SUCCESS
>> [0.224s]
>> [INFO] WSO2 Carbon Kernel - Extensions ... SUCCESS
>> [0.166s]
>> [INFO] WSO2 Carbon Kernel - Patching . SUCCESS
>> [0.205s]
>> [INFO] WSO2 Carbon Kernel - Features Parent .. SUCCESS
>> [0.004s]
>> [INFO] WSO2 Carbon Kernel - Carbon Server Feature  SUCCESS
>> [0.268s]
>> [INFO] WSO2 Carbon Kernel - Carbon Runtime Feature ... SUCCESS
>> [0.235s]
>> [INFO] WSO2 Carbon Kernel - Distribution . FAILURE
>> [7.823s]
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 54.513s
>> [INFO] Finished at: Fri May 02 12:28:51 IST 2014
>> [INFO] Final Memory: 55M/982M
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.wso2.maven:carbon-p2-plugin:1.5.4-SNAPSHOT:p2-profile-gen
>> (feature-installation) on project wso2carbon-kernel: P2 publisher return
>> code was 13 -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with the
>> command
>> [ERROR]   mvn  -rf :wso2carbon-kernel
>>
>>
>> Following is the Import-Package of the  pom.xml file, of the component.
>>
>> 
>> org.slf4j.*;version="${slf4j.logging.import.version.range}",
>> org.osgi.framework.*;version="${osgi.framework.import.version.range}",
>> *org.osgi.framework.wiring.*;version="[1.1.0, 1.2.0)",*
>>
>> org.wso2.carbon.utils.*;version="${carbon.kernel.package.import.version.range}",
>>
>> javax.xml.bind.*;version="${osgi.framework.packages.import.version.range}",
>>
>> javax.xml.validation.*;version="${osgi.framework.packages.import.version.range}",
>>
>> javax.xml.transform.*;version="${osgi.framework.packages.import.version.range}",
>> 
>>
>>
>> What may be the cause for the above error?.. Any help is highly
>> appreciated.
>>
>>
>> Regards,
>>
>>

[Dev] Getting an Instance of DataSource Object

[Harshan Liyanage]

Hi,

I need to get an instance of DataSource object. While going through
the JDBCPersistenceManager
classin
org.wso2.carbon.identity.core/4.2.3 module I have found following code
block. Can I use this way to access the DataSource object?

String dataSourceName = dataSourceNameElem.getText();
Context ctx = new InitialContext();
dataSource = (DataSource) ctx.lookup(dataSourceName);


Thanks,


Best Regards,

Lakshitha Harshan
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog : http://harshanliyanage.blogspot.com/
*WSO2, Inc. :** wso2.com *
lean.enterprise.middleware.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Best approach to removing stratos.common.server.feature from a product

[Chamath Gunawardana]

Hi Amila,

This has been moved to location [1].

[1] - https://github.com/wso2/carbon-multitenancy/tree/master/components



On Thu, May 8, 2014 at 10:17 AM, Amila Maha Arachchi wrote:

> Hi Kasun,
>
> I can't find the tenant-mgt component in the location you have mentioned.
>
>
> On Fri, Apr 18, 2014 at 5:31 PM, Kasun Gajasinghe  wrote:
>
>> Hi AmilaM, SameeraM,
>>
>> The tenant-mgt components and features are already available in 4.3.0
>> [1]. You can find the components we brought back in the thread "Removing
>> Stratos features from Carbon 4.3.0 Products" in architecture list.
>>
>> [1]
>> https://github.com/wso2/carbon-commons/tree/master/components/tenant-mgt/
>>
>> Regards,
>> KasunG
>>
>>
>>
>> On Fri, Apr 18, 2014 at 3:25 PM, Amila Maha Arachchi wrote:
>>
>>> Lot of components bundled in stratos.common feature are not needed for
>>> individual products now. They were needed for StratosLive setup. But I
>>> cannot be sure about which bundles are needed and which are not.
>>>
>>> Following are the components bundled and features imported in this
>>> feature. IMO, we only need tenant-mgt components. So, we can get rid of
>>> stratos.common feature and try only adding tenant-mgt features to the
>>> product.
>>>
>>> To do that, we need to add the tenant-mgt components to Git. Who can
>>> help with it?
>>>
>>> 
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.stratos.common:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.redirector.servlet
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.activation:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.sample.installer:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.dispatcher
>>>
>>>
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.stratos.landing.page.deployer
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> org.json.wso2:json
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.mgt:${stratos.version}
>>>
>>>
>>> kaptcha.wso2:kaptcha
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.keystore.mgt
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.mgt.core:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.captcha.mgt
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.theme.mgt:${stratos.version}
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> org.apache.rampart.wso2:rampart-policy
>>>
>>>
>>> org.apache.rampart.wso2:rampart-core
>>>
>>>
>>> org.apache.rampart.wso2:rampart-trust
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.application.upload
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> org.wso2.carbon.core.server:${wso2carbon.version}
>>>
>>>
>>> org.wso2.carbon.identity.authenticator.saml2.sso.server:${carbon.version}
>>>
>>>
>>> org.wso2.carbon.registry.core.server:${carbon.version}
>>>
>>> 
>>>
>>>
>>>
>>> On Fri, Apr 18, 2014 at 2:50 PM, Sameera Medagammaddegedara <
>>> samee...@wso2.com> wrote:
>>>
 Hi Everyone,

 *Background*

- The Enterprise Store (ES) and the Cassandra components require
the stratos.common.server.feature :2.2.1
- At the moment we are in the process of moving ES to Carbon 4.3.0
for the next Governance Registry milestone.

 *Problem*

- The stratos.common.server.feature 2.2.1 cannot be used as it has
dependencies on 4.2.0 features:
org.wso2.carbon.registry.core.server.feature.group
- This feature is used for multitenancy support in the Cassandra
component and is needed by several other products as well.
- In an offline discussion AmilaM , proposed the option of dropping
the feature and utilizing only the components required for 
 multitenancy.In
which case the tenant-mgt component[1] will need to be moved to Git as 
 well.

 *Questions*

- What is the best approach to replacing this feature?


 *References*
 [1]tenant-mgt repository ,URL
 https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/stratos/tenant-mgt/

 Thank You,
 Sameera

 --
 Sameera Medagammaddegedara
 Software Engineer

 Contact:
 Email: samee...@wso2.com
 Mobile: + 94 077 255 3005

>>>
>>>
>>>
>>> --
>>> *Amila Maharachchi*
>>> Senior Technical Lead
>>> WSO2, Inc.; http://wso2.com
>>>
>>> Blog: http://maharachchi.blogspot.com
>>> Mobile: +94719371446
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>>
>>
>>
>
>
>
> --
> *Amila Maharachchi*
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
>
> Blog: http://maharac

Re: [Dev] Best approach to removing stratos.common.server.feature from a product

[Amila Maha Arachchi]

Found it at https://github.com/wso2/carbon-multitenancy


On Thu, May 8, 2014 at 10:17 AM, Amila Maha Arachchi wrote:

> Hi Kasun,
>
> I can't find the tenant-mgt component in the location you have mentioned.
>
>
> On Fri, Apr 18, 2014 at 5:31 PM, Kasun Gajasinghe  wrote:
>
>> Hi AmilaM, SameeraM,
>>
>> The tenant-mgt components and features are already available in 4.3.0
>> [1]. You can find the components we brought back in the thread "Removing
>> Stratos features from Carbon 4.3.0 Products" in architecture list.
>>
>> [1]
>> https://github.com/wso2/carbon-commons/tree/master/components/tenant-mgt/
>>
>> Regards,
>> KasunG
>>
>>
>>
>> On Fri, Apr 18, 2014 at 3:25 PM, Amila Maha Arachchi wrote:
>>
>>> Lot of components bundled in stratos.common feature are not needed for
>>> individual products now. They were needed for StratosLive setup. But I
>>> cannot be sure about which bundles are needed and which are not.
>>>
>>> Following are the components bundled and features imported in this
>>> feature. IMO, we only need tenant-mgt components. So, we can get rid of
>>> stratos.common feature and try only adding tenant-mgt features to the
>>> product.
>>>
>>> To do that, we need to add the tenant-mgt components to Git. Who can
>>> help with it?
>>>
>>> 
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.stratos.common:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.redirector.servlet
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.activation:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.sample.installer:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.dispatcher
>>>
>>>
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.stratos.landing.page.deployer
>>>
>>>
>>>
>>>
>>>
>>> 
>>>
>>> org.json.wso2:json
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.mgt:${stratos.version}
>>>
>>>
>>> kaptcha.wso2:kaptcha
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.keystore.mgt
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.tenant.mgt.core:${stratos.version}
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.captcha.mgt
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.theme.mgt:${stratos.version}
>>>
>>> 
>>>
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> org.apache.rampart.wso2:rampart-policy
>>>
>>>
>>> org.apache.rampart.wso2:rampart-core
>>>
>>>
>>> org.apache.rampart.wso2:rampart-trust
>>>
>>>
>>> org.wso2.carbon:org.wso2.carbon.application.upload
>>>
>>> 
>>>
>>> 
>>>
>>>
>>> org.wso2.carbon.core.server:${wso2carbon.version}
>>>
>>>
>>> org.wso2.carbon.identity.authenticator.saml2.sso.server:${carbon.version}
>>>
>>>
>>> org.wso2.carbon.registry.core.server:${carbon.version}
>>>
>>> 
>>>
>>>
>>>
>>> On Fri, Apr 18, 2014 at 2:50 PM, Sameera Medagammaddegedara <
>>> samee...@wso2.com> wrote:
>>>
 Hi Everyone,

 *Background*

- The Enterprise Store (ES) and the Cassandra components require
the stratos.common.server.feature :2.2.1
- At the moment we are in the process of moving ES to Carbon 4.3.0
for the next Governance Registry milestone.

 *Problem*

- The stratos.common.server.feature 2.2.1 cannot be used as it has
dependencies on 4.2.0 features:
org.wso2.carbon.registry.core.server.feature.group
- This feature is used for multitenancy support in the Cassandra
component and is needed by several other products as well.
- In an offline discussion AmilaM , proposed the option of dropping
the feature and utilizing only the components required for 
 multitenancy.In
which case the tenant-mgt component[1] will need to be moved to Git as 
 well.

 *Questions*

- What is the best approach to replacing this feature?


 *References*
 [1]tenant-mgt repository ,URL
 https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/stratos/tenant-mgt/

 Thank You,
 Sameera

 --
 Sameera Medagammaddegedara
 Software Engineer

 Contact:
 Email: samee...@wso2.com
 Mobile: + 94 077 255 3005

>>>
>>>
>>>
>>> --
>>> *Amila Maharachchi*
>>> Senior Technical Lead
>>> WSO2, Inc.; http://wso2.com
>>>
>>> Blog: http://maharachchi.blogspot.com
>>> Mobile: +94719371446
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>>
>>
>>
>
>
>
> --
> *Amila Maharachchi*
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
>
> Blog: http://maharachchi.blogspot.com
> Mobile: +94719371446
>
>


-- 
*Amila Maharachc

Re: [Dev] Best approach to removing stratos.common.server.feature from a product

[Amila Maha Arachchi]

Hi Kasun,

I can't find the tenant-mgt component in the location you have mentioned.


On Fri, Apr 18, 2014 at 5:31 PM, Kasun Gajasinghe  wrote:

> Hi AmilaM, SameeraM,
>
> The tenant-mgt components and features are already available in 4.3.0 [1].
> You can find the components we brought back in the thread "Removing
> Stratos features from Carbon 4.3.0 Products" in architecture list.
>
> [1]
> https://github.com/wso2/carbon-commons/tree/master/components/tenant-mgt/
>
> Regards,
> KasunG
>
>
>
> On Fri, Apr 18, 2014 at 3:25 PM, Amila Maha Arachchi wrote:
>
>> Lot of components bundled in stratos.common feature are not needed for
>> individual products now. They were needed for StratosLive setup. But I
>> cannot be sure about which bundles are needed and which are not.
>>
>> Following are the components bundled and features imported in this
>> feature. IMO, we only need tenant-mgt components. So, we can get rid of
>> stratos.common feature and try only adding tenant-mgt features to the
>> product.
>>
>> To do that, we need to add the tenant-mgt components to Git. Who can help
>> with it?
>>
>> 
>>
>>
>> org.wso2.carbon:org.wso2.carbon.stratos.common:${stratos.version}
>>
>>
>> org.wso2.carbon:org.wso2.carbon.redirector.servlet
>>
>>
>> org.wso2.carbon:org.wso2.carbon.activation:${stratos.version}
>>
>>
>> org.wso2.carbon:org.wso2.carbon.sample.installer:${stratos.version}
>>
>>
>> org.wso2.carbon:org.wso2.carbon.tenant.dispatcher
>>
>>
>>
>>
>> org.wso2.carbon:org.wso2.carbon.stratos.landing.page.deployer
>>
>>
>>
>>
>>
>> 
>>
>> org.json.wso2:json
>>
>>
>> org.wso2.carbon:org.wso2.carbon.tenant.mgt:${stratos.version}
>>
>>
>> kaptcha.wso2:kaptcha
>>
>>
>> org.wso2.carbon:org.wso2.carbon.keystore.mgt
>>
>>
>> org.wso2.carbon:org.wso2.carbon.tenant.mgt.core:${stratos.version}
>>
>>
>> org.wso2.carbon:org.wso2.carbon.captcha.mgt
>>
>>
>> org.wso2.carbon:org.wso2.carbon.theme.mgt:${stratos.version}
>>
>> 
>>
>>
>> 
>>
>> 
>>
>>
>> org.apache.rampart.wso2:rampart-policy
>>
>>
>> org.apache.rampart.wso2:rampart-core
>>
>>
>> org.apache.rampart.wso2:rampart-trust
>>
>>
>> org.wso2.carbon:org.wso2.carbon.application.upload
>>
>> 
>>
>> 
>>
>>
>> org.wso2.carbon.core.server:${wso2carbon.version}
>>
>>
>> org.wso2.carbon.identity.authenticator.saml2.sso.server:${carbon.version}
>>
>>
>> org.wso2.carbon.registry.core.server:${carbon.version}
>>
>> 
>>
>>
>>
>> On Fri, Apr 18, 2014 at 2:50 PM, Sameera Medagammaddegedara <
>> samee...@wso2.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> *Background*
>>>
>>>- The Enterprise Store (ES) and the Cassandra components require the
>>>stratos.common.server.feature :2.2.1
>>>- At the moment we are in the process of moving ES to Carbon 4.3.0
>>>for the next Governance Registry milestone.
>>>
>>> *Problem*
>>>
>>>- The stratos.common.server.feature 2.2.1 cannot be used as it has
>>>dependencies on 4.2.0 features:
>>>org.wso2.carbon.registry.core.server.feature.group
>>>- This feature is used for multitenancy support in the Cassandra
>>>component and is needed by several other products as well.
>>>- In an offline discussion AmilaM , proposed the option of dropping
>>>the feature and utilizing only the components required for 
>>> multitenancy.In
>>>which case the tenant-mgt component[1] will need to be moved to Git as 
>>> well.
>>>
>>> *Questions*
>>>
>>>- What is the best approach to replacing this feature?
>>>
>>>
>>> *References*
>>> [1]tenant-mgt repository ,URL
>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/stratos/tenant-mgt/
>>>
>>> Thank You,
>>> Sameera
>>>
>>> --
>>> Sameera Medagammaddegedara
>>> Software Engineer
>>>
>>> Contact:
>>> Email: samee...@wso2.com
>>> Mobile: + 94 077 255 3005
>>>
>>
>>
>>
>> --
>> *Amila Maharachchi*
>> Senior Technical Lead
>> WSO2, Inc.; http://wso2.com
>>
>> Blog: http://maharachchi.blogspot.com
>> Mobile: +94719371446
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



-- 
*Amila Maharachchi*
Senior Technical Lead
WSO2, Inc.; http://wso2.com

Blog: http://maharachchi.blogspot.com
Mobile: +94719371446
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Do we required to ship MB 220 with enabling Flow control by default?

[Prabath Abeysekera]

+1 for having it enabled by default.

In the current implementation, if andes client cannot deliver a message to
the server over a given period of time (this is configurable) once flow
control is activated, then it throws an exception and closes the connection
so there won't be any message accumulation beyond that point. This prevents
any unnecessary memory build-ups at the client side due to flow
controlling.

After an offline chat had with Srinath, it was decided that we can also
monitor the queues in which the data gets buffered at client-side and do
the same as done in the previous step, as well. In all aforementioned
instances, we should ship the feature with proper defaults.


Cheers,
Prabath


On Wed, May 7, 2014 at 7:48 PM, Srinath Perera  wrote:

> I think it should be on by default. If load is low, it will never kick in.
>
> If it has any adverse effect, that has to be fixed anyway.
>
> --Srinath
>
>
> On Tue, May 6, 2014 at 3:32 PM, Asanka Vithanage  wrote:
>
>> Hi All,
>>
>> With MB 220 we are going to introduce a new feature to flow control the
>> publisher. Currently by default MB pack comes with enabling that feature.
>>
>> But AFAIU flow control requires only on systems which expose to high
>> message loads.for such systems we could enable the Flow control feature as
>> required.
>>
>> So don't it a good idea to disable flow control on default pack and allow
>> users to select whether they required flow control?
>>
>> WDYT?
>>
>>
>>
>> --
>> Asanka Vithanage
>> Senior Software Engineer -QA
>> Mobile: +94 0716286708
>> Email: asan...@wso2.com
>> WSO2 Inc. www.wso2.com
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>   Director, Research, WSO2 Inc.
>   Visiting Faculty, University of Moratuwa
>   Member, Apache Software Foundation
>   Research Scientist, Lanka Software Foundation
>   Blog: http://srinathsview.blogspot.com/
>   Photos: http://www.flickr.com/photos/hemapani/
>Phone: 0772360902
>



-- 
Prabath Abeysekara
Associate Technical Lead, Data TG.
WSO2 Inc.
Email: praba...@wso2.com
Mobile: +94774171471
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 ESB Connector Store Icons

[Malaka Silva]

Hi Chanaka,

What is the resolution you have used for log and banner.

We may need to use the same for other connectors?

Best Regards,
Malaka


On Sun, May 4, 2014 at 11:26 AM, Chanaka Jayasena  wrote:

> Hi Dushan, the Google drive is updated with the latest.
>
> thanks,
> Chanaka
>
>
> On Fri, May 2, 2014 at 5:35 PM, Chanaka Jayasena  wrote:
>
>> Noted. I will update and provide you with the remaining connector icons
>> as well.
>>
>> Thanks,
>> Chanaka
>>
>>
>> On Fri, May 2, 2014 at 1:20 PM, Dushan Abeyruwan  wrote:
>>
>>> Hi ChanakaJ
>>>
>>> On Fri, May 2, 2014 at 9:00 AM, Malaka Silva  wrote:
>>>
 Hi All,

 IMO we should not modify the backgroung color and layout outside what
 vendors(Third parties) are using.

 Eg: - Salesforce logo is in green color whereas standard is blue.

>>>
>>>Yes, I feel the same as we should not modify exiting vendors layout
>>> colors, overall felt only salesforce has such issue.
>>>
>>> meantime, can we get the remaining connector images as well [1] shows
>>> you the connectors we have at the moment
>>>
>>> https://github.com/wso2-dev/esb-connectors
>>>
>>>   we should add, facebook,gmail.amazon s3,google drive,suvaymonkey,
>>> sugerCRM.
>>>

 Best Regards,
 Malaka


 On Fri, May 2, 2014 at 8:08 AM, Chanaka Jayasena wrote:

> Hi Dushan,
>
> [1] contains the images you requested for the Connector Store. Amazon
> s3 and Survey Monkey icons are missing. I will upload those ones they are
> done.
>
> 1 -
> https://drive.google.com/a/wso2.com/folderview?id=0B_CCkDYHWyB9VGlJc0MzWnRpYkU&usp=sharing#grid
>
> thanks,
> Chanaka
>
> --
> Chanaka Jayasena
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> email: chan...@wso2.com; cell: +94 77 785 5565
> blog: http://chanaka3d.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --

 Best Regards,

 Malaka Silva
 Senior Tech Lead
 M: +94 777 219 791
 Tel : 94 11 214 5345
 Fax :94 11 2145300
 Skype : malaka.sampath.silva
 LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
 Blog : http://mrmalakasilva.blogspot.com/

 WSO2, Inc.
 lean . enterprise . middleware
 http://www.wso2.com/
 http://www.wso2.com/about/team/malaka-silva/

 Save a tree -Conserve nature & Save the world for your future. Print
 this email only if it is absolutely necessary.

>>>
>>>
>>>
>>> --
>>> Dushan Abeyruwan | Associate Tech Lead
>>>  Integration Technologies Team
>>> PMC Member Apache Synpase
>>> WSO2 Inc. http://wso2.com/
>>> Blog:http://dushansview.blogspot.com/
>>> Mobile:(0094)713942042
>>>
>>>
>>
>>
>> --
>> Chanaka Jayasena
>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>> email: chan...@wso2.com; cell: +94 77 785 5565
>> blog: http://chanaka3d.blogspot.com
>>
>
>
>
> --
> Chanaka Jayasena
> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
> email: chan...@wso2.com; cell: +94 77 785 5565
> blog: http://chanaka3d.blogspot.com
>



-- 

Best Regards,

Malaka Silva
Senior Tech Lead
M: +94 777 219 791
Tel : 94 11 214 5345
Fax :94 11 2145300
Skype : malaka.sampath.silva
LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
Blog : http://mrmalakasilva.blogspot.com/

WSO2, Inc.
lean . enterprise . middleware
http://www.wso2.com/
http://www.wso2.com/about/team/malaka-silva/

Save a tree -Conserve nature & Save the world for your future. Print this
email only if it is absolutely necessary.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Content Length is removed for multipart requests

[Malaka Silva]

Hi

Adding the following sends the original content length.

 
 

I guess this is a hack?


On Wed, May 7, 2014 at 9:24 PM, Malaka Silva  wrote:

> Hi,
>
> When sending multipart it seems Content_length is remove from ESB.
>
> Following lines are doing it. Any idea why this is given this way?
>
> if (HTTP.CONN_DIRECTIVE.equalsIgnoreCase(headerName) ||
> HTTP.TRANSFER_ENCODING.equalsIgnoreCase(headerName) ||
> HTTP.DATE_HEADER.equalsIgnoreCase(headerName) ||
> HTTP.CONTENT_LEN.equalsIgnoreCase(headerName) ||
> HTTP.CONN_KEEP_ALIVE.equalsIgnoreCase(headerName)) {
> iter.remove();
> }
>
>
> http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/dependencies/synapse/2.1.2-wso2v4/modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/passthru/util/PassThroughTransportUtils.java
>
> --
>
> Best Regards,
>
> Malaka Silva
> Senior Tech Lead
> M: +94 777 219 791
> Tel : 94 11 214 5345
> Fax :94 11 2145300
> Skype : malaka.sampath.silva
> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
> Blog : http://mrmalakasilva.blogspot.com/
>
> WSO2, Inc.
> lean . enterprise . middleware
> http://www.wso2.com/
> http://www.wso2.com/about/team/malaka-silva/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it is absolutely necessary.
>



-- 

Best Regards,

Malaka Silva
Senior Tech Lead
M: +94 777 219 791
Tel : 94 11 214 5345
Fax :94 11 2145300
Skype : malaka.sampath.silva
LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
Blog : http://mrmalakasilva.blogspot.com/

WSO2, Inc.
lean . enterprise . middleware
http://www.wso2.com/
http://www.wso2.com/about/team/malaka-silva/

Save a tree -Conserve nature & Save the world for your future. Print this
email only if it is absolutely necessary.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Extensibility of JDBCAuthorizationManager.

[Dimuthu Leelarathne]

Hi Danushka,

+1. I don't see any harm in making it extensible.

thanks,
dimuthu


On Tue, May 6, 2014 at 2:12 PM, Danushka Fernando wrote:

> Any Ideas on this?
>
> Thanks & Regards
> Danushka Fernando
> Software Engineer
> WSO2 inc. http://wso2.com/
> Mobile : +94716332729
>
>
> On Fri, May 2, 2014 at 4:02 PM, Danushka Fernando wrote:
>
>> Hi all
>> In user management area we have made lot of stuff extensible. We can
>> write our own user store managers, tenant managers and authorization
>> managers. So most of the time when we write a custom one we extend form an
>> existing one.
>>
>> For example We implement
>> tenant managers extended from JDBCTenantManager
>> user store managers extended from ReadOnlyLDAPUserStoreManager /
>> ReadWriteLDAPUserStoreManager.
>>
>> Because what we want to customize might not be the whole class. It could
>> be a one operation of the class.
>>
>> Like that the implementation of Authorization Manager we can extend from
>> is JDBCAuthorizationManager. But current implementation
>> of JDBCAuthorizationManager is not extensible due to following reasons.
>>
>>
>>1. All the object level variables are private not protected.
>>2. Lot of methods of the class are private.
>>3. SearchResult class is visible only to the particular package.
>>
>>
>> If we make all necessary private things protected, then some one can
>> extend it and write his/her own Authorization Manager. Can we
>> update JDBCAuthorizationManager code to make it extensible.
>>
>> Thanks & Regards
>> Danushka Fernando
>> Software Engineer
>> WSO2 inc. http://wso2.com/
>> Mobile : +94716332729
>>
>
>


-- 
Dimuthu Leelarathne
Architect & Product Lead of App Factory

WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile : 0773661935

Lean . Enterprise . Middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] App Factory migration from Scratch area to Turing

[Shamika Ariyawansa]

Hi all,

App Factory Scratch area located at [1] is completely moved to Truing
and wso2appfactory-2.0.0 can be build-able using chunk-12.

We have tested and verified the basic flow of it.

[1] https://svn.wso2.org/repos/wso2/scratch/appfactorycc

Regards
-- 
Shamika Ariyawansa
Senior Software Engineer
WSO2, Inc.; http://wso2.com

LK -  +94 7639629 Ext 5999
US - +1 408 754 7388 Ext 51732
Mob:+ 94 772929486

*twitter: 
**https://twitter.com/Amila_Shamika*
*linked-in: *http://www.linkedin.com/pub/dir/Shamika/Ariyawansa

*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Streaming JSON Fix

[Shelan Perera]

Hi Anjana,

Thanks for clarification and i could get it working. The reason is URL [1]
used. You need to have /route_batch_req which is the operation for
Addressing i assume [2]. And also yes
it should be "_postinsert" not "insert.

320 Doc was silent about it but 321 has been updated with correct batch
request URLs.

[1] http://localhost:9763/services/RouteService/

[2] http://localhost:9763/services/RouteService/route_batch_req


Thanks



On Wed, May 7, 2014 at 4:15 PM, Anjana Fernando  wrote:

> Hi Shelan,
>
> I guess the 2'nd object name should be "_postinsert" not "insert",
> basically the service dispatch is not happening, double check the service
> URL also. And also, there's a JSONSample.dbs that goes with data services
> as a sample, check that with batch requests enabled, at [1], contains how
> the batch request should be created.
>
> [1] https://docs.wso2.org/display/DSS321/JSON+Mapping
>
> Cheers,
> Anjana.
>
>
> On Wed, May 7, 2014 at 3:28 PM, Shelan Perera  wrote:
>
>> Hi,
>>
>> I have checked with the pack [1] here available and the original issue is
>> not fixed yet. I can still reproduce it and getting the error,
>>
>> Sample Request
>>  
>> {
>>"_postinsert_batch_req":{
>>   "insert":[
>>  {
>> "name":"route1",
>> "length":"200"
>>  },
>>  {
>> "name":"route2",
>> "length":"300"
>>  },
>>  {
>> "name":"route3",
>> "length":"400"
>>  }
>>   ]
>>}
>> }
>>
>> Error
>> 
>>  {"Fault":{"faultcode":"axis2ns1:Client","faultstring":"The endpoint
>> reference (EPR) for the Operation not found is /services/RouteService and
>> the WSA Action = null. If this EPR was previously reachable, please contact
>> the server administrator.","detail":""}}
>>
>> I am attaching the DBS i used to reproduce if anyone needs it. We may
>> need to reopen the original issue [2] and resolve it properly as this patch
>> did not fix it.
>>
>>
>>
>> [1] http://ec2-54-198-211-48.compute-1.amazonaws.com/chunk10/
>>
>> [2] https://wso2.org/jira/browse/DS-891
>>
>>
>>
>> Thanks
>>
>>
>> On Mon, May 5, 2014 at 4:27 PM, Manoj Kumara  wrote:
>>
>>> Hi,
>>>
>>> Applied to patch0007 with r201892.
>>>
>>> Thanks,
>>> Manoj
>>>
>>>
>>> *Manoj Kumara*
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94713448188
>>>
>>>
>>> On Sat, May 3, 2014 at 11:09 PM, Shameera Rathnayaka 
>>> wrote:
>>>
 Hi Anjana,

 I will have a look and apply the patch.

 Thanks,
 Shameera.


 On Sat, May 3, 2014 at 4:11 PM, Anjana Fernando wrote:

> Hi Shameera,
>
> I've fixed a bug in the streaming JSON implementation, related to the
> issue [1]. I've given the explanation to the fix there in a comment, 
> please
> review it, and commit it to the necessary places, i.e. kernel patch07,
> GitHub, Axis2 etc.. We need this for the Monday DSS 3.2.1 release. Chanika
> please follow up.
>
> [1] https://wso2.org/jira/browse/DS-891
>
> Cheers,
> Anjana.
> --
> *Anjana Fernando*
> Senior Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



 --
 *Software Engineer - WSO2 Inc.*
 *email: shameera AT wso2.com  , shameera AT
 apache.org *
 *phone:  +9471 922 1454 <%2B9471%20922%201454>*

 *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
 *Twitter : *https://twitter.com/Shameera_R

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


>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Shelan Perera*
>>
>> Senior Software Engineer
>> Integration Technology Group
>> *WSO2, Inc. : wso2.com *
>> lean.enterprise.middleware.
>>
>> *Blog* :   blog.shelan.org
>> *Linked-i*n  :   http://www.linkedin.com/pub/shelan-perera/a/194/465
>> *Twitter* :https://twitter.com/#!/shelan
>>
>> *Mobile*  : +94 772 604 402
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Anjana Fernando*
> Senior Technical Lead
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



-- 
*Shelan Perera*

Senior Software Engineer
Integration Technology Group
*WSO2, Inc. : wso2.com *
lean.enterprise.middleware.

*Blog* :   blog.shelan.org
*Linked-i*n  :   http://www.linkedin.com/pub/shelan-perera/a/194/465
*Twitter* :https://twitter.com/#!/shelan

*Mobile*  : +94 772 604 402
___
Dev mailing list
Dev@ws

[Dev] Content Length is removed for multipart requests

[Malaka Silva]

Hi,

When sending multipart it seems Content_length is remove from ESB.

Following lines are doing it. Any idea why this is given this way?

if (HTTP.CONN_DIRECTIVE.equalsIgnoreCase(headerName) ||
HTTP.TRANSFER_ENCODING.equalsIgnoreCase(headerName) ||
HTTP.DATE_HEADER.equalsIgnoreCase(headerName) ||
HTTP.CONTENT_LEN.equalsIgnoreCase(headerName) ||
HTTP.CONN_KEEP_ALIVE.equalsIgnoreCase(headerName)) {
iter.remove();
}

http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/dependencies/synapse/2.1.2-wso2v4/modules/transports/core/nhttp/src/main/java/org/apache/synapse/transport/passthru/util/PassThroughTransportUtils.java

-- 

Best Regards,

Malaka Silva
Senior Tech Lead
M: +94 777 219 791
Tel : 94 11 214 5345
Fax :94 11 2145300
Skype : malaka.sampath.silva
LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77
Blog : http://mrmalakasilva.blogspot.com/

WSO2, Inc.
lean . enterprise . middleware
http://www.wso2.com/
http://www.wso2.com/about/team/malaka-silva/

Save a tree -Conserve nature & Save the world for your future. Print this
email only if it is absolutely necessary.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 Identity Server 5.0.0 Beta Released!

[Sanjeewa Malalgoda]

On Wed, May 7, 2014 at 9:13 PM, Evanthika Amarasiri wrote:

> It would be great if we can have a p2 repo soon since we have not tested
> IS as a key manager feature since 2nd of April.
>
+1. We will do.

Thanks,
sanjeewa.

>
> ​- ​
> Evanthika
>
>
> On Tue, May 6, 2014 at 12:50 PM, Darshana Gunawardana 
> wrote:
>
>> Hi Asanthi,
>>
>> On Tue, May 6, 2014 at 10:19 AM, Asanthi Kulasinghe wrote:
>>
>>> Hi,
>>>
>>> Is there a P2 repo for this?
>>>
>>
>> Not atm, We'll let you know once its hosted.
>>
>> Thanks,
>>
>>>
>>> Regards
>>> Asanthi
>>>
>>>
>>> On Tue, May 6, 2014 at 5:53 AM, Darshana Gunawardana 
>>> wrote:
>>>
 WSO2 Identity Server 5.0.0 Beta Released!



  Date: 6th May 2014


  WSO2 Identity Server team is pleased to announce the release of 5.0.0
 Beta version of WSO2 Identity Server.


 It can be downloaded from 
 *https://svn.wso2.org/repos/wso2/scratch/IS-5.0.0/beta/
 * which is
 built upon r201958.



 How to Run

1.

Extract the downloaded zip
2.

Go to the bin directory in the extracted folder
3.

Run the wso2server.sh or wso2server.bat as appropriate
4.

To access management console, point your browser to the URL
https://localhost:9443/carbon
5.

To access user-portal, point your browser to the URL
https://localhost:9443/dashboard/
6.

Use "admin", "admin" as the username and password to login as an
admin



  The following is a list of new features, improvements and bug fixes
 available with this release.


  New Features


  1. Identity Token transformation and mediation.


  WSO2 Identity Server 5.0.0 is capable of transforming and mediating
 any identity token - between SAML 2.0, OAuth 1.0/2.0, OpenID, OpenID
 Connect, IWA (Integrated Windows Authentication), OTP based on XMPP &
 Email and WS-Federation(Passive). This leads to seamless integration
 between internal applications and cloud applications such as Salesforce,
 Google Apps and Office 365.


  Few example use cases.


   - Login to your corporate Salesforce or Google Apps accounts from
 your Facebook credentials.

  - Login to your laptop connected to your corporate Windows domain -
 you will be automatically logged into your corporate Salesforce and Google
 Apps accounts.

  - Login to corporate Office 365 account - you will be automatically
 logged into you Google Apps and Salesforce accounts.

  - Login to Identity Server user portal - you will be automatically
 logged into your internal Liferay portals.


  2. Multi-option and multi-step authentication.


  With WSO2 Identity Server 5.0.0, a given service provider
 (irrespective of the protocol it supports) can select the login options it
 wants to present to it users. It can be multi-option as well and
 multi-step. With multi-option - the user will be presented with a login
 screen to pick whatever the authentication mechanism it wants (e.g.:
 Username/password, Facebook, SAML, OpenID Connect). With multi-step - you
 can enforce multi-factor authentication by picking right authenticators at
 the right step.


  3. Request Path Authenticators.


  Enables federated login with credentials attached to the request
 itself.


  4. Ability plugin in custom developed authenticators.


  The WSO2 Identity Server 5.0.0 runtime is capable of working with
 custom developed authenticators.


  5. Provisioning Bridge and Just-in-time Provisioning.


  WSO2 Identity Server 5.0.0 is capable of transforming inbound
 provisioning requests based on SOAP and SCIM to SCIM, SPML 2.0,
 Salesforce, Google Apps, LDAP, Active Directory, JDBC -  provisioning

 APIs.


  Just-in-time provisioning is integrated with Identity Federation.
 Login from a Federated Identity provider - WSO2 Identity Server is capable
 of provisioning the corresponding subject to its internal user

 store and any other provisioning system.


  6. Rule based provisioning.


  This is an integrated use case with WSO2 ESB. From WSO2 Identity
 Server, it can provision users to the WSO2 ESB. Using the ESB configuration
 language (Synapse) you can define rules for outbound provisioning based on
 the message content on any other parameter.


  7. Ability plugin in custom developed provisioning connectors.


  The WSO2 Identity Server 5.0.0 runtime is capable of working with
 custom developed provisioning connectors.


  8. User Dashboard


  A Jaggery base

Re: [Dev] WSO2 Identity Server 5.0.0 Beta Released!

[Evanthika Amarasiri]

It would be great if we can have a p2 repo soon since we have not tested IS
as a key manager feature since 2nd of April.

​- ​
Evanthika


On Tue, May 6, 2014 at 12:50 PM, Darshana Gunawardana wrote:

> Hi Asanthi,
>
> On Tue, May 6, 2014 at 10:19 AM, Asanthi Kulasinghe wrote:
>
>> Hi,
>>
>> Is there a P2 repo for this?
>>
>
> Not atm, We'll let you know once its hosted.
>
> Thanks,
>
>>
>> Regards
>> Asanthi
>>
>>
>> On Tue, May 6, 2014 at 5:53 AM, Darshana Gunawardana 
>> wrote:
>>
>>> WSO2 Identity Server 5.0.0 Beta Released!
>>>
>>>
>>>
>>>  Date: 6th May 2014
>>>
>>>
>>>  WSO2 Identity Server team is pleased to announce the release of 5.0.0
>>> Beta version of WSO2 Identity Server.
>>>
>>>
>>> It can be downloaded from 
>>> *https://svn.wso2.org/repos/wso2/scratch/IS-5.0.0/beta/
>>> * which is
>>> built upon r201958.
>>>
>>>
>>>
>>> How to Run
>>>
>>>1.
>>>
>>>Extract the downloaded zip
>>>2.
>>>
>>>Go to the bin directory in the extracted folder
>>>3.
>>>
>>>Run the wso2server.sh or wso2server.bat as appropriate
>>>4.
>>>
>>>To access management console, point your browser to the URL
>>>https://localhost:9443/carbon
>>>5.
>>>
>>>To access user-portal, point your browser to the URL
>>>https://localhost:9443/dashboard/
>>>6.
>>>
>>>Use "admin", "admin" as the username and password to login as an
>>>admin
>>>
>>>
>>>
>>>  The following is a list of new features, improvements and bug fixes
>>> available with this release.
>>>
>>>
>>>  New Features
>>>
>>>
>>>  1. Identity Token transformation and mediation.
>>>
>>>
>>>  WSO2 Identity Server 5.0.0 is capable of transforming and mediating
>>> any identity token - between SAML 2.0, OAuth 1.0/2.0, OpenID, OpenID
>>> Connect, IWA (Integrated Windows Authentication), OTP based on XMPP &
>>> Email and WS-Federation(Passive). This leads to seamless integration
>>> between internal applications and cloud applications such as Salesforce,
>>> Google Apps and Office 365.
>>>
>>>
>>>  Few example use cases.
>>>
>>>
>>>   - Login to your corporate Salesforce or Google Apps accounts from
>>> your Facebook credentials.
>>>
>>>  - Login to your laptop connected to your corporate Windows domain - you
>>> will be automatically logged into your corporate Salesforce and Google Apps
>>> accounts.
>>>
>>>  - Login to corporate Office 365 account - you will be automatically
>>> logged into you Google Apps and Salesforce accounts.
>>>
>>>  - Login to Identity Server user portal - you will be automatically
>>> logged into your internal Liferay portals.
>>>
>>>
>>>  2. Multi-option and multi-step authentication.
>>>
>>>
>>>  With WSO2 Identity Server 5.0.0, a given service provider
>>> (irrespective of the protocol it supports) can select the login options it
>>> wants to present to it users. It can be multi-option as well and
>>> multi-step. With multi-option - the user will be presented with a login
>>> screen to pick whatever the authentication mechanism it wants (e.g.:
>>> Username/password, Facebook, SAML, OpenID Connect). With multi-step - you
>>> can enforce multi-factor authentication by picking right authenticators at
>>> the right step.
>>>
>>>
>>>  3. Request Path Authenticators.
>>>
>>>
>>>  Enables federated login with credentials attached to the request
>>> itself.
>>>
>>>
>>>  4. Ability plugin in custom developed authenticators.
>>>
>>>
>>>  The WSO2 Identity Server 5.0.0 runtime is capable of working with
>>> custom developed authenticators.
>>>
>>>
>>>  5. Provisioning Bridge and Just-in-time Provisioning.
>>>
>>>
>>>  WSO2 Identity Server 5.0.0 is capable of transforming inbound
>>> provisioning requests based on SOAP and SCIM to SCIM, SPML 2.0,
>>> Salesforce, Google Apps, LDAP, Active Directory, JDBC -  provisioning
>>>
>>> APIs.
>>>
>>>
>>>  Just-in-time provisioning is integrated with Identity Federation.
>>> Login from a Federated Identity provider - WSO2 Identity Server is capable
>>> of provisioning the corresponding subject to its internal user
>>>
>>> store and any other provisioning system.
>>>
>>>
>>>  6. Rule based provisioning.
>>>
>>>
>>>  This is an integrated use case with WSO2 ESB. From WSO2 Identity
>>> Server, it can provision users to the WSO2 ESB. Using the ESB configuration
>>> language (Synapse) you can define rules for outbound provisioning based on
>>> the message content on any other parameter.
>>>
>>>
>>>  7. Ability plugin in custom developed provisioning connectors.
>>>
>>>
>>>  The WSO2 Identity Server 5.0.0 runtime is capable of working with
>>> custom developed provisioning connectors.
>>>
>>>
>>>  8. User Dashboard
>>>
>>>
>>>  A Jaggery based Dashboard for end users.
>>>
>>>
>>>  9. Remote User Store Management
>>>
>>>
>>>  Manage heterogeneous user stores distributed across different data
>>> centers from a single Identity Server node.
>>>
>>>
>>>  10. Custom permissions.
>>>
>>>
>>>  Each external application can

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Sanjeewa Malalgoda]

In this[2] pack we fixed multitenant issue and some of other issues
reported. But still we have to fix multi tenant SSO issue, registry ui
issue and some other issues. APIM team is working on them.
[2]http://builder1.us1.wso2.org/~apim/06-05-2014/evening/

Thanks,
sanjeewa.


On Wed, May 7, 2014 at 6:21 PM, Asanthi Kulasinghe  wrote:

> Hi,
>
> The following blocker is there as well.
>
> https://wso2.org/jira/browse/APIMANAGER-2317
>
> Regards
> Asanthi
>
> On Wed, May 7, 2014 at 5:21 PM, Sanjeewa Malalgoda wrote:
>
>>
>>
>>
>> On Wed, May 7, 2014 at 5:17 PM, Evanthika Amarasiri 
>> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> This has some blockers and some of the commits are not there. Therefore,
>>> it would be good if we can get a new pack tomorrow.
>>>
>>> https://wso2.org/jira/browse/APIMANAGER-2314
>>> https://wso2.org/jira/browse/APIMANAGER-2313
>>>
>> Yes we found that there is missed commit related to default API feature
>> and we will build another set of pack tonight.
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>>
>>> ​- ​
>>> Evanthika
>>>
>>>
>>> On Wed, May 7, 2014 at 2:36 PM, Manoj Kumara  wrote:
>>>
  Hi,

 Reverted from patch0007 with r202140.

 Thanks,
 Manoj


 *Manoj Kumara*
 Software Engineer
 WSO2 Inc. http://wso2.com/
 *lean.enterprise.middleware*
 Mobile: +94713448188


 On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando wrote:

> Hi,
>
> Yeah, +1, lets anyway fix it in patch0007.
>
> Cheers,
> Anjana.
>
>
> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>
>> Hi Anjana,
>>
>>
>> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando wrote:
>>
>>> Hi Manoj,
>>>
>>> So this is a bug that can affect DSS too? .. if so, we have to patch
>>> in 0007 itself.
>>>
>> This is only affecting for non blocking transports (ptt/nio). So DSS
>> will not get affected by this.
>> However IMO we need to revert this in Patch0007 as it is not good to
>> release a kernel patch with a serious bug.
>>
>>
>>>
>>> Cheers,
>>> Anjana.
>>>
>>>
>>>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara wrote:
>>>
 Hi Nuwan,

 currently patch0007 is breezed due to due to DSS release. I'll
 revert this after talking to DSS team.

 Thanks,
 Manoj


 *Manoj Kumara*
 Software Engineer
 WSO2 Inc. http://wso2.com/
 *lean.enterprise.middleware*
 Mobile: +94713448188


 On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias wrote:

> Hi Charitha,
>
> We figured out that this had been a regression due to a kernel
> patch - patch0007. Commit revision is r200946. Thanks IsuruU for
> the assistance.
>
> @Manoj, please revert this patch urgently since it causes a 202
> Accepted to be sent for all tenant requests and drops the response 
> body.
>
> Thanks,
> NuwanD.
>
>
> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge <
> chari...@wso2.com> wrote:
>
>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>> Verified the jiras.
>>  However, there is a critical MT failure which can be reproduced
>> in a fresh pack as well.
>>
>> When you invoke an API in a tenant, the response is not returned.
>> Given below is the wire log. As you can see, the response is not 
>> sent back.
>> Client always gets http 202 acknowledgement instead of the actual 
>> response.
>> Basically MT is broken.
>>
>> Note that the same API works with the same backend in super
>> tenant mode. So this must be a MT regression.
>>
>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection:
>> close[\r][\n]"
>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>> 4636d529ea62b726e312a53794dccf36[\r
>> ][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
>> 307[\r][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
>> [\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>> [2014-05-07 03:25:31,898] DEBUG - 

Re: [Dev] Do we required to ship MB 220 with enabling Flow control by default?

[Srinath Perera]

I think it should be on by default. If load is low, it will never kick in.

If it has any adverse effect, that has to be fixed anyway.

--Srinath


On Tue, May 6, 2014 at 3:32 PM, Asanka Vithanage  wrote:

> Hi All,
>
> With MB 220 we are going to introduce a new feature to flow control the
> publisher. Currently by default MB pack comes with enabling that feature.
>
> But AFAIU flow control requires only on systems which expose to high
> message loads.for such systems we could enable the Flow control feature as
> required.
>
> So don't it a good idea to disable flow control on default pack and allow
> users to select whether they required flow control?
>
> WDYT?
>
>
>
> --
> Asanka Vithanage
> Senior Software Engineer -QA
> Mobile: +94 0716286708
> Email: asan...@wso2.com
> WSO2 Inc. www.wso2.com
>
>


-- 

Srinath Perera, Ph.D.
  Director, Research, WSO2 Inc.
  Visiting Faculty, University of Moratuwa
  Member, Apache Software Foundation
  Research Scientist, Lanka Software Foundation
  Blog: http://srinathsview.blogspot.com/
  Photos: http://www.flickr.com/photos/hemapani/
   Phone: 0772360902
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Migration scripts for API-M 1.6.0 to 1.7.0

[Evanthika Amarasiri]

Hi All,

When can we have these migration scripts? I'm afraid we cannot release
until we do migration testing :( .

Regards,
Evanthika

On Tue, May 6, 2014 at 10:33 AM, Nirodha Pramod  wrote:

> Hi,
>
> Can we have this as soon as possible. Created a jira for this.
>
> [1] https://wso2.org/jira/browse/APIMANAGER-2292
>
> regards,
> Nirodha
>
>
> On Thu, Apr 17, 2014 at 7:54 PM, Nuwan Dias  wrote:
>
>> Hi Nirodha,
>>
>> This is still not done. We have a list maintained to identify what needs
>> to be migrated, quite a long list actually :). But work has not been
>> initiated on the migration script. Will let you know once done.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Thu, Apr 17, 2014 at 11:41 AM, Nirodha Pramod wrote:
>>
>>> Ping!! On the $subject.
>>>
>>>
>>> On Thu, Apr 10, 2014 at 11:37 AM, Nirodha Pramod wrote:
>>>
 Hi,

 Do we have the $subject ready?

 regards,
 Nirodha

 --

 *Nirodha Gallage*
 Senior Software Engineer, QA.
 WSO2 Inc.: http://wso2.com/
 Mobile: +94716429078

>>>
>>>
>>>
>>> --
>>>
>>> *Nirodha Gallage*
>>> Senior Software Engineer, QA.
>>> WSO2 Inc.: http://wso2.com/
>>> Mobile: +94716429078
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
>
> *Nirodha Gallage*
> Senior Software Engineer, QA.
> WSO2 Inc.: http://wso2.com/
> Mobile: +94716429078
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
> ​​
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Issue in invoking APIs with POST request (with different content types)

[Sanjeewa Malalgoda]

Hi,
We observed following behavior in API Manager 1.7.0 which built on top
of synapse 2.1.2.wso2v5. We sent same request to API created by fronting
basic jaxrs service. Only difference is setting 2 content types. Backend
service support both content types and we can invoke it without any issue.

01. Content-Type: text/xml
[2014-05-07 18:36:31,114] DEBUG - headers http-outgoing-6 >> POST
http://10.100.1.65:9764/jaxrs_basic/services/customers HTTP/1.1

02. Content-Type: application/xml
[2014-05-07 18:36:11,805] DEBUG - headers http-outgoing-6 >> POST
http://10.100.1.65:9764/jaxrs_basic/services/customers/
*customerservice/customers* HTTP/1.1

When content type is text/xml we can see part of the request is dropping.
It send request directly to the endpoint defined in API without appending
other things in client request url. Any idea what went wrong?

Here is my API
 







http://10.100.1.65:9764/jaxrs_basic/services/customers";>

3

fault


-1
0

1.0
0


-1




























Thanks,
sanjeewa.
--

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

 blog
:http://sanjeewamalalgoda.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] CAR deployment broken due to following changes

[Dushan Abeyruwan]

HI KasunG,

  Previous workable deployment,

SynapseAppDeployer.java
---

 /**
 * Finds the correct deployer for the given artifact type
 *
 * @param axisConfig - AxisConfiguration instance
 * @return Deployer instance
 */
private Deployer getDeployer(AxisConfiguration axisConfig, String
directory) {
Deployer deployer = null;
// access the deployment engine through axis config
DeploymentEngine deploymentEngine = (DeploymentEngine)
axisConfig.getConfigurator();
String tenantId = AppDeployerUtils.getTenantIdString(axisConfig);
SynapseEnvironmentService environmentService =
DataHolder.getInstance().
getSynapseEnvironmentService(Integer.parseInt(tenantId));
if (environmentService != null) {
String synapseConfigPath =
ServiceBusUtils.getSynapseConfigAbsPath(

environmentService.getSynapseEnvironment().getServerContextInformation());
String endpointDirPath = synapseConfigPath
 + File.separator + directory;
deployer = deploymentEngine.getDeployer(endpointDirPath,

ServiceBusConstants.ARTIFACT_EXTENSION);
}
return deployer;
}




change You have done.. GIT ref* {79e529f18c4db6b45d7d0c8fd5f2288a70aee680}*

   /**
 * Finds the correct deployer for the given artifact type
 *
 * @param axisConfig - AxisConfiguration instance
 * @return Deployer instance
 */
private Deployer getDeployer(AxisConfiguration axisConfig, String
directory) {

// access the deployment engine through axis config
DeploymentEngine deploymentEngine = (DeploymentEngine)
axisConfig.getConfigurator();
String endpointDirPath = getArtifactDirPath(axisConfig, directory);
return deploymentEngine.getDeployer(endpointDirPath,

SynapseAppDeployerConstants.ARTIFACT_EXTENSION);
}

questions ?

Any reason why this done ? for the same reason ESB CAP deployment broken ..

cheers,
Dushan Abeyruwan | Associate Tech Lead
Integration Technologies Team
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:http://dushansview.blogspot.com/
Mobile:(0094)713942042
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] ERROR {org.wso2.carbon.server.extensions.DropinsBundleDeployer} - Error displayed in Management Node ESB Worker Manager setup.

[Chathurika Mahaarachchi]

Reported Jira [1]

[1] https://wso2.org/jira/browse/CARBON-14794


On Wed, May 7, 2014 at 5:39 PM, Chathurika Mahaarachchi  wrote:

> Tried this.. but same issue observed in Management Node.
>
>
> On Wed, May 7, 2014 at 5:35 PM, Manoj Kumara  wrote:
>
>> Can you try cleaning the dropins directory and restart.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>>
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Wed, May 7, 2014 at 5:33 PM, Chathurika Mahaarachchi <
>> chathur...@wso2.com> wrote:
>>
>>> Hi ,
>>>
>>>
>>> The following error message is displayed in Management node of ESB -
>>> Worker management set up suddenly.  The cluster  was working fine earlier.
>>> But now I try to start it following error is displayed in Management node
>>>
>>> [2014-05-07 17:15:58,367] ERROR
>>> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
>>> found in the dropins directory: org.wso2.carbon.logging.propfile_1.0.0.jar
>>> [2014-05-07 17:15:58,369] ERROR
>>> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
>>> found in the dropins directory: mysql_connector_java_5.1.21_bin_1.0.0.jar
>>> log4j:WARN No appenders could be found for logger
>>> (com.atomikos.logging.LoggerFactory).
>>> log4j:WARN Please initialize the log4j system properly.
>>>
>>> I have deleted the "mysql_connector_java_5.1.21_bin_1.0.0.jar" and  &
>>> "org.wso2.carbon.logging.propfile_1.0.0.jar"  file form the droppings
>>> folder and tried to restart the management node . but its still gives the
>>> above error.
>>>
>>> Anyone knows the reason for this ?
>>>
>>> Thanks & Regards,
>>>
>>> --
>>> *Chathurika Mahaarachchi*
>>> Software Engineer, QA.
>>> WSO2 Inc.: http://wso2.com/
>>> lean.enterprise.middleware
>>> Mobile: +94718223950
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>
>
> --
> *Chathurika Mahaarachchi*
> Software Engineer, QA.
> WSO2 Inc.: http://wso2.com/
> lean.enterprise.middleware
> Mobile: +94718223950
>



-- 
*Chathurika Mahaarachchi*
Software Engineer, QA.
WSO2 Inc.: http://wso2.com/
lean.enterprise.middleware
Mobile: +94718223950
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Asanthi Kulasinghe]

Hi,

The following blocker is there as well.

https://wso2.org/jira/browse/APIMANAGER-2317

Regards
Asanthi

On Wed, May 7, 2014 at 5:21 PM, Sanjeewa Malalgoda wrote:

>
>
>
> On Wed, May 7, 2014 at 5:17 PM, Evanthika Amarasiri wrote:
>
>> Hi Sanjeewa,
>>
>> This has some blockers and some of the commits are not there. Therefore,
>> it would be good if we can get a new pack tomorrow.
>>
>> https://wso2.org/jira/browse/APIMANAGER-2314
>> https://wso2.org/jira/browse/APIMANAGER-2313
>>
> Yes we found that there is missed commit related to default API feature
> and we will build another set of pack tonight.
>
> Thanks,
> sanjeewa.
>
>>
>>
>> ​- ​
>> Evanthika
>>
>>
>> On Wed, May 7, 2014 at 2:36 PM, Manoj Kumara  wrote:
>>
>>>  Hi,
>>>
>>> Reverted from patch0007 with r202140.
>>>
>>> Thanks,
>>> Manoj
>>>
>>>
>>> *Manoj Kumara*
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94713448188
>>>
>>>
>>> On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:
>>>
 Hi,

 Yeah, +1, lets anyway fix it in patch0007.

 Cheers,
 Anjana.


 On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:

> Hi Anjana,
>
>
> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando wrote:
>
>> Hi Manoj,
>>
>> So this is a bug that can affect DSS too? .. if so, we have to patch
>> in 0007 itself.
>>
> This is only affecting for non blocking transports (ptt/nio). So DSS
> will not get affected by this.
> However IMO we need to revert this in Patch0007 as it is not good to
> release a kernel patch with a serious bug.
>
>
>>
>> Cheers,
>> Anjana.
>>
>>
>>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara wrote:
>>
>>> Hi Nuwan,
>>>
>>> currently patch0007 is breezed due to due to DSS release. I'll
>>> revert this after talking to DSS team.
>>>
>>> Thanks,
>>> Manoj
>>>
>>>
>>> *Manoj Kumara*
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94713448188
>>>
>>>
>>> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>>>
 Hi Charitha,

 We figured out that this had been a regression due to a kernel
 patch - patch0007. Commit revision is r200946. Thanks IsuruU for
 the assistance.

 @Manoj, please revert this patch urgently since it causes a 202
 Accepted to be sent for all tenant requests and drops the response 
 body.

 Thanks,
 NuwanD.


 On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge <
 chari...@wso2.com> wrote:

> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
> Verified the jiras.
>  However, there is a critical MT failure which can be reproduced
> in a fresh pack as well.
>
> When you invoke an API in a tenant, the response is not returned.
> Given below is the wire log. As you can see, the response is not sent 
> back.
> Client always gets http 202 acknowledgement instead of the actual 
> response.
> Basically MT is broken.
>
> Note that the same API works with the same backend in super tenant
> mode. So this must be a MT regression.
>
> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection:
> close[\r][\n]"
> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
> gzip,deflate[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
> text/xml;charset=UTF-8[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
> "urn:echoString"[\r][\n]"
> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
> 4636d529ea62b726e312a53794dccf36[\r
> ][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
> 307[\r][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
> [\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
> [2014-05-07 03:25:31,898] DEBUG - wire >> " xmlns:soapenv="http://schemas.xmlsoap.o
> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
> ">[\r][\n]"
>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>  [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>

[Dev] Has anyone tried a mutual auth scenario when a server is fronted by WSO2 ELB

[Amila Maha Arachchi]

Hi all,

$Subject?

We recently figured out that this is not working with AWS ELB. Just wanted
to know whether $Subject before trying.

Regards,
AmilaM.

-- 
*Amila Maharachchi*
Senior Technical Lead
WSO2, Inc.; http://wso2.com

Blog: http://maharachchi.blogspot.com
Mobile: +94719371446
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Global cluster cache invalidation code review Notes

[Subash Chaturanga]

Great! Please work with Amal and follow up with Shammi. It will be much
effective.


On Wed, May 7, 2014 at 5:56 PM, Shazni Nazeer  wrote:

> Hi Subash,
>
> Yes I'm also looking into this.
>
> Shazni Nazeer
>
> Senior Software Engineer
>
> Mob : +94 715 440 607
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
> Blog : http://shazninazeer.blogspot.com
>
>
> On Wed, May 7, 2014 at 5:45 PM, Subash Chaturanga  wrote:
>
>> Hi Amal,
>> Can't your implementation adhere to the old JMS client version instead ?
>>
>> Hi Shazni,
>> Since we are blocked on this for some time and Amal is in support and
>> having context switching on this and support issues. So can you please sit
>> with him and do the needful to get this issue sorted out. Please talk to a
>> carbon member to get their help if necessary proceed with the best approach.
>>
>>
>>
>>
>>
>> On Wed, May 7, 2014 at 2:43 PM, Amal Gunatilake  wrote:
>>
>>> Hi Shammi,
>>>
>>> Thanks for the idea. I tried this out with activemq-client jar and
>>> several other jars. Still the casting problem exists. Further inspection
>>> showed me that there is another older version of jms osgi bundle
>>> (geronimo-spec-jms_1.1.0.rc4-wso2v1) in the carbon server. I think that
>>> this bundle causes the issue since this is an older version of jms and when
>>> we include the ActiveMQ jar to the lib the org.apache.activemq.
>>> ActiveMQConnectionFactory will not be able to cast into older version of
>>> javax.jms.TopicConnectionFactory.
>>>
>>> So either we have to update the versions of existing jms bundles or we
>>> might have to find an older version of ActiveMQ jar which comply with
>>> geronimo-spec-jms_1.1.0.rc4 version.
>>> Appreciate your thoughts on the matter.
>>>
>>> Thank you,
>>>
>>> Thank you  & Best regards,
>>>
>>> *Amal Gunatilake*
>>>  Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>>
>>> On Tue, May 6, 2014 at 4:33 PM, Shammi Jayasinghe wrote:
>>>
 Hi Amal,

 I think the adding of  activemq-all bundle may adding another version
 of the library which contains javax.jms and it may cause this problem.
 Could you please try to not to add activemq-all but only the required
 bundles or remove the other library which contains javax.jms package and
 try this out.

 Thanks
 Shammi


 On Tue, May 6, 2014 at 3:57 PM, Amal Gunatilake  wrote:

> Hi Shammi/Hasitha,
>
> There is a version conflict with existing javax.jms bundles when
> starting the cache invalidation osgi bundle, which causes the casting
> problem. Any thoughts on this matter?
>
> Thank you  & Best regards,
>
> *Amal Gunatilake*
>  Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
>
> On Tue, May 6, 2014 at 1:22 PM, Shazni Nazeer  wrote:
>
>> Hi Amal,
>>
>> Yes now the cache.xml entries are correctly read. After replacing
>> activemq-core to activemq-all the debugging steps go below the
>> IniatlContext line, but as you have mentioned when session object is 
>> being
>> created the following exception is thrown. Therefore, still jms
>> initialization fails.
>>
>> [2014-05-06 13:13:58,409] ERROR
>> {org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl} 
>> -
>> Global cache invalidation: Error jms broker initialization
>> java.lang.ClassCastException:
>> org.apache.activemq.ActiveMQConnectionFactory cannot be cast to
>> javax.jms.TopicConnectionFactory
>> at
>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.initJMSBroker(JMSGlobalCacheInvalidationImpl.java:112)
>> at
>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.init(JMSGlobalCacheInvalidationImpl.java:96)
>> at
>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.invalidateCache(JMSGlobalCacheInvalidationImpl.java:131)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.removeFromCache(CachingHandler.java:255)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:211)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:207)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:91)
>> at
>> org.wso2.carbon.registry.core.caching.CachingHandler.put(CachingHandler.java:280)
>> at
>> org.wso2.carbon.registry.core.jdbc.handlers.HandlerManager.put(HandlerManager.java:2503)
>> at
>> org.wso2.carbon.registry.core.jdbc.handlers.HandlerLifecycleManager.put(HandlerLif

Re: [Dev] Global cluster cache invalidation code review Notes

[Shazni Nazeer]

Hi Subash,

Yes I'm also looking into this.

Shazni Nazeer

Senior Software Engineer

Mob : +94 715 440 607
LinkedIn : http://lk.linkedin.com/in/shazninazeer
Blog : http://shazninazeer.blogspot.com


On Wed, May 7, 2014 at 5:45 PM, Subash Chaturanga  wrote:

> Hi Amal,
> Can't your implementation adhere to the old JMS client version instead ?
>
> Hi Shazni,
> Since we are blocked on this for some time and Amal is in support and
> having context switching on this and support issues. So can you please sit
> with him and do the needful to get this issue sorted out. Please talk to a
> carbon member to get their help if necessary proceed with the best approach.
>
>
>
>
>
> On Wed, May 7, 2014 at 2:43 PM, Amal Gunatilake  wrote:
>
>> Hi Shammi,
>>
>> Thanks for the idea. I tried this out with activemq-client jar and
>> several other jars. Still the casting problem exists. Further inspection
>> showed me that there is another older version of jms osgi bundle
>> (geronimo-spec-jms_1.1.0.rc4-wso2v1) in the carbon server. I think that
>> this bundle causes the issue since this is an older version of jms and when
>> we include the ActiveMQ jar to the lib the org.apache.activemq.
>> ActiveMQConnectionFactory will not be able to cast into older version of
>> javax.jms.TopicConnectionFactory.
>>
>> So either we have to update the versions of existing jms bundles or we
>> might have to find an older version of ActiveMQ jar which comply with
>> geronimo-spec-jms_1.1.0.rc4 version.
>> Appreciate your thoughts on the matter.
>>
>> Thank you,
>>
>> Thank you  & Best regards,
>>
>> *Amal Gunatilake*
>>  Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>>
>> On Tue, May 6, 2014 at 4:33 PM, Shammi Jayasinghe wrote:
>>
>>> Hi Amal,
>>>
>>> I think the adding of  activemq-all bundle may adding another version
>>> of the library which contains javax.jms and it may cause this problem.
>>> Could you please try to not to add activemq-all but only the required
>>> bundles or remove the other library which contains javax.jms package and
>>> try this out.
>>>
>>> Thanks
>>> Shammi
>>>
>>>
>>> On Tue, May 6, 2014 at 3:57 PM, Amal Gunatilake  wrote:
>>>
 Hi Shammi/Hasitha,

 There is a version conflict with existing javax.jms bundles when
 starting the cache invalidation osgi bundle, which causes the casting
 problem. Any thoughts on this matter?

 Thank you  & Best regards,

 *Amal Gunatilake*
  Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware


 On Tue, May 6, 2014 at 1:22 PM, Shazni Nazeer  wrote:

> Hi Amal,
>
> Yes now the cache.xml entries are correctly read. After replacing
> activemq-core to activemq-all the debugging steps go below the
> IniatlContext line, but as you have mentioned when session object is being
> created the following exception is thrown. Therefore, still jms
> initialization fails.
>
> [2014-05-06 13:13:58,409] ERROR
> {org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl} -
> Global cache invalidation: Error jms broker initialization
> java.lang.ClassCastException:
> org.apache.activemq.ActiveMQConnectionFactory cannot be cast to
> javax.jms.TopicConnectionFactory
> at
> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.initJMSBroker(JMSGlobalCacheInvalidationImpl.java:112)
> at
> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.init(JMSGlobalCacheInvalidationImpl.java:96)
> at
> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.invalidateCache(JMSGlobalCacheInvalidationImpl.java:131)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.removeFromCache(CachingHandler.java:255)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:211)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:207)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:91)
> at
> org.wso2.carbon.registry.core.caching.CachingHandler.put(CachingHandler.java:280)
> at
> org.wso2.carbon.registry.core.jdbc.handlers.HandlerManager.put(HandlerManager.java:2503)
> at
> org.wso2.carbon.registry.core.jdbc.handlers.HandlerLifecycleManager.put(HandlerLifecycleManager.java:993)
> at
> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistry.put(EmbeddedRegistry.java:697)
> at
> org.wso2.carbon.registry.core.caching.CacheBackedRegistry.put(CacheBackedRegistry.java:508)
> at
> org.wso2.carbon.registry.core.sess

Re: [Dev] Kernel commit in user core

[Manoj Kumara]

Hi,

Applied [1] to patch0008 with 202160.


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 1:10 PM, Manoj Kumara  wrote:

> Hi Asela,
>
> Fix [1] contain public API additions and [2] adds new property to
> user-mgt.xml file. Can you please check the diff.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 3:19 AM, Asela Pathberiya  wrote:
>
>> Hi Manoj,
>>
>> Please commit following attached patches to kernel..
>>
>> [1] https://wso2.org/jira/browse/CARBON-14769
>> [2] https://wso2.org/jira/browse/IDENTITY-2281
>>
>> Thanks,
>> Asela.
>>
>> --
>> Thanks & Regards,
>> Asela
>>
>> ATL
>> Mobile : +94 777 625 933
>>
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Global cluster cache invalidation code review Notes

[Subash Chaturanga]

Hi Amal,
Can't your implementation adhere to the old JMS client version instead ?

Hi Shazni,
Since we are blocked on this for some time and Amal is in support and
having context switching on this and support issues. So can you please sit
with him and do the needful to get this issue sorted out. Please talk to a
carbon member to get their help if necessary proceed with the best approach.





On Wed, May 7, 2014 at 2:43 PM, Amal Gunatilake  wrote:

> Hi Shammi,
>
> Thanks for the idea. I tried this out with activemq-client jar and several
> other jars. Still the casting problem exists. Further inspection showed me
> that there is another older version of jms osgi bundle
> (geronimo-spec-jms_1.1.0.rc4-wso2v1) in the carbon server. I think that
> this bundle causes the issue since this is an older version of jms and when
> we include the ActiveMQ jar to the lib the org.apache.activemq.
> ActiveMQConnectionFactory will not be able to cast into older version of
> javax.jms.TopicConnectionFactory.
>
> So either we have to update the versions of existing jms bundles or we
> might have to find an older version of ActiveMQ jar which comply with
> geronimo-spec-jms_1.1.0.rc4 version.
> Appreciate your thoughts on the matter.
>
> Thank you,
>
> Thank you  & Best regards,
>
> *Amal Gunatilake*
>  Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
>
> On Tue, May 6, 2014 at 4:33 PM, Shammi Jayasinghe  wrote:
>
>> Hi Amal,
>>
>> I think the adding of  activemq-all bundle may adding another version of
>> the library which contains javax.jms and it may cause this problem. Could
>> you please try to not to add activemq-all but only the required bundles or
>> remove the other library which contains javax.jms package and try this out.
>>
>> Thanks
>> Shammi
>>
>>
>> On Tue, May 6, 2014 at 3:57 PM, Amal Gunatilake  wrote:
>>
>>> Hi Shammi/Hasitha,
>>>
>>> There is a version conflict with existing javax.jms bundles when
>>> starting the cache invalidation osgi bundle, which causes the casting
>>> problem. Any thoughts on this matter?
>>>
>>> Thank you  & Best regards,
>>>
>>> *Amal Gunatilake*
>>>  Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>>
>>> On Tue, May 6, 2014 at 1:22 PM, Shazni Nazeer  wrote:
>>>
 Hi Amal,

 Yes now the cache.xml entries are correctly read. After replacing
 activemq-core to activemq-all the debugging steps go below the
 IniatlContext line, but as you have mentioned when session object is being
 created the following exception is thrown. Therefore, still jms
 initialization fails.

 [2014-05-06 13:13:58,409] ERROR
 {org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl} -
 Global cache invalidation: Error jms broker initialization
 java.lang.ClassCastException:
 org.apache.activemq.ActiveMQConnectionFactory cannot be cast to
 javax.jms.TopicConnectionFactory
 at
 org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.initJMSBroker(JMSGlobalCacheInvalidationImpl.java:112)
 at
 org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.init(JMSGlobalCacheInvalidationImpl.java:96)
 at
 org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.invalidateCache(JMSGlobalCacheInvalidationImpl.java:131)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.removeFromCache(CachingHandler.java:255)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:211)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:207)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:91)
 at
 org.wso2.carbon.registry.core.caching.CachingHandler.put(CachingHandler.java:280)
 at
 org.wso2.carbon.registry.core.jdbc.handlers.HandlerManager.put(HandlerManager.java:2503)
 at
 org.wso2.carbon.registry.core.jdbc.handlers.HandlerLifecycleManager.put(HandlerLifecycleManager.java:993)
 at
 org.wso2.carbon.registry.core.jdbc.EmbeddedRegistry.put(EmbeddedRegistry.java:697)
 at
 org.wso2.carbon.registry.core.caching.CacheBackedRegistry.put(CacheBackedRegistry.java:508)
 at
 org.wso2.carbon.registry.core.session.UserRegistry.put(UserRegistry.java:680)
 at
 org.wso2.carbon.theme.mgt.util.ThemeUtil.transferAllThemesToRegistry(ThemeUtil.java:122)
 at
 org.wso2.carbon.theme.mgt.util.ThemeUtil.loadResourceThemes(ThemeUtil.java:175)
 at
 org.wso2.carbon.theme.mgt.internal.TenantThemeMgtServiceComponent.activate(TenantThemeMgtServiceComponent.java:53)
   

Re: [Dev] ERROR {org.wso2.carbon.server.extensions.DropinsBundleDeployer} - Error displayed in Management Node ESB Worker Manager setup.

[Chathurika Mahaarachchi]

Tried this.. but same issue observed in Management Node.


On Wed, May 7, 2014 at 5:35 PM, Manoj Kumara  wrote:

> Can you try cleaning the dropins directory and restart.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
>
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 5:33 PM, Chathurika Mahaarachchi <
> chathur...@wso2.com> wrote:
>
>> Hi ,
>>
>>
>> The following error message is displayed in Management node of ESB -
>> Worker management set up suddenly.  The cluster  was working fine earlier.
>> But now I try to start it following error is displayed in Management node
>>
>> [2014-05-07 17:15:58,367] ERROR
>> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
>> found in the dropins directory: org.wso2.carbon.logging.propfile_1.0.0.jar
>> [2014-05-07 17:15:58,369] ERROR
>> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
>> found in the dropins directory: mysql_connector_java_5.1.21_bin_1.0.0.jar
>> log4j:WARN No appenders could be found for logger
>> (com.atomikos.logging.LoggerFactory).
>> log4j:WARN Please initialize the log4j system properly.
>>
>> I have deleted the "mysql_connector_java_5.1.21_bin_1.0.0.jar" and  &
>> "org.wso2.carbon.logging.propfile_1.0.0.jar"  file form the droppings
>> folder and tried to restart the management node . but its still gives the
>> above error.
>>
>> Anyone knows the reason for this ?
>>
>> Thanks & Regards,
>>
>> --
>> *Chathurika Mahaarachchi*
>> Software Engineer, QA.
>> WSO2 Inc.: http://wso2.com/
>> lean.enterprise.middleware
>> Mobile: +94718223950
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
*Chathurika Mahaarachchi*
Software Engineer, QA.
WSO2 Inc.: http://wso2.com/
lean.enterprise.middleware
Mobile: +94718223950
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] ERROR {org.wso2.carbon.server.extensions.DropinsBundleDeployer} - Error displayed in Management Node ESB Worker Manager setup.

[Manoj Kumara]

Can you try cleaning the dropins directory and restart.

Thanks,
Manoj


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 5:33 PM, Chathurika Mahaarachchi  wrote:

> Hi ,
>
>
> The following error message is displayed in Management node of ESB -
> Worker management set up suddenly.  The cluster  was working fine earlier.
> But now I try to start it following error is displayed in Management node
>
> [2014-05-07 17:15:58,367] ERROR
> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
> found in the dropins directory: org.wso2.carbon.logging.propfile_1.0.0.jar
> [2014-05-07 17:15:58,369] ERROR
> {org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
> found in the dropins directory: mysql_connector_java_5.1.21_bin_1.0.0.jar
> log4j:WARN No appenders could be found for logger
> (com.atomikos.logging.LoggerFactory).
> log4j:WARN Please initialize the log4j system properly.
>
> I have deleted the "mysql_connector_java_5.1.21_bin_1.0.0.jar" and  &
> "org.wso2.carbon.logging.propfile_1.0.0.jar"  file form the droppings
> folder and tried to restart the management node . but its still gives the
> above error.
>
> Anyone knows the reason for this ?
>
> Thanks & Regards,
>
> --
> *Chathurika Mahaarachchi*
> Software Engineer, QA.
> WSO2 Inc.: http://wso2.com/
> lean.enterprise.middleware
> Mobile: +94718223950
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] ERROR {org.wso2.carbon.server.extensions.DropinsBundleDeployer} - Error displayed in Management Node ESB Worker Manager setup.

[Chathurika Mahaarachchi]

Hi ,


The following error message is displayed in Management node of ESB - Worker
management set up suddenly.  The cluster  was working fine earlier.  But
now I try to start it following error is displayed in Management node

[2014-05-07 17:15:58,367] ERROR
{org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
found in the dropins directory: org.wso2.carbon.logging.propfile_1.0.0.jar
[2014-05-07 17:15:58,369] ERROR
{org.wso2.carbon.server.extensions.DropinsBundleDeployer} -  Invalid Bundle
found in the dropins directory: mysql_connector_java_5.1.21_bin_1.0.0.jar
log4j:WARN No appenders could be found for logger
(com.atomikos.logging.LoggerFactory).
log4j:WARN Please initialize the log4j system properly.

I have deleted the "mysql_connector_java_5.1.21_bin_1.0.0.jar" and  &
"org.wso2.carbon.logging.propfile_1.0.0.jar"  file form the droppings
folder and tried to restart the management node . but its still gives the
above error.

Anyone knows the reason for this ?

Thanks & Regards,

-- 
*Chathurika Mahaarachchi*
Software Engineer, QA.
WSO2 Inc.: http://wso2.com/
lean.enterprise.middleware
Mobile: +94718223950
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] BRS 2.1.0 Alpha testing update

[Sandapa Handakumbura]

Hi All,

We have set up the BRS W/M separated cluster with ELB 2.1.0 and started
functional testing in the clustered setup. We will be following [1] as our
test plan (during testing more scenarios will be added if required).

[1]
https://docs.google.com/a/wso2.com/spreadsheet/ccc?key=0AnpVKBDCKX9ldERGSzFZaUxJMWFKVlVObEh0akJYRnc&usp=sharing#gid=1

Regards,
Sandapa


On Wed, May 7, 2014 at 11:55 AM, Chathurika De Silva
wrote:

> Hi All
>
> We tried to set up the cluster for above mentioned BRS version using ELB
> 2.1.1. We encountered the following blocker which we reported under LB-147
>
> Due the above issue, we are moving to ELB 2.1.0 for our further testing
> process until the issue is fixed.
>
> Best Regards
>
> --
> *Chathurika Erandi*
> Software Engineer,
> WSO2 Inc.
>
> *E-mail:* chathuri...@wso2.com
> *Mobile: *+94714 328 612
> *Blog*: chathurikaerandi.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Sandapa Handakumbura
Associate Technical Lead
WSO2.Inc. ; http://wso2.com/
M : +94777115866
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Sanjeewa Malalgoda]

On Wed, May 7, 2014 at 5:17 PM, Evanthika Amarasiri wrote:

> Hi Sanjeewa,
>
> This has some blockers and some of the commits are not there. Therefore,
> it would be good if we can get a new pack tomorrow.
>
> https://wso2.org/jira/browse/APIMANAGER-2314
> https://wso2.org/jira/browse/APIMANAGER-2313
>
Yes we found that there is missed commit related to default API feature and
we will build another set of pack tonight.

Thanks,
sanjeewa.

>
>
> ​- ​
> Evanthika
>
>
> On Wed, May 7, 2014 at 2:36 PM, Manoj Kumara  wrote:
>
>> Hi,
>>
>> Reverted from patch0007 with r202140.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:
>>
>>> Hi,
>>>
>>> Yeah, +1, lets anyway fix it in patch0007.
>>>
>>> Cheers,
>>> Anjana.
>>>
>>>
>>> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>>>
 Hi Anjana,


 On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando wrote:

> Hi Manoj,
>
> So this is a bug that can affect DSS too? .. if so, we have to patch
> in 0007 itself.
>
 This is only affecting for non blocking transports (ptt/nio). So DSS
 will not get affected by this.
 However IMO we need to revert this in Patch0007 as it is not good to
 release a kernel patch with a serious bug.


>
> Cheers,
> Anjana.
>
>
>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>
>> Hi Nuwan,
>>
>> currently patch0007 is breezed due to due to DSS release. I'll revert
>> this after talking to DSS team.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>>
>>> Hi Charitha,
>>>
>>> We figured out that this had been a regression due to a kernel patch
>>> - patch0007. Commit revision is r200946. Thanks IsuruU for the
>>> assistance.
>>>
>>> @Manoj, please revert this patch urgently since it causes a 202
>>> Accepted to be sent for all tenant requests and drops the response body.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>>
>>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge <
>>> chari...@wso2.com> wrote:
>>>
 ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
 Verified the jiras.
  However, there is a critical MT failure which can be reproduced in
 a fresh pack as well.

 When you invoke an API in a tenant, the response is not returned.
 Given below is the wire log. As you can see, the response is not sent 
 back.
 Client always gets http 202 acknowledgement instead of the actual 
 response.
 Basically MT is broken.

 Note that the same API works with the same backend in super tenant
 mode. So this must be a MT regression.

 [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
 superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
 [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection:
 close[\r][\n]"
 [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
 gzip,deflate[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
 text/xml;charset=UTF-8[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
 "urn:echoString"[\r][\n]"
 [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
 4636d529ea62b726e312a53794dccf36[\r
 ][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
 307[\r][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
 [\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
 Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
 [2014-05-07 03:25:31,898] DEBUG - wire >> ">>> xmlns:soapenv="http://schemas.xmlsoap.o
 rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
 ">[\r][\n]"
  [2014-05-07 03:25:31,898] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
 test[\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> ""
 [2014-05-07 03:25:31,917]  INFO - LogMediator To:
 local://axis2services/axis2API/v1, WSAction: urn:e
>

Re: [Dev] Test failures - wso2greg-5.0.0-SNAPSHOT

[Shelan Perera]

Hi Subash,

Will do.

Thanks


On Wed, May 7, 2014 at 3:09 PM, Subash Chaturanga  wrote:

> Hi Krishantha,
> As discussed in git migration hackethon,  Shelan will work with you on
> registry test migration.
>
> Hi Shelan,
> Please help Krishantha as discussed offline.
>
>
> On Tue, May 6, 2014 at 10:38 PM, Ajith Vitharana  wrote:
>
>> Hi Krishantha,
>>
>>
>> On Tue, May 6, 2014 at 10:23 PM, Krishantha Samaraweera <
>> krishan...@wso2.com> wrote:
>>
>>> Product teams need to own these test failure in future. We've enabled
>>> only the tests passing in our local machine.
>>>
>>
>> I wanted to verify those failures whether  due to latest test migrations
>> or actual bugs. So, if those test was passing before the migration that
>> should be passed after the migrated as well.
>>
>> Thanks.
>> Ajith
>>
>>
>>> Thanks,
>>> Krishantha.
>>>
>>>
>>> On Tue, May 6, 2014 at 10:21 PM, Krishantha Samaraweera <
>>> krishan...@wso2.com> wrote:
>>>
 Most failures are due to user management issue which is reported at -
 https://wso2.org/jira/browse/IDENTITY-2230

 Can someone form IS team please have a look.

 Thanks,
 Krishantha.


 On Tue, May 6, 2014 at 8:49 PM, Ajith Vitharana wrote:

> Hi Krishantha,
>
> The product-greg build is unstable due to test failures. Please note.
>
> [1]
> http://54.84.136.218:8080/jenkins/view/product-builds/job/product-greg/28/
>
> Thanks.
> Ajith.
>
> --
> Ajith Vitharana.
> WSO2 Inc. - http://wso2.org
> Email  :  aji...@wso2.com
> Mobile : +94772217350
>
>


 --
 Krishantha Samaraweera
 Senior Technical Lead - Test Automation
 Mobile: +94 77 7759918
 WSO2, Inc.; http://wso2.com/
 lean . enterprise . middlewear.

>>>
>>>
>>>
>>> --
>>> Krishantha Samaraweera
>>> Senior Technical Lead - Test Automation
>>> Mobile: +94 77 7759918
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middlewear.
>>>
>>
>>
>>
>> --
>> Ajith Vitharana.
>> WSO2 Inc. - http://wso2.org
>> Email  :  aji...@wso2.com
>> Mobile : +94772217350
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Thanks
> /subash
>
> *Subash Chaturanga*
> Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com
>
> email: sub...@wso2.com
> blog:  http://subashsdm.blogspot.com/
> twitter: @subash89
> phone: +9477 2225922
> Lean . Enterprise . Middleware
>



-- 
*Shelan Perera*

Senior Software Engineer
Integration Technology Group
*WSO2, Inc. : wso2.com *
lean.enterprise.middleware.

*Blog* :   blog.shelan.org
*Linked-i*n  :   http://www.linkedin.com/pub/shelan-perera/a/194/465
*Twitter* :https://twitter.com/#!/shelan

*Mobile*  : +94 772 604 402
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Update on Gsoc Project - BAM Toolbox for WSO2 Business Process Server

[Pubudu Gunatilaka]

Hi Hasitha,

Thank you for the information. I did not write a sample event listener yet.
Still trying to get some idea about BPEL and Human task processes.

I will work on what you have mentioned and let you know the progress.

Thanks.

On Wed, May 7, 2014 at 4:31 PM, Hasitha Aravinda  wrote:

> Hi Pubudu,
>
> For BPEL processes, you can enable ODE events via deploy.xml. Please refer
> [1] for more information. Similar to HumanTask you can register ODE event
> listener to BPS using bps.xml.
>
> were you able to write a sample HumanTaskEventListener ?
>
> Also try to write sample BPELEventListener and see what kind of
> information you can get from events about HumanTask/BPEL instances. The
> idea is to identify data, which we are going to publish to the BAM.
>
> Also study about BAM data publishers. [2] will be a good point to start.
>
> Thanks,
> Hasitha.
>
> [1] - http://ode.apache.org/ode-execution-events.html
> [2] -
> http://wso2.com/library/articles/2012/07/creating-custom-agents-publish-events-bamcep/
>
>
> On Wed, May 7, 2014 at 1:47 PM, Pubudu Gunatilaka wrote:
>
>> Hi,
>>
>> These days I am working with samples that are in WSO2 BPS in order to get
>> some idea about BPEL and Human task processes. Some of the processes
>> generate events and some do not.
>>
>> For the processes which generate events can use HumanTaskEventListener
>> and BPELEventListener classes to write a custom event listener. But for the
>> processes that do not generate events have to do using ODE Execution
>> events.
>>
>> According to [1] this component can be added separately to BPS.
>>
>> I would really appreciate if you can provide me some useful materials in
>> order to move forward.
>>
>>
>> [1]-
>> http://tryitnw.blogspot.com/2013/05/humantask-event-listeners-wso2-bps.html
>> --
>> Regards
>> P.C. Gunatilaka
>> Undergraduate,
>> Department of Computer Science And Engineering,
>> University of Moratuwa, Sri Lanka.
>>
>> Web  , 
>> Facebook,
>> LinkedIn  ,
>> Google+  , 
>> Twitter ,
>> About.me 
>>
>>
>
>
> --
> Hasitha Aravinda,
> Software Engineer,
> WSO2 Inc.
> Email: hasi...@wso2.com
> Mobile: +94 71 8 210 200
>
>


-- 
Regards
P.C. Gunatilaka
Undergraduate,
Department of Computer Science And Engineering,
University of Moratuwa, Sri Lanka.

Web  ,
Facebook,
LinkedIn  ,
Google+,
Twitter  ,
About.me
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Evanthika Amarasiri]

Hi Sanjeewa,

This has some blockers and some of the commits are not there. Therefore, it
would be good if we can get a new pack tomorrow.

https://wso2.org/jira/browse/APIMANAGER-2314
https://wso2.org/jira/browse/APIMANAGER-2313

​- ​
Evanthika


On Wed, May 7, 2014 at 2:36 PM, Manoj Kumara  wrote:

> Hi,
>
> Reverted from patch0007 with r202140.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> Yeah, +1, lets anyway fix it in patch0007.
>>
>> Cheers,
>> Anjana.
>>
>>
>> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>>
>>> Hi Anjana,
>>>
>>>
>>> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:
>>>
 Hi Manoj,

 So this is a bug that can affect DSS too? .. if so, we have to patch in
 0007 itself.

>>> This is only affecting for non blocking transports (ptt/nio). So DSS
>>> will not get affected by this.
>>> However IMO we need to revert this in Patch0007 as it is not good to
>>> release a kernel patch with a serious bug.
>>>
>>>

 Cheers,
 Anjana.


  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:

> Hi Nuwan,
>
> currently patch0007 is breezed due to due to DSS release. I'll revert
> this after talking to DSS team.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>
>> Hi Charitha,
>>
>> We figured out that this had been a regression due to a kernel patch
>> - patch0007. Commit revision is r200946. Thanks IsuruU for the
>> assistance.
>>
>> @Manoj, please revert this patch urgently since it causes a 202
>> Accepted to be sent for all tenant requests and drops the response body.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge <
>> chari...@wso2.com> wrote:
>>
>>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>>> Verified the jiras.
>>>  However, there is a critical MT failure which can be reproduced in
>>> a fresh pack as well.
>>>
>>> When you invoke an API in a tenant, the response is not returned.
>>> Given below is the wire log. As you can see, the response is not sent 
>>> back.
>>> Client always gets http 202 acknowledgement instead of the actual 
>>> response.
>>> Basically MT is broken.
>>>
>>> Note that the same API works with the same backend in super tenant
>>> mode. So this must be a MT regression.
>>>
>>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>>> 4636d529ea62b726e312a53794dccf36[\r
>>> ][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
>>> 307[\r][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>>> [2014-05-07 03:25:31,898] DEBUG - wire >> ">> xmlns:soapenv="http://schemas.xmlsoap.o
>>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
>>> ">[\r][\n]"
>>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>> test[\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>>> local://axis2services/axis2API/v1, WSAction: urn:e
>>> choString, SOAPAction: urn:echoString, MessageID:
>>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>>> n: request, Envelope: >> encoding="utf-8"?>http://service.carbon.wso2.org";>
>>>   
>>>  
>>>  test
>>>   
>>>
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST
>>> /services/Axis2Service HTTP/1.1

Re: [Dev] Update on Gsoc Project - BAM Toolbox for WSO2 Business Process Server

[Hasitha Aravinda]

Hi Pubudu,

For BPEL processes, you can enable ODE events via deploy.xml. Please refer
[1] for more information. Similar to HumanTask you can register ODE event
listener to BPS using bps.xml.

were you able to write a sample HumanTaskEventListener ?

Also try to write sample BPELEventListener and see what kind of information
you can get from events about HumanTask/BPEL instances. The idea is to
identify data, which we are going to publish to the BAM.

Also study about BAM data publishers. [2] will be a good point to start.

Thanks,
Hasitha.

[1] - http://ode.apache.org/ode-execution-events.html
[2] -
http://wso2.com/library/articles/2012/07/creating-custom-agents-publish-events-bamcep/


On Wed, May 7, 2014 at 1:47 PM, Pubudu Gunatilaka wrote:

> Hi,
>
> These days I am working with samples that are in WSO2 BPS in order to get
> some idea about BPEL and Human task processes. Some of the processes
> generate events and some do not.
>
> For the processes which generate events can use HumanTaskEventListener and
> BPELEventListener classes to write a custom event listener. But for the
> processes that do not generate events have to do using ODE Execution
> events.
>
> According to [1] this component can be added separately to BPS.
>
> I would really appreciate if you can provide me some useful materials in
> order to move forward.
>
>
> [1]-
> http://tryitnw.blogspot.com/2013/05/humantask-event-listeners-wso2-bps.html
> --
> Regards
> P.C. Gunatilaka
> Undergraduate,
> Department of Computer Science And Engineering,
> University of Moratuwa, Sri Lanka.
>
> Web  , 
> Facebook,
> LinkedIn  ,
> Google+  , 
> Twitter ,
> About.me 
>
>


-- 
Hasitha Aravinda,
Software Engineer,
WSO2 Inc.
Email: hasi...@wso2.com
Mobile: +94 71 8 210 200
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] ELB 2.1.1 Alpha Released

[Isuru Udana]

Hi All,

WSO2 ELB 2.1.1 Alpha is available at [1]

[1]
https://svn.wso2.org/repos/wso2/people/isuruu/ELB211Release/alpha/wso2elb-2.1.1.zip


Thanks.

-- 
*Isuru Udana*
Senior
* Software Engineer*
WSO2 Inc.; http://wso2.com
email: isu...@wso2.com cell: +94 77 3791887
blog: http://mytecheye.blogspot.com/
twitter: http://twitter.com/isudana
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Streaming JSON Fix

[Anjana Fernando]

Hi Shelan,

I guess the 2'nd object name should be "_postinsert" not "insert",
basically the service dispatch is not happening, double check the service
URL also. And also, there's a JSONSample.dbs that goes with data services
as a sample, check that with batch requests enabled, at [1], contains how
the batch request should be created.

[1] https://docs.wso2.org/display/DSS321/JSON+Mapping

Cheers,
Anjana.


On Wed, May 7, 2014 at 3:28 PM, Shelan Perera  wrote:

> Hi,
>
> I have checked with the pack [1] here available and the original issue is
> not fixed yet. I can still reproduce it and getting the error,
>
> Sample Request
> 
> {
>"_postinsert_batch_req":{
>   "insert":[
>  {
> "name":"route1",
> "length":"200"
>  },
>  {
> "name":"route2",
> "length":"300"
>  },
>  {
> "name":"route3",
> "length":"400"
>  }
>   ]
>}
> }
>
> Error
> 
>  {"Fault":{"faultcode":"axis2ns1:Client","faultstring":"The endpoint
> reference (EPR) for the Operation not found is /services/RouteService and
> the WSA Action = null. If this EPR was previously reachable, please contact
> the server administrator.","detail":""}}
>
> I am attaching the DBS i used to reproduce if anyone needs it. We may need
> to reopen the original issue [2] and resolve it properly as this patch did
> not fix it.
>
>
>
> [1] http://ec2-54-198-211-48.compute-1.amazonaws.com/chunk10/
>
> [2] https://wso2.org/jira/browse/DS-891
>
>
>
> Thanks
>
>
> On Mon, May 5, 2014 at 4:27 PM, Manoj Kumara  wrote:
>
>> Hi,
>>
>> Applied to patch0007 with r201892.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Sat, May 3, 2014 at 11:09 PM, Shameera Rathnayaka 
>> wrote:
>>
>>> Hi Anjana,
>>>
>>> I will have a look and apply the patch.
>>>
>>> Thanks,
>>> Shameera.
>>>
>>>
>>> On Sat, May 3, 2014 at 4:11 PM, Anjana Fernando  wrote:
>>>
 Hi Shameera,

 I've fixed a bug in the streaming JSON implementation, related to the
 issue [1]. I've given the explanation to the fix there in a comment, please
 review it, and commit it to the necessary places, i.e. kernel patch07,
 GitHub, Axis2 etc.. We need this for the Monday DSS 3.2.1 release. Chanika
 please follow up.

 [1] https://wso2.org/jira/browse/DS-891

 Cheers,
 Anjana.
 --
 *Anjana Fernando*
 Senior Technical Lead
 WSO2 Inc. | http://wso2.com
 lean . enterprise . middleware

>>>
>>>
>>>
>>> --
>>> *Software Engineer - WSO2 Inc.*
>>> *email: shameera AT wso2.com  , shameera AT
>>> apache.org *
>>> *phone:  +9471 922 1454 <%2B9471%20922%201454>*
>>>
>>> *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
>>> *Twitter : *https://twitter.com/Shameera_R
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Shelan Perera*
>
> Senior Software Engineer
> Integration Technology Group
> *WSO2, Inc. : wso2.com *
> lean.enterprise.middleware.
>
> *Blog* :   blog.shelan.org
> *Linked-i*n  :   http://www.linkedin.com/pub/shelan-perera/a/194/465
> *Twitter* :https://twitter.com/#!/shelan
>
> *Mobile*  : +94 772 604 402
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Anjana Fernando*
Senior Technical Lead
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Streaming JSON Fix

[Shelan Perera]

Hi,

I have checked with the pack [1] here available and the original issue is
not fixed yet. I can still reproduce it and getting the error,

Sample Request

{
   "_postinsert_batch_req":{
  "insert":[
 {
"name":"route1",
"length":"200"
 },
 {
"name":"route2",
"length":"300"
 },
 {
"name":"route3",
"length":"400"
 }
  ]
   }
}

Error

 {"Fault":{"faultcode":"axis2ns1:Client","faultstring":"The endpoint
reference (EPR) for the Operation not found is /services/RouteService and
the WSA Action = null. If this EPR was previously reachable, please contact
the server administrator.","detail":""}}

I am attaching the DBS i used to reproduce if anyone needs it. We may need
to reopen the original issue [2] and resolve it properly as this patch did
not fix it.



[1] http://ec2-54-198-211-48.compute-1.amazonaws.com/chunk10/

[2] https://wso2.org/jira/browse/DS-891



Thanks


On Mon, May 5, 2014 at 4:27 PM, Manoj Kumara  wrote:

> Hi,
>
> Applied to patch0007 with r201892.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Sat, May 3, 2014 at 11:09 PM, Shameera Rathnayaka wrote:
>
>> Hi Anjana,
>>
>> I will have a look and apply the patch.
>>
>> Thanks,
>> Shameera.
>>
>>
>> On Sat, May 3, 2014 at 4:11 PM, Anjana Fernando  wrote:
>>
>>> Hi Shameera,
>>>
>>> I've fixed a bug in the streaming JSON implementation, related to the
>>> issue [1]. I've given the explanation to the fix there in a comment, please
>>> review it, and commit it to the necessary places, i.e. kernel patch07,
>>> GitHub, Axis2 etc.. We need this for the Monday DSS 3.2.1 release. Chanika
>>> please follow up.
>>>
>>> [1] https://wso2.org/jira/browse/DS-891
>>>
>>> Cheers,
>>> Anjana.
>>> --
>>> *Anjana Fernando*
>>> Senior Technical Lead
>>> WSO2 Inc. | http://wso2.com
>>> lean . enterprise . middleware
>>>
>>
>>
>>
>> --
>> *Software Engineer - WSO2 Inc.*
>> *email: shameera AT wso2.com  , shameera AT apache.org
>> *
>> *phone:  +9471 922 1454 <%2B9471%20922%201454>*
>>
>> *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561
>> *Twitter : *https://twitter.com/Shameera_R
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Shelan Perera*

Senior Software Engineer
Integration Technology Group
*WSO2, Inc. : wso2.com *
lean.enterprise.middleware.

*Blog* :   blog.shelan.org
*Linked-i*n  :   http://www.linkedin.com/pub/shelan-perera/a/194/465
*Twitter* :https://twitter.com/#!/shelan

*Mobile*  : +94 772 604 402


RouteService.dbs
Description: Binary data
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ES]No Established Sessions corresponding to Session Indexes provided during logout.

[Udara Rathnayake]

I managed to solved this by changing the identityProviderURL within store
configuration.


On Wed, May 7, 2014 at 11:59 AM, Udara Rathnayake  wrote:

> Hi all,
>
> I tried to answer this SO[1], in my ES setup SSO(login/logout & sso
> between store/publisher) works perfectly.
> But I'm getting the following error during log-out action and browser
> redirects back to the admin-console UI.
>
> ERROR
> {org.wso2.carbon.identity.sso.saml.processors.LogoutRequestProcessor} -  No
> Established Sessions corresponding to Session Indexes provided.
>
> The same error reported before too[2][3], but I'm unable to find the
> solution.
>
> [1]
> http://stackoverflow.com/questions/23481465/deploy-wso2-enterprise-app-store-in-ec2-using-elb
> [2] SSO enabled application logout action leads to redirect user to IS
> Server login page in IS 4.1.0
> [3] [Dev] SAML2 SSO based login fails with IS-4.5.0-M4 as IdP and ESB-4.7
> as service provider
>
> Regards,
> UdaraR
>
> --
> *Udara Rathnayake*
> Software Engineer
> WSO2 Inc. : http://wso2.com
>
> Mobile : +94 772207239
> Twitter : http://twitter.com/udarakr
> Blog: http://udarakr.blogspot.com
>
>


-- 
*Udara Rathnayake*
Software Engineer
WSO2 Inc. : http://wso2.com

Mobile : +94 772207239
Twitter : http://twitter.com/udarakr
Blog: http://udarakr.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Test failures - wso2greg-5.0.0-SNAPSHOT

[Subash Chaturanga]

Hi Krishantha,
As discussed in git migration hackethon,  Shelan will work with you on
registry test migration.

Hi Shelan,
Please help Krishantha as discussed offline.


On Tue, May 6, 2014 at 10:38 PM, Ajith Vitharana  wrote:

> Hi Krishantha,
>
>
> On Tue, May 6, 2014 at 10:23 PM, Krishantha Samaraweera <
> krishan...@wso2.com> wrote:
>
>> Product teams need to own these test failure in future. We've enabled
>> only the tests passing in our local machine.
>>
>
> I wanted to verify those failures whether  due to latest test migrations
> or actual bugs. So, if those test was passing before the migration that
> should be passed after the migrated as well.
>
> Thanks.
> Ajith
>
>
>> Thanks,
>> Krishantha.
>>
>>
>> On Tue, May 6, 2014 at 10:21 PM, Krishantha Samaraweera <
>> krishan...@wso2.com> wrote:
>>
>>> Most failures are due to user management issue which is reported at -
>>> https://wso2.org/jira/browse/IDENTITY-2230
>>>
>>> Can someone form IS team please have a look.
>>>
>>> Thanks,
>>> Krishantha.
>>>
>>>
>>> On Tue, May 6, 2014 at 8:49 PM, Ajith Vitharana  wrote:
>>>
 Hi Krishantha,

 The product-greg build is unstable due to test failures. Please note.

 [1]
 http://54.84.136.218:8080/jenkins/view/product-builds/job/product-greg/28/

 Thanks.
 Ajith.

 --
 Ajith Vitharana.
 WSO2 Inc. - http://wso2.org
 Email  :  aji...@wso2.com
 Mobile : +94772217350


>>>
>>>
>>> --
>>> Krishantha Samaraweera
>>> Senior Technical Lead - Test Automation
>>> Mobile: +94 77 7759918
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middlewear.
>>>
>>
>>
>>
>> --
>> Krishantha Samaraweera
>> Senior Technical Lead - Test Automation
>> Mobile: +94 77 7759918
>> WSO2, Inc.; http://wso2.com/
>> lean . enterprise . middlewear.
>>
>
>
>
> --
> Ajith Vitharana.
> WSO2 Inc. - http://wso2.org
> Email  :  aji...@wso2.com
> Mobile : +94772217350
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks
/subash

*Subash Chaturanga*
Senior Software Engineer :Integration TG; WSO2 Inc. http://wso2.com

email: sub...@wso2.com
blog:  http://subashsdm.blogspot.com/
twitter: @subash89
phone: +9477 2225922
Lean . Enterprise . Middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Global cluster cache invalidation code review Notes

[Amal Gunatilake]

Hi Shammi,

Thanks for the idea. I tried this out with activemq-client jar and several
other jars. Still the casting problem exists. Further inspection showed me
that there is another older version of jms osgi bundle
(geronimo-spec-jms_1.1.0.rc4-wso2v1) in the carbon server. I think that
this bundle causes the issue since this is an older version of jms and when
we include the ActiveMQ jar to the lib the org.apache.activemq.
ActiveMQConnectionFactory will not be able to cast into older version of
javax.jms.TopicConnectionFactory.

So either we have to update the versions of existing jms bundles or we
might have to find an older version of ActiveMQ jar which comply with
geronimo-spec-jms_1.1.0.rc4 version.
Appreciate your thoughts on the matter.

Thank you,

Thank you  & Best regards,

*Amal Gunatilake*
 Software Engineer
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware


On Tue, May 6, 2014 at 4:33 PM, Shammi Jayasinghe  wrote:

> Hi Amal,
>
> I think the adding of  activemq-all bundle may adding another version of
> the library which contains javax.jms and it may cause this problem. Could
> you please try to not to add activemq-all but only the required bundles or
> remove the other library which contains javax.jms package and try this out.
>
> Thanks
> Shammi
>
>
> On Tue, May 6, 2014 at 3:57 PM, Amal Gunatilake  wrote:
>
>> Hi Shammi/Hasitha,
>>
>> There is a version conflict with existing javax.jms bundles when starting
>> the cache invalidation osgi bundle, which causes the casting problem. Any
>> thoughts on this matter?
>>
>> Thank you  & Best regards,
>>
>> *Amal Gunatilake*
>>  Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>>
>> On Tue, May 6, 2014 at 1:22 PM, Shazni Nazeer  wrote:
>>
>>> Hi Amal,
>>>
>>> Yes now the cache.xml entries are correctly read. After replacing
>>> activemq-core to activemq-all the debugging steps go below the
>>> IniatlContext line, but as you have mentioned when session object is being
>>> created the following exception is thrown. Therefore, still jms
>>> initialization fails.
>>>
>>> [2014-05-06 13:13:58,409] ERROR
>>> {org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl} -
>>> Global cache invalidation: Error jms broker initialization
>>> java.lang.ClassCastException:
>>> org.apache.activemq.ActiveMQConnectionFactory cannot be cast to
>>> javax.jms.TopicConnectionFactory
>>> at
>>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.initJMSBroker(JMSGlobalCacheInvalidationImpl.java:112)
>>> at
>>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.init(JMSGlobalCacheInvalidationImpl.java:96)
>>> at
>>> org.wso2.carbon.caching.invalidator.jms.JMSGlobalCacheInvalidationImpl.invalidateCache(JMSGlobalCacheInvalidationImpl.java:131)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.removeFromCache(CachingHandler.java:255)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:211)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.clearAncestry(CachingHandler.java:232)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:207)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.clearCache(CachingHandler.java:91)
>>> at
>>> org.wso2.carbon.registry.core.caching.CachingHandler.put(CachingHandler.java:280)
>>> at
>>> org.wso2.carbon.registry.core.jdbc.handlers.HandlerManager.put(HandlerManager.java:2503)
>>> at
>>> org.wso2.carbon.registry.core.jdbc.handlers.HandlerLifecycleManager.put(HandlerLifecycleManager.java:993)
>>> at
>>> org.wso2.carbon.registry.core.jdbc.EmbeddedRegistry.put(EmbeddedRegistry.java:697)
>>> at
>>> org.wso2.carbon.registry.core.caching.CacheBackedRegistry.put(CacheBackedRegistry.java:508)
>>> at
>>> org.wso2.carbon.registry.core.session.UserRegistry.put(UserRegistry.java:680)
>>> at
>>> org.wso2.carbon.theme.mgt.util.ThemeUtil.transferAllThemesToRegistry(ThemeUtil.java:122)
>>> at
>>> org.wso2.carbon.theme.mgt.util.ThemeUtil.loadResourceThemes(ThemeUtil.java:175)
>>> at
>>> org.wso2.carbon.theme.mgt.internal.TenantThemeMgtServiceComponent.activate(TenantThemeMgtServiceComponent.java:53)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ServiceComponent.activate(ServiceComponent.java:260)
>>> at
>>> org.eclipse.equinox.internal.ds.model.ServiceComponentProp.activate(ServiceComponentProp.java:146)
>>> at
>>> org.eclipse.equinox.interna

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Manoj Kumara]

Hi,

Reverted from patch0007 with r202140.

Thanks,
Manoj


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:

> Hi,
>
> Yeah, +1, lets anyway fix it in patch0007.
>
> Cheers,
> Anjana.
>
>
> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>
>> Hi Anjana,
>>
>>
>> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:
>>
>>> Hi Manoj,
>>>
>>> So this is a bug that can affect DSS too? .. if so, we have to patch in
>>> 0007 itself.
>>>
>> This is only affecting for non blocking transports (ptt/nio). So DSS will
>> not get affected by this.
>> However IMO we need to revert this in Patch0007 as it is not good to
>> release a kernel patch with a serious bug.
>>
>>
>>>
>>> Cheers,
>>> Anjana.
>>>
>>>
>>>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>>>
 Hi Nuwan,

 currently patch0007 is breezed due to due to DSS release. I'll revert
 this after talking to DSS team.

 Thanks,
 Manoj


 *Manoj Kumara*
 Software Engineer
 WSO2 Inc. http://wso2.com/
 *lean.enterprise.middleware*
 Mobile: +94713448188


 On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:

> Hi Charitha,
>
> We figured out that this had been a regression due to a kernel patch -
> patch0007. Commit revision is r200946. Thanks IsuruU for the
> assistance.
>
> @Manoj, please revert this patch urgently since it causes a 202
> Accepted to be sent for all tenant requests and drops the response body.
>
> Thanks,
> NuwanD.
>
>
> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge  > wrote:
>
>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>> Verified the jiras.
>>  However, there is a critical MT failure which can be reproduced in a
>> fresh pack as well.
>>
>> When you invoke an API in a tenant, the response is not returned.
>> Given below is the wire log. As you can see, the response is not sent 
>> back.
>> Client always gets http 202 acknowledgement instead of the actual 
>> response.
>> Basically MT is broken.
>>
>> Note that the same API works with the same backend in super tenant
>> mode. So this must be a MT regression.
>>
>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>> 4636d529ea62b726e312a53794dccf36[\r
>> ][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
>> 307[\r][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
>> [\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>> [2014-05-07 03:25:31,898] DEBUG - wire >> "> xmlns:soapenv="http://schemas.xmlsoap.o
>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
>> ">[\r][\n]"
>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>> [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>  [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>> [\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>> test[\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>  [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>> local://axis2services/axis2API/v1, WSAction: urn:e
>> choString, SOAPAction: urn:echoString, MessageID:
>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>> n: request, Envelope: > encoding="utf-8"?>http://service.carbon.wso2.org";>
>>   
>>  
>>  test
>>   
>>
>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST
>> /services/Axis2Service HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
>> chunked[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Host:
>> localhost:9764[\r][\n]"
>>

Re: [Dev] Moving databridge components to a separate git repository

[Sriskandarajah Suhothayan]

No thats wrong!

Data bridge its just a transport. so that have to be in the carbon commons

people and write deferent clients to that e.g web app data publisher
Here that has to go to the product/specific repo e.g
AS-product/carbon-deplyment

Then some others can write receiver callbacks e.g BAM and CEP
That has to go to BAM and CEP.

Currently some of these are in the same component that is wrong, we have to
break this and move them accordingly.

Regards
Suho



On Wed, May 7, 2014 at 2:27 PM, Kasun Gajasinghe  wrote:

>
>
>
> On Wed, May 7, 2014 at 1:12 PM, Gihan Anuruddha  wrote:
>
>> Hi Kasun,
>>
>> No, not always.  We can do changes that backward compatible way like we
>> did in our last BAM 2.4.1 release. Even though might need to add
>> improvements frequently to these client components.
>>
>>
> Ok. Either way, both these set of components need to live outside the
> carbon-commons.
>
>
>  Regards,
>> Gihan
>>
>>
>> On Wed, May 7, 2014 at 12:59 PM, Kasun Gajasinghe wrote:
>>
>>> Hi Gihan,
>>>
>>>
>>> On Wed, May 7, 2014 at 11:23 AM, Gihan Anuruddha  wrote:
>>>
 Hi Rajeev,

  We can divide databridge components into a two separate parts as
 server and client.  AFAIK at the moment server part only used by BAM and
 CEP. But I think client part might need to all other wso2 products since we
 are going to create toolboxes for all of them.  So IMHO is we can keep
 those client components in the carbon-commons and we can create
 separate git repo for the databridge server related components.

>>>
>>> When you change the data-bridge server/receiver, you will also have to
>>> modify the clients appropriately, right? Therefore, I think it's better
>>> keep all in one place. And, I'm -1 to keep any data-bridge components in
>>> carbon-commons. Carbon-commons is not the place to keep components that
>>> changes frequently. It's for components like soap-tracer, wsdl2code etc.
>>> that hardly get any commit.
>>>
>>> I'm +1 to create a new repo to keep the data-bridge components. There
>>> around 11 data-bridge components as I see.
>>>
>>> Regards,
>>> KasunG
>>>
>>>

 WDYT?

 Regards,
 Gihan


 On Wed, May 7, 2014 at 10:56 AM, Rajeev Sampath wrote:

> Hi,
>
> Currently part of the data-bridge (core components) are in
> carbon-commons and the rest is in carbon-analytics. However there are
> arguments that carbon-commons is not the right place to have these
> data-bridge components.
>
> Completely moving this to carbon-analytics doesn't seem to be a good
> option either since quite a few products depend on this and they will have
> to wait for a carbon-analytics release when there are updates.
>
> Do we need a separate git repo for data-bridge? Or else a better place
> to move this?
>
>
> Thanks
> Rajeev
>
> --
> Rajeev Sampath
> Senior Software Engineer
> WSO2, Inc.; http://www.wso2.com.
>
> Mobile:
> * +94716265766 <%2B94716265766>*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 W.G. Gihan Anuruddha

 Senior Software Engineer | WSO2, Inc.
 M: +94772272595

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


>>>
>>>
>>> --
>>>
>>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
>>> email: kasung AT spamfree wso2.com
>>> linked-in: http://lk.linkedin.com/in/gajasinghe
>>> blog: http://kasunbg.org
>>>
>>>
>>>
>>
>>
>>
>> --
>> W.G. Gihan Anuruddha
>> Senior Software Engineer | WSO2, Inc.
>> M: +94772272595
>>
>
>
>
> --
>
> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

*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 *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Moving databridge components to a separate git repository

[Kasun Gajasinghe]

On Wed, May 7, 2014 at 1:12 PM, Gihan Anuruddha  wrote:

> Hi Kasun,
>
> No, not always.  We can do changes that backward compatible way like we
> did in our last BAM 2.4.1 release. Even though might need to add
> improvements frequently to these client components.
>
>
Ok. Either way, both these set of components need to live outside the
carbon-commons.


Regards,
> Gihan
>
>
> On Wed, May 7, 2014 at 12:59 PM, Kasun Gajasinghe  wrote:
>
>> Hi Gihan,
>>
>>
>> On Wed, May 7, 2014 at 11:23 AM, Gihan Anuruddha  wrote:
>>
>>> Hi Rajeev,
>>>
>>>  We can divide databridge components into a two separate parts as
>>> server and client.  AFAIK at the moment server part only used by BAM and
>>> CEP. But I think client part might need to all other wso2 products since we
>>> are going to create toolboxes for all of them.  So IMHO is we can keep
>>> those client components in the carbon-commons and we can create
>>> separate git repo for the databridge server related components.
>>>
>>
>> When you change the data-bridge server/receiver, you will also have to
>> modify the clients appropriately, right? Therefore, I think it's better
>> keep all in one place. And, I'm -1 to keep any data-bridge components in
>> carbon-commons. Carbon-commons is not the place to keep components that
>> changes frequently. It's for components like soap-tracer, wsdl2code etc.
>> that hardly get any commit.
>>
>> I'm +1 to create a new repo to keep the data-bridge components. There
>> around 11 data-bridge components as I see.
>>
>> Regards,
>> KasunG
>>
>>
>>>
>>> WDYT?
>>>
>>> Regards,
>>> Gihan
>>>
>>>
>>> On Wed, May 7, 2014 at 10:56 AM, Rajeev Sampath wrote:
>>>
 Hi,

 Currently part of the data-bridge (core components) are in
 carbon-commons and the rest is in carbon-analytics. However there are
 arguments that carbon-commons is not the right place to have these
 data-bridge components.

 Completely moving this to carbon-analytics doesn't seem to be a good
 option either since quite a few products depend on this and they will have
 to wait for a carbon-analytics release when there are updates.

 Do we need a separate git repo for data-bridge? Or else a better place
 to move this?


 Thanks
 Rajeev

 --
 Rajeev Sampath
 Senior Software Engineer
 WSO2, Inc.; http://www.wso2.com.

 Mobile:
 * +94716265766 <%2B94716265766>*

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


>>>
>>>
>>> --
>>> W.G. Gihan Anuruddha
>>>
>>> Senior Software Engineer | WSO2, Inc.
>>> M: +94772272595
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>>
>> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
>> email: kasung AT spamfree wso2.com
>> linked-in: http://lk.linkedin.com/in/gajasinghe
>> blog: http://kasunbg.org
>>
>>
>>
>
>
>
> --
> W.G. Gihan Anuruddha
> Senior Software Engineer | WSO2, Inc.
> M: +94772272595
>



-- 

*Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Nuwan Dias]

Yes. This has already been fixed. Need to update the registry core version
in the packs


On Wed, May 7, 2014 at 2:23 PM, Nirodha Pramod  wrote:

> Hi,
>
> Cannot browse registry in above API-M pack.
>
> JIRA - https://wso2.org/jira/browse/APIMANAGER-2310
>
>
> regards,
> Nirodha
>
>
> On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> Yeah, +1, lets anyway fix it in patch0007.
>>
>> Cheers,
>> Anjana.
>>
>>
>> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>>
>>> Hi Anjana,
>>>
>>>
>>> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:
>>>
 Hi Manoj,

 So this is a bug that can affect DSS too? .. if so, we have to patch in
 0007 itself.

>>> This is only affecting for non blocking transports (ptt/nio). So DSS
>>> will not get affected by this.
>>> However IMO we need to revert this in Patch0007 as it is not good to
>>> release a kernel patch with a serious bug.
>>>
>>>

 Cheers,
 Anjana.


  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:

> Hi Nuwan,
>
> currently patch0007 is breezed due to due to DSS release. I'll revert
> this after talking to DSS team.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>
>> Hi Charitha,
>>
>> We figured out that this had been a regression due to a kernel patch
>> - patch0007. Commit revision is r200946. Thanks IsuruU for the
>> assistance.
>>
>> @Manoj, please revert this patch urgently since it causes a 202
>> Accepted to be sent for all tenant requests and drops the response body.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge <
>> chari...@wso2.com> wrote:
>>
>>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>>> Verified the jiras.
>>>  However, there is a critical MT failure which can be reproduced in
>>> a fresh pack as well.
>>>
>>> When you invoke an API in a tenant, the response is not returned.
>>> Given below is the wire log. As you can see, the response is not sent 
>>> back.
>>> Client always gets http 202 acknowledgement instead of the actual 
>>> response.
>>> Basically MT is broken.
>>>
>>> Note that the same API works with the same backend in super tenant
>>> mode. So this must be a MT regression.
>>>
>>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>>> 4636d529ea62b726e312a53794dccf36[\r
>>> ][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
>>> 307[\r][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>>> [2014-05-07 03:25:31,898] DEBUG - wire >> ">> xmlns:soapenv="http://schemas.xmlsoap.o
>>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
>>> ">[\r][\n]"
>>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>> test[\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>>> local://axis2services/axis2API/v1, WSAction: urn:e
>>> choString, SOAPAction: urn:echoString, MessageID:
>>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>>> n: request, Envelope: >> encoding="utf-8"?>http://service.carbon.wso2.org";>
>>>   
>>>  
>>>  test
>>>   
>>>
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST
>>> /services/Axis2Service HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Nirodha Pramod]

Hi,

Cannot browse registry in above API-M pack.

JIRA - https://wso2.org/jira/browse/APIMANAGER-2310


regards,
Nirodha


On Wed, May 7, 2014 at 1:34 PM, Anjana Fernando  wrote:

> Hi,
>
> Yeah, +1, lets anyway fix it in patch0007.
>
> Cheers,
> Anjana.
>
>
> On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:
>
>> Hi Anjana,
>>
>>
>> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:
>>
>>> Hi Manoj,
>>>
>>> So this is a bug that can affect DSS too? .. if so, we have to patch in
>>> 0007 itself.
>>>
>> This is only affecting for non blocking transports (ptt/nio). So DSS will
>> not get affected by this.
>> However IMO we need to revert this in Patch0007 as it is not good to
>> release a kernel patch with a serious bug.
>>
>>
>>>
>>> Cheers,
>>> Anjana.
>>>
>>>
>>>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>>>
 Hi Nuwan,

 currently patch0007 is breezed due to due to DSS release. I'll revert
 this after talking to DSS team.

 Thanks,
 Manoj


 *Manoj Kumara*
 Software Engineer
 WSO2 Inc. http://wso2.com/
 *lean.enterprise.middleware*
 Mobile: +94713448188


 On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:

> Hi Charitha,
>
> We figured out that this had been a regression due to a kernel patch -
> patch0007. Commit revision is r200946. Thanks IsuruU for the
> assistance.
>
> @Manoj, please revert this patch urgently since it causes a 202
> Accepted to be sent for all tenant requests and drops the response body.
>
> Thanks,
> NuwanD.
>
>
> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge  > wrote:
>
>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>> Verified the jiras.
>>  However, there is a critical MT failure which can be reproduced in a
>> fresh pack as well.
>>
>> When you invoke an API in a tenant, the response is not returned.
>> Given below is the wire log. As you can see, the response is not sent 
>> back.
>> Client always gets http 202 acknowledgement instead of the actual 
>> response.
>> Basically MT is broken.
>>
>> Note that the same API works with the same backend in super tenant
>> mode. So this must be a MT regression.
>>
>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>> 4636d529ea62b726e312a53794dccf36[\r
>> ][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length:
>> 307[\r][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
>> [\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>> [2014-05-07 03:25:31,898] DEBUG - wire >> "> xmlns:soapenv="http://schemas.xmlsoap.o
>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
>> ">[\r][\n]"
>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>> [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>  [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>> [\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>> test[\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>  [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>> local://axis2services/axis2API/v1, WSAction: urn:e
>> choString, SOAPAction: urn:echoString, MessageID:
>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>> n: request, Envelope: > encoding="utf-8"?>http://service.carbon.wso2.org";>
>>   
>>  
>>  test
>>   
>>
>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST
>> /services/Axis2Service HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
>> chunked[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Host:
>> localhost:9764[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "C

[Dev] WSO2 Contact Directory Android App

[Ahsan Shamsudeen]

Hi ,

I have finished off the WSO2 contact manager Android App which have
following functionalities.
- View contact's details such as mobile no, office phone,email, team,
designation of WSO2 employees
- Search contacts
-  Place a call , email , sms to a contact
- Login using WSO2 user credentials.
- update new contact details by syncing to the HR database when there is
Internet   connection. The App work in  both online as well as offline
mode.

This application connect to the HR database to get employee information.
The HR database providing an access token to access this database through
OAuth 2.0 .
It was all fine .

But, unfortunately, The HR server  is not working last couple of days.As I
think, their server certificate might got expired. So, I couldn't do a demo
on my project.

@Udeshika, @ Shan - Can you please contact with Micro Image people and make
the server up ?

most probably, we'll be finishing our internship by this Friday. So, please
be kind enough to take necessary action as soon as possible.





-- 
Ahsan Shamsudeen
Software Engineer Intern
WSO2, Inc.:http://wso2.com
lean.enterprise.middleware

Mobile - +9471554
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Update on Gsoc Project - BAM Toolbox for WSO2 Business Process Server

[Pubudu Gunatilaka]

Hi,

These days I am working with samples that are in WSO2 BPS in order to get
some idea about BPEL and Human task processes. Some of the processes
generate events and some do not.

For the processes which generate events can use HumanTaskEventListener and
BPELEventListener classes to write a custom event listener. But for the
processes that do not generate events have to do using ODE Execution
events.

According to [1] this component can be added separately to BPS.

I would really appreciate if you can provide me some useful materials in
order to move forward.


[1]-
http://tryitnw.blogspot.com/2013/05/humantask-event-listeners-wso2-bps.html
-- 
Regards
P.C. Gunatilaka
Undergraduate,
Department of Computer Science And Engineering,
University of Moratuwa, Sri Lanka.

Web  ,
Facebook,
LinkedIn  ,
Google+,
Twitter  ,
About.me
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] WSO2 Business Activity Monitor 2.4.1 Released!

[Dunith Dhanushka]

The WSO2 Business Activity Monitor development team is pleased to announce
the release of WSO2 Business Activity Monitor
2.4.1

WSO2 Business Activity Monitor (WSO2 BAM) is a comprehensive framework
designed to solve the problems in the wide area of business activity
monitoring. WSO2 BAM comprises of many modules to give the best of
performance, scalability and customizability. This allows to achieve
requirements of business users, dev ops, CEOs without spending countless
months on customizing the solution without sacrificing performance or the
ability to scale.

WSO2 BAM is powered by WSO2 Carbon , the
SOA middleware component platform.

*License*

WSO2 BAM is an open source software product and is release under Apache
Software License v2.0 .

*Release Highlights*

   - Event searching and visualization with BAM Message Console
   - Message Interceptor/publisher for HL7 transport
   - Shipping HL7 toolbox with BAM
   - Upgraded embedded Cassandra version to 1.2
   - SVN based artifact deployment synchronizer
   - Added Oracle DB support for Hive meta stores

*Key Features of WSO2 BAM*

   - Data Agents
  1. A re-usable Agent API to publish events to the BAM server from any
  application (samples included)
  2. Apache Thrift based Agents to publish data at extremely high
  throughput rates
  3. Load balancing and HA for all data agents
  - Event Storage
  1. Apache Cassandra based scalable data architecture for high
  throughput of writes and reads
  2. Carbon based security mechanism on top of Cassandra
   - Analytics
  1. An Analyzer Framework with the capability of Writing the the Hive
  Scripts and run Hadoop Jobs, which enables provides more
performance in big
  data
  2. This has the capability of writing and plugging in any custom
  analysis tasks
  3. Scheduling capability of analysis tasks
  - Visualization
  1. Step-by-Step Easy Gadget Generation Wizard
  2. Jaggery based gadgets generation
  3. Capability use with most commonly used data sources, such as
  MySQL, H2, etc.
  4. Google gadgets based dashboard
  - Toolbox Deployment
  1. Easy deployment of default scenarios
  2. Bundled required hive scripts and gadgets and deploy and undeploys
  with a click go
  3. Capability to deploy custom toolboxes
  - Toolboxes
  1. Service stats toolbox
  2. Mediation statistic toolbox
  3. Message tracing toolbox
  4. Real-Time Traffic monitoring toolbox
  5. HL7 Toolbox

*Downloads*

You can download WSO2 BAM release artifacts from
http://wso2.com/products/business-activity-monitor/.

*How to Run?*


   1. Download the binary distribution zip file
   2. Extract the downloaded zip file
   3. Go to the *bin* directory in the extracted folder
   4. On Linux/Unix, run wso2server.sh script. On Microsoft Windows, run
   wso2server.bat file.
   5. Point your browser to the URL https://localhost:9443/carbon
6. Use username admin, and password admin to login as the
   administrator.
   NOTE: It is strongly recommended that you change your administrator
   password from the admin to a more secure one at this point. To do this
   click on 'Configure->User Managment' link on the left menu.

For more information, please see the WSO2 Business Activity Monitor
Documentation

*Fixed **Issues in this release*

WSO2 BAM 2.4.1 Fixed Issues 

*Known Issues in this release*

WSO2 BAM 2.4.1 Known Issues 

*Engaging with Community*

*Mailing Lists*

Join our mailing list and correspond with the developers directly.

Developer List : dev@wso2.org | Subscribe  | Mail
Archive 

*Reporting Issues*

WSO2 encourages you to report issues, enhancements and feature requests for
WSO2 BAM. Use the issue tracker  for
reporting issues.

*Discussion Forums*

We encourage to use stackoverflow  to
engage with developers as well as other users.

*Training*

WSO2 Inc. offers a variety of professional Training Programs, including
training on general Web services as well as WSO2 Business Activity Monitor
and number of other products. For additional support information please
refer to

*Support*

We are committed to ensuring that your enterprise middleware deployment is
completely supported from evaluation to production. Our unique approach
ensures that all support leverages our open development methodology and is
provided by the very same engineers who build the technology.

For additional support information please refer to http://wso2.com/support/

We welcome your feedback and would love to hear your thoughts on t

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Anjana Fernando]

Hi,

Yeah, +1, lets anyway fix it in patch0007.

Cheers,
Anjana.


On Wed, May 7, 2014 at 1:20 PM, Isuru Udana  wrote:

> Hi Anjana,
>
>
> On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:
>
>> Hi Manoj,
>>
>> So this is a bug that can affect DSS too? .. if so, we have to patch in
>> 0007 itself.
>>
> This is only affecting for non blocking transports (ptt/nio). So DSS will
> not get affected by this.
> However IMO we need to revert this in Patch0007 as it is not good to
> release a kernel patch with a serious bug.
>
>
>>
>> Cheers,
>> Anjana.
>>
>>
>>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>>
>>> Hi Nuwan,
>>>
>>> currently patch0007 is breezed due to due to DSS release. I'll revert
>>> this after talking to DSS team.
>>>
>>> Thanks,
>>> Manoj
>>>
>>>
>>> *Manoj Kumara*
>>> Software Engineer
>>> WSO2 Inc. http://wso2.com/
>>> *lean.enterprise.middleware*
>>> Mobile: +94713448188
>>>
>>>
>>> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>>>
 Hi Charitha,

 We figured out that this had been a regression due to a kernel patch -
 patch0007. Commit revision is r200946. Thanks IsuruU for the
 assistance.

 @Manoj, please revert this patch urgently since it causes a 202
 Accepted to be sent for all tenant requests and drops the response body.

 Thanks,
 NuwanD.


 On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge 
 wrote:

> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
> Verified the jiras.
>  However, there is a critical MT failure which can be reproduced in a
> fresh pack as well.
>
> When you invoke an API in a tenant, the response is not returned.
> Given below is the wire log. As you can see, the response is not sent 
> back.
> Client always gets http 202 acknowledgement instead of the actual 
> response.
> Basically MT is broken.
>
> Note that the same API works with the same backend in super tenant
> mode. So this must be a MT regression.
>
> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
> gzip,deflate[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
> text/xml;charset=UTF-8[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
> "urn:echoString"[\r][\n]"
> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
> 4636d529ea62b726e312a53794dccf36[\r
> ][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280
> [\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
> [2014-05-07 03:25:31,898] DEBUG - wire >> " xmlns:soapenv="http://schemas.xmlsoap.o
> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org
> ">[\r][\n]"
>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>  [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,900] DEBUG - wire >> "
> test[\r][\n]"
> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>  [\r][\n]"
> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
> local://axis2services/axis2API/v1, WSAction: urn:e
> choString, SOAPAction: urn:echoString, MessageID:
> urn:uuid:AE969D38832DDA67D11399413331911, Directio
> n: request, Envelope:  encoding="utf-8"?>http://service.carbon.wso2.org";>
>   
>  
>  test
>   
>
> [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
> HTTP/1.1[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
> gzip,deflate[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
> text/xml;charset=UTF-8[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
> "urn:echoString"[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
> chunked[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Host:
> localhost:9764[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Connection:
> Keep-Alive[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
> Synapse-PT-HttpComponents-NIO[\r][\n]"
> [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202
> Accepted[\r][\n]"
> [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
> 21:55:31 GMT[\r][\n]"

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Isuru Udana]

Hi Anjana,


On Wed, May 7, 2014 at 1:12 PM, Anjana Fernando  wrote:

> Hi Manoj,
>
> So this is a bug that can affect DSS too? .. if so, we have to patch in
> 0007 itself.
>
This is only affecting for non blocking transports (ptt/nio). So DSS will
not get affected by this.
However IMO we need to revert this in Patch0007 as it is not good to
release a kernel patch with a serious bug.


>
> Cheers,
> Anjana.
>
>
>  On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>
>> Hi Nuwan,
>>
>> currently patch0007 is breezed due to due to DSS release. I'll revert
>> this after talking to DSS team.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>>
>>> Hi Charitha,
>>>
>>> We figured out that this had been a regression due to a kernel patch -
>>> patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.
>>>
>>> @Manoj, please revert this patch urgently since it causes a 202 Accepted
>>> to be sent for all tenant requests and drops the response body.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>>
>>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge 
>>> wrote:
>>>
 ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
 Verified the jiras.
  However, there is a critical MT failure which can be reproduced in a
 fresh pack as well.

 When you invoke an API in a tenant, the response is not returned. Given
 below is the wire log. As you can see, the response is not sent back.
 Client always gets http 202 acknowledgement instead of the actual response.
 Basically MT is broken.

 Note that the same API works with the same backend in super tenant
 mode. So this must be a MT regression.

 [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
 superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
 [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
 [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
 gzip,deflate[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
 text/xml;charset=UTF-8[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
 "urn:echoString"[\r][\n]"
 [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
 4636d529ea62b726e312a53794dccf36[\r
 ][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
 Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
 [2014-05-07 03:25:31,898] DEBUG - wire >> ">>> xmlns:soapenv="http://schemas.xmlsoap.o
 rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
  [2014-05-07 03:25:31,898] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
 test[\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> ""
 [2014-05-07 03:25:31,917]  INFO - LogMediator To:
 local://axis2services/axis2API/v1, WSAction: urn:e
 choString, SOAPAction: urn:echoString, MessageID:
 urn:uuid:AE969D38832DDA67D11399413331911, Directio
 n: request, Envelope: >>> encoding="utf-8"?>http://service.carbon.wso2.org";>
   
  
  test
   

 [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
 HTTP/1.1[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
 gzip,deflate[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
 text/xml;charset=UTF-8[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
 "urn:echoString"[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
 chunked[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Connection:
 Keep-Alive[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
 Synapse-PT-HttpComponents-NIO[\r][\n]"
 [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202
 Accepted[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
 21:55:31 GMT[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
 WSO2-PassThrough-HTTP[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
 chunked[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
 [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: c

Re: [Dev] Moving databridge components to a separate git repository

[Gihan Anuruddha]

Hi Kasun,

No, not always.  We can do changes that backward compatible way like we did
in our last BAM 2.4.1 release. Even though might need to add improvements
frequently to these client components.

Regards,
Gihan


On Wed, May 7, 2014 at 12:59 PM, Kasun Gajasinghe  wrote:

> Hi Gihan,
>
>
> On Wed, May 7, 2014 at 11:23 AM, Gihan Anuruddha  wrote:
>
>> Hi Rajeev,
>>
>>  We can divide databridge components into a two separate parts as server
>> and client.  AFAIK at the moment server part only used by BAM and CEP. But
>> I think client part might need to all other wso2 products since we are
>> going to create toolboxes for all of them.  So IMHO is we can keep those
>> client components in the carbon-commons and we can create separate git
>> repo for the databridge server related components.
>>
>
> When you change the data-bridge server/receiver, you will also have to
> modify the clients appropriately, right? Therefore, I think it's better
> keep all in one place. And, I'm -1 to keep any data-bridge components in
> carbon-commons. Carbon-commons is not the place to keep components that
> changes frequently. It's for components like soap-tracer, wsdl2code etc.
> that hardly get any commit.
>
> I'm +1 to create a new repo to keep the data-bridge components. There
> around 11 data-bridge components as I see.
>
> Regards,
> KasunG
>
>
>>
>> WDYT?
>>
>> Regards,
>> Gihan
>>
>>
>> On Wed, May 7, 2014 at 10:56 AM, Rajeev Sampath  wrote:
>>
>>> Hi,
>>>
>>> Currently part of the data-bridge (core components) are in
>>> carbon-commons and the rest is in carbon-analytics. However there are
>>> arguments that carbon-commons is not the right place to have these
>>> data-bridge components.
>>>
>>> Completely moving this to carbon-analytics doesn't seem to be a good
>>> option either since quite a few products depend on this and they will have
>>> to wait for a carbon-analytics release when there are updates.
>>>
>>> Do we need a separate git repo for data-bridge? Or else a better place
>>> to move this?
>>>
>>>
>>> Thanks
>>> Rajeev
>>>
>>> --
>>> Rajeev Sampath
>>> Senior Software Engineer
>>> WSO2, Inc.; http://www.wso2.com.
>>>
>>> Mobile:
>>> * +94716265766 <%2B94716265766>*
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> W.G. Gihan Anuruddha
>>
>> Senior Software Engineer | WSO2, Inc.
>> M: +94772272595
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
>
>
>



-- 
W.G. Gihan Anuruddha
Senior Software Engineer | WSO2, Inc.
M: +94772272595
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Anjana Fernando]

Hi Manoj,

So this is a bug that can affect DSS too? .. if so, we have to patch in
0007 itself.

Cheers,
Anjana.


On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:

> Hi Nuwan,
>
> currently patch0007 is breezed due to due to DSS release. I'll revert this
> after talking to DSS team.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>
>> Hi Charitha,
>>
>> We figured out that this had been a regression due to a kernel patch -
>> patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.
>>
>> @Manoj, please revert this patch urgently since it causes a 202 Accepted
>> to be sent for all tenant requests and drops the response body.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge wrote:
>>
>>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>>> Verified the jiras.
>>>  However, there is a critical MT failure which can be reproduced in a
>>> fresh pack as well.
>>>
>>> When you invoke an API in a tenant, the response is not returned. Given
>>> below is the wire log. As you can see, the response is not sent back.
>>> Client always gets http 202 acknowledgement instead of the actual response.
>>> Basically MT is broken.
>>>
>>> Note that the same API works with the same backend in super tenant mode.
>>> So this must be a MT regression.
>>>
>>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>>> 4636d529ea62b726e312a53794dccf36[\r
>>> ][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>>> [2014-05-07 03:25:31,898] DEBUG - wire >> ">> xmlns:soapenv="http://schemas.xmlsoap.o
>>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
>>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>> test[\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>>> local://axis2services/axis2API/v1, WSAction: urn:e
>>> choString, SOAPAction: urn:echoString, MessageID:
>>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>>> n: request, Envelope: >> encoding="utf-8"?>http://service.carbon.wso2.org";>
>>>   
>>>  
>>>  test
>>>   
>>>
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
>>> HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
>>> chunked[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Connection:
>>> Keep-Alive[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
>>> Synapse-PT-HttpComponents-NIO[\r][\n]"
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202 Accepted[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
>>> 21:55:31 GMT[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
>>> WSO2-PassThrough-HTTP[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
>>> chunked[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "161[\r][\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << ">> encoding="UTF-8"?>>> mlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ser="
>>> http://service.carbon.wso2.org";>
>>> [\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << "
>>> [\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << "  

Re: [Dev] Kernel commit in user core

[Manoj Kumara]

Hi Asela,

Fix [1] contain public API additions and [2] adds new property to
user-mgt.xml file. Can you please check the diff.

Thanks,
Manoj


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 3:19 AM, Asela Pathberiya  wrote:

> Hi Manoj,
>
> Please commit following attached patches to kernel..
>
> [1] https://wso2.org/jira/browse/CARBON-14769
> [2] https://wso2.org/jira/browse/IDENTITY-2281
>
> Thanks,
> Asela.
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Manoj Kumara]

Sure, Will add this to patch0008.


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 12:50 PM, Nuwan Dias  wrote:

> Ok, then we have to apply the revert to patch0008.
>
>
> On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:
>
>> Hi Nuwan,
>>
>> currently patch0007 is breezed due to due to DSS release. I'll revert
>> this after talking to DSS team.
>>
>> Thanks,
>> Manoj
>>
>>
>> *Manoj Kumara*
>> Software Engineer
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94713448188
>>
>>
>> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>>
>>> Hi Charitha,
>>>
>>> We figured out that this had been a regression due to a kernel patch -
>>> patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.
>>>
>>> @Manoj, please revert this patch urgently since it causes a 202 Accepted
>>> to be sent for all tenant requests and drops the response body.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>>
>>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge 
>>> wrote:
>>>
 ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
 Verified the jiras.
  However, there is a critical MT failure which can be reproduced in a
 fresh pack as well.

 When you invoke an API in a tenant, the response is not returned. Given
 below is the wire log. As you can see, the response is not sent back.
 Client always gets http 202 acknowledgement instead of the actual response.
 Basically MT is broken.

 Note that the same API works with the same backend in super tenant
 mode. So this must be a MT regression.

 [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
 superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
 [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
 [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
 gzip,deflate[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
 text/xml;charset=UTF-8[\r][\n]"
 [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
 "urn:echoString"[\r][\n]"
 [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
 4636d529ea62b726e312a53794dccf36[\r
 ][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
 [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
 Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
 [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
 [2014-05-07 03:25:31,898] DEBUG - wire >> ">>> xmlns:soapenv="http://schemas.xmlsoap.o
 rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
  [2014-05-07 03:25:31,898] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,899] DEBUG - wire >> "
 [\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
 test[\r][\n]"
 [2014-05-07 03:25:31,900] DEBUG - wire >> "
  [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
 [2014-05-07 03:25:31,901] DEBUG - wire >> ""
 [2014-05-07 03:25:31,917]  INFO - LogMediator To:
 local://axis2services/axis2API/v1, WSAction: urn:e
 choString, SOAPAction: urn:echoString, MessageID:
 urn:uuid:AE969D38832DDA67D11399413331911, Directio
 n: request, Envelope: >>> encoding="utf-8"?>http://service.carbon.wso2.org";>
   
  
  test
   

 [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
 HTTP/1.1[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
 gzip,deflate[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
 text/xml;charset=UTF-8[\r][\n]"
 [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
 "urn:echoString"[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
 chunked[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "Connection:
 Keep-Alive[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
 Synapse-PT-HttpComponents-NIO[\r][\n]"
 [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202
 Accepted[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
 21:55:31 GMT[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
 WSO2-PassThrough-HTTP[\r][\n]"
 [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
 chunked[\r][\n]"
 [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
 [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: close[\r][\n]"
 [2014-05-07 03:25:31,933] DEBUG - wire << "[\r][\n]"
 [2014-05-07 03:25:31,933] DEBUG - wire << "161[\r][\n]"
 [2014-05-07 03:25:31

Re: [Dev] Moving databridge components to a separate git repository

[Kasun Gajasinghe]

Hi Gihan,


On Wed, May 7, 2014 at 11:23 AM, Gihan Anuruddha  wrote:

> Hi Rajeev,
>
> We can divide databridge components into a two separate parts as server
> and client.  AFAIK at the moment server part only used by BAM and CEP. But
> I think client part might need to all other wso2 products since we are
> going to create toolboxes for all of them.  So IMHO is we can keep those
> client components in the carbon-commons and we can create separate git
> repo for the databridge server related components.
>

When you change the data-bridge server/receiver, you will also have to
modify the clients appropriately, right? Therefore, I think it's better
keep all in one place. And, I'm -1 to keep any data-bridge components in
carbon-commons. Carbon-commons is not the place to keep components that
changes frequently. It's for components like soap-tracer, wsdl2code etc.
that hardly get any commit.

I'm +1 to create a new repo to keep the data-bridge components. There
around 11 data-bridge components as I see.

Regards,
KasunG


>
> WDYT?
>
> Regards,
> Gihan
>
>
> On Wed, May 7, 2014 at 10:56 AM, Rajeev Sampath  wrote:
>
>> Hi,
>>
>> Currently part of the data-bridge (core components) are in carbon-commons
>> and the rest is in carbon-analytics. However there are arguments that
>> carbon-commons is not the right place to have these data-bridge components.
>>
>> Completely moving this to carbon-analytics doesn't seem to be a good
>> option either since quite a few products depend on this and they will have
>> to wait for a carbon-analytics release when there are updates.
>>
>> Do we need a separate git repo for data-bridge? Or else a better place to
>> move this?
>>
>>
>> Thanks
>> Rajeev
>>
>> --
>> Rajeev Sampath
>> Senior Software Engineer
>> WSO2, Inc.; http://www.wso2.com.
>>
>> Mobile:
>> * +94716265766 <%2B94716265766>*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> W.G. Gihan Anuruddha
>
> Senior Software Engineer | WSO2, Inc.
> M: +94772272595
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

*Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] DSS 3.2.0 - Boxcarring Sample

[Firzhan Naqash]

Hi,

*When I was trying to run the Boxcarring Sample of DSS 3.2.0, I encountered
with the following error*. The same error has been reported in the JIRA
issues [1] and [2].


As per jira comment [2] are there any way to increase the session timeout
by means of configuration.


Error Stack
===

[2014-05-07 12:32:48,979] ERROR {org.wso2.carbon.statistics.
ui.StatisticsAdminClient} -  Cannot get service stats for service
samples/RDBMSSample. Backend server may be unavailable.
org.apache.axis2.AxisFault: The input stream for an incoming message is
null.
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:93)
at
org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:68)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:348)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:445)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:225)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
at
org.wso2.carbon.statistics.stub.StatisticsAdminStub.getServiceStatistics(StatisticsAdminStub.java:3893)
at
org.wso2.carbon.statistics.ui.StatisticsAdminClient.getServiceStatistics(StatisticsAdminClient.java:77)
at
org.apache.jsp.statistics.service_005fstats_005fajaxprocessor_jsp._jspService(org.apache.jsp.statistics.service_005fstats_005fajaxprocessor_jsp:107)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.wso2.carbon.ui.JspServlet.service(JspServlet.java:155)
at org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at
org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37)
at
org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
at
org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at
org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:68)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.wso2.carbon.tomcat.ext.filter.CharacterSetFilter.doFilter(CharacterSetFilter.java:61)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.wso2.carbon.tomcat.ext.valves.CompositeValve.continueInvocation(CompositeValve.java:178)
at
org.wso2.carbon.tomcat.ext.valves.TomcatValveContainer.invokeValves(TomcatValveContainer.java:49)
at
org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:141)
at
org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:156)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at
org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:52)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)



[1] https://wso2.org/jira

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Nuwan Dias]

Ok, then we have to apply the revert to patch0008.


On Wed, May 7, 2014 at 12:44 PM, Manoj Kumara  wrote:

> Hi Nuwan,
>
> currently patch0007 is breezed due to due to DSS release. I'll revert this
> after talking to DSS team.
>
> Thanks,
> Manoj
>
>
> *Manoj Kumara*
> Software Engineer
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94713448188
>
>
> On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:
>
>> Hi Charitha,
>>
>> We figured out that this had been a regression due to a kernel patch -
>> patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.
>>
>> @Manoj, please revert this patch urgently since it causes a 202 Accepted
>> to be sent for all tenant requests and drops the response body.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge wrote:
>>
>>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack.
>>> Verified the jiras.
>>>  However, there is a critical MT failure which can be reproduced in a
>>> fresh pack as well.
>>>
>>> When you invoke an API in a tenant, the response is not returned. Given
>>> below is the wire log. As you can see, the response is not sent back.
>>> Client always gets http 202 acknowledgement instead of the actual response.
>>> Basically MT is broken.
>>>
>>> Note that the same API works with the same backend in super tenant mode.
>>> So this must be a MT regression.
>>>
>>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>>> 4636d529ea62b726e312a53794dccf36[\r
>>> ][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
>>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>>> [2014-05-07 03:25:31,898] DEBUG - wire >> ">> xmlns:soapenv="http://schemas.xmlsoap.o
>>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
>>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>>> [\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>> test[\r][\n]"
>>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>>  [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
>>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>>> local://axis2services/axis2API/v1, WSAction: urn:e
>>> choString, SOAPAction: urn:echoString, MessageID:
>>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>>> n: request, Envelope: >> encoding="utf-8"?>http://service.carbon.wso2.org";>
>>>   
>>>  
>>>  test
>>>   
>>>
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
>>> HTTP/1.1[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>>> gzip,deflate[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>>> text/xml;charset=UTF-8[\r][\n]"
>>> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
>>> "urn:echoString"[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
>>> chunked[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "Connection:
>>> Keep-Alive[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
>>> Synapse-PT-HttpComponents-NIO[\r][\n]"
>>> [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202 Accepted[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
>>> 21:55:31 GMT[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
>>> WSO2-PassThrough-HTTP[\r][\n]"
>>> [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
>>> chunked[\r][\n]"
>>> [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: close[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "[\r][\n]"
>>> [2014-05-07 03:25:31,933] DEBUG - wire << "161[\r][\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << ">> encoding="UTF-8"?>>> mlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ser="
>>> http://service.carbon.wso2.org";>
>>> [\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << "
>>> [\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << "   [\n]"
>>> [2014-05-07 03:25:31,934] DEBUG - wire << "  [\

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Manoj Kumara]

Hi Nuwan,

currently patch0007 is breezed due to due to DSS release. I'll revert this
after talking to DSS team.

Thanks,
Manoj


*Manoj Kumara*
Software Engineer
WSO2 Inc. http://wso2.com/
*lean.enterprise.middleware*
Mobile: +94713448188


On Wed, May 7, 2014 at 12:27 PM, Nuwan Dias  wrote:

> Hi Charitha,
>
> We figured out that this had been a regression due to a kernel patch -
> patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.
>
> @Manoj, please revert this patch urgently since it causes a 202 Accepted
> to be sent for all tenant requests and drops the response body.
>
> Thanks,
> NuwanD.
>
>
> On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge wrote:
>
>> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack. Verified
>> the jiras.
>>  However, there is a critical MT failure which can be reproduced in a
>> fresh pack as well.
>>
>> When you invoke an API in a tenant, the response is not returned. Given
>> below is the wire log. As you can see, the response is not sent back.
>> Client always gets http 202 acknowledgement instead of the actual response.
>> Basically MT is broken.
>>
>> Note that the same API works with the same backend in super tenant mode.
>> So this must be a MT regression.
>>
>> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST /t/
>> superqa.com/axis2API/v1 HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
>> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
>> 4636d529ea62b726e312a53794dccf36[\r
>> ][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
>> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
>> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
>> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
>> [2014-05-07 03:25:31,898] DEBUG - wire >> "> xmlns:soapenv="http://schemas.xmlsoap.o
>> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
>>  [2014-05-07 03:25:31,898] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "  [\r][\n]"
>> [2014-05-07 03:25:31,899] DEBUG - wire >> "
>> [\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>> test[\r][\n]"
>> [2014-05-07 03:25:31,900] DEBUG - wire >> "
>>  [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
>> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
>> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
>> local://axis2services/axis2API/v1, WSAction: urn:e
>> choString, SOAPAction: urn:echoString, MessageID:
>> urn:uuid:AE969D38832DDA67D11399413331911, Directio
>> n: request, Envelope: > encoding="utf-8"?>http://service.carbon.wso2.org";>
>>   
>>  
>>  test
>>   
>>
>> [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
>> HTTP/1.1[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
>> gzip,deflate[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
>> text/xml;charset=UTF-8[\r][\n]"
>> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
>> "urn:echoString"[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
>> chunked[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "Connection: Keep-Alive[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
>> Synapse-PT-HttpComponents-NIO[\r][\n]"
>> [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202 Accepted[\r][\n]"
>> [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014
>> 21:55:31 GMT[\r][\n]"
>> [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
>> WSO2-PassThrough-HTTP[\r][\n]"
>> [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
>> chunked[\r][\n]"
>> [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
>> [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: close[\r][\n]"
>> [2014-05-07 03:25:31,933] DEBUG - wire << "[\r][\n]"
>> [2014-05-07 03:25:31,933] DEBUG - wire << "161[\r][\n]"
>> [2014-05-07 03:25:31,934] DEBUG - wire << "> encoding="UTF-8"?>> mlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ser="
>> http://service.carbon.wso2.org";>
>> [\n]"
>> [2014-05-07 03:25:31,934] DEBUG - wire << "
>> [\n]"
>> [2014-05-07 03:25:31,934] DEBUG - wire << "   [\n]"
>> [2014-05-07 03:25:31,934] DEBUG - wire << "  [\n]"
>> [2014-05-07 03:25:31,934] DEBUG - wire << "0[\r][\n]"
>> [2014-05-07 03:25:31,935] DEBUG - wire << "[\r][\n]"
>> [2014-05-07 03:25:31,935] DEBUG - wire << " [\n]"
>> [2014-05-07 03:25:31,935] DEBUG - wire << "
>> test[\n]"
>> [2014

Re: [Dev] API Manager 1.7.0 & ELB-2.1.1 nightly build packs 06-05-2014

[Nuwan Dias]

Hi Charitha,

We figured out that this had been a regression due to a kernel patch -
patch0007. Commit revision is r200946. Thanks IsuruU for the assistance.

@Manoj, please revert this patch urgently since it causes a 202 Accepted to
be sent for all tenant requests and drops the response body.

Thanks,
NuwanD.


On Wed, May 7, 2014 at 3:53 AM, Charitha Kankanamge wrote:

> ​Thanks Sanjeewa. MSSQL related blockers are fixed in this pack. Verified
> the jiras.
> However, there is a critical MT failure which can be reproduced in a fresh
> pack as well.
>
> When you invoke an API in a tenant, the response is not returned. Given
> below is the wire log. As you can see, the response is not sent back.
> Client always gets http 202 acknowledgement instead of the actual response.
> Basically MT is broken.
>
> Note that the same API works with the same backend in super tenant mode.
> So this must be a MT regression.
>
> [2014-05-07 03:25:31,891] DEBUG - wire >> "POST 
> /t/superqa.com/axis2API/v1HTTP/1.1[\r][\n]"
> [2014-05-07 03:25:31,892] DEBUG - wire >> "Connection: close[\r][\n]"
> [2014-05-07 03:25:31,893] DEBUG - wire >> "Accept-Encoding:
> gzip,deflate[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "Content-Type:
> text/xml;charset=UTF-8[\r][\n]"
> [2014-05-07 03:25:31,894] DEBUG - wire >> "SOAPAction:
> "urn:echoString"[\r][\n]"
> [2014-05-07 03:25:31,895] DEBUG - wire >> "Authorization: Bearer
> 4636d529ea62b726e312a53794dccf36[\r
> ][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Content-Length: 307[\r][\n]"
> [2014-05-07 03:25:31,896] DEBUG - wire >> "Host: 10.0.0.2:8280[\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "User-Agent:
> Apache-HttpClient/4.1.1 (java 1.5)[\r][\n]"
> [2014-05-07 03:25:31,897] DEBUG - wire >> "[\r][\n]"
> [2014-05-07 03:25:31,898] DEBUG - wire >> " xmlns:soapenv="http://schemas.xmlsoap.o
> rg/soap/envelope/" xmlns:ser="http://service.carbon.wso2.org";>[\r][\n]"
> [2014-05-07 03:25:31,898] DEBUG - wire >> "   [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "   [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "  [\r][\n]"
> [2014-05-07 03:25:31,899] DEBUG - wire >> "
> [\r][\n]"
> [2014-05-07 03:25:31,900] DEBUG - wire >> "
> test[\r][\n]"
> [2014-05-07 03:25:31,900] DEBUG - wire >> "  [\r][\n]"
> [2014-05-07 03:25:31,901] DEBUG - wire >> "   [\r][\n]"
> [2014-05-07 03:25:31,901] DEBUG - wire >> ""
> [2014-05-07 03:25:31,917]  INFO - LogMediator To:
> local://axis2services/axis2API/v1, WSAction: urn:e
> choString, SOAPAction: urn:echoString, MessageID:
> urn:uuid:AE969D38832DDA67D11399413331911, Directio
> n: request, Envelope:  encoding="utf-8"?>http://service.carbon.wso2.org";>
>   
>  
>  test
>   
>
> [2014-05-07 03:25:31,929] DEBUG - wire << "POST /services/Axis2Service
> HTTP/1.1[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "Accept-Encoding:
> gzip,deflate[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "Content-Type:
> text/xml;charset=UTF-8[\r][\n]"
> [2014-05-07 03:25:31,930] DEBUG - wire << "SOAPAction:
> "urn:echoString"[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Transfer-Encoding:
> chunked[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Host: localhost:9764[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "Connection: Keep-Alive[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "User-Agent:
> Synapse-PT-HttpComponents-NIO[\r][\n]"
> [2014-05-07 03:25:31,929] DEBUG - wire << "HTTP/1.1 202 Accepted[\r][\n]"
> [2014-05-07 03:25:31,932] DEBUG - wire << "Date: Tue, 06 May 2014 21:55:31
> GMT[\r][\n]"
> [2014-05-07 03:25:31,932] DEBUG - wire << "Server:
> WSO2-PassThrough-HTTP[\r][\n]"
> [2014-05-07 03:25:31,932] DEBUG - wire << "Transfer-Encoding:
> chunked[\r][\n]"
> [2014-05-07 03:25:31,931] DEBUG - wire << "[\r][\n]"
> [2014-05-07 03:25:31,933] DEBUG - wire << "Connection: close[\r][\n]"
> [2014-05-07 03:25:31,933] DEBUG - wire << "[\r][\n]"
> [2014-05-07 03:25:31,933] DEBUG - wire << "161[\r][\n]"
> [2014-05-07 03:25:31,934] DEBUG - wire << " encoding="UTF-8"?> mlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ser="
> http://service.carbon.wso2.org";>
> [\n]"
> [2014-05-07 03:25:31,934] DEBUG - wire << "
> [\n]"
> [2014-05-07 03:25:31,934] DEBUG - wire << "   [\n]"
> [2014-05-07 03:25:31,934] DEBUG - wire << "  [\n]"
> [2014-05-07 03:25:31,934] DEBUG - wire << "0[\r][\n]"
> [2014-05-07 03:25:31,935] DEBUG - wire << "[\r][\n]"
> [2014-05-07 03:25:31,935] DEBUG - wire << " [\n]"
> [2014-05-07 03:25:31,935] DEBUG - wire << "
> test[\n]"
> [2014-05-07 03:25:31,936] DEBUG - wire << "  [\n]"
> [2014-05-07 03:25:31,936] DEBUG - wire << "   [\n]"
> [2014-05-07 03:25:31,936] DEBUG - wire << "[\r][\n]"
> [2014-05-07 03:25:31,936] DEBUG - wire << "0[\r][\n]"
> [2014-05-07 03:25:31,936] DEBUG - wire << "[\r][\n]"
> [2014-05-07 03:25:31,991] DEBUG - wire >> "HTTP/1.1 200 OK[\r][\n]"
> [2014-05-07 03:25:32,008] DEBUG - wire >> "Content-Type:
> text/xml;cha