[Dev] Commit to Kernel patch 0008

[Johann Nallathamby]

Hi,

Please find patch attached at [1].

[1] *https://wso2.org/jira/browse/IDENTITY-2334
*

-- 
Thanks & Regards,

*Johann Dilantha Nallathamby*
Associate Technical Lead
Integration Technologies Team
WSO2, Inc.
lean.enterprise.middleware

Mobile - *+9476950*
Blog - *http://nallaa.wordpress.com *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Gitblit is added as a dependency

[Ranga Siriwardena]

Hi All,

$Subject. Added the required dependency and orbit bundle to solve the
AppFactory product build.

Thank You.
Ranga.

-- 
Ranga Siriwardena
Software Engineer
WSO2 Inc.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Value too long for REG_VALUE issue in Registry

[Suresh Attanayaka]

Why are we using registry for this at the first place ?


On Sat, May 10, 2014 at 6:54 AM, Nuwan Dias  wrote:

> On Fri, May 9, 2014 at 9:25 PM, Ajith Vitharana  wrote:
>
>> Hi Uvindra,
>>
>>
>> On Fri, May 9, 2014 at 5:47 PM, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> This limitation was highlighted during the discussion we had with Ajith
>>> just before work on the API Store forum was started. As I mentioned we ran
>>> into the same limitation when developing the development governance
>>> solution. The text area that was to store custom javascript rules could not
>>> accommodate anything exceeding 1000 characters. In the end after discussing
>>> with Senaka we solved the problem by increasing the column size of
>>> REG_VALUE to 5000 and changing the DB scripts that were shipped with the
>>> solution accordingly.
>>>
>>
>> So, what happen when the length is 5001 ? :)
>>
>
> Yes, I think we should someday fix this rxt field to property mapping.
> Otherwise there's no point in having a field called 'text-area' in the rxt
> right? Its capabilities become limited to same as the 'text' field.
> Besides, from a user POV, there's no point in creating a property in the
> rxt for each field. And when you comes across the need to store more than
> 1000 characters in an artifact, you're totally blocked from doing so and
> have to resort to other complicated measures.
>
> So I suggest that we make it a point to fix this urgently when
> appropriate. Kernel 4.3.0 or C5 at least. Sooner the better :)
>
>>
>> Thanks.
>> Ajith.
>>
>>>
>>>
>>> On Fri, May 9, 2014 at 5:29 PM, Nuwan Dias  wrote:
>>>
 Hi Ajith,

 We're developing a forum for the API Store using the registry as the
 storage medium. Each topic/reply is stored in the registry as an artifact.
 Topics/Replies have a rich text editor which supports code blocks, etc.
 This text-area has been mapped to a text-area field in the rxt. So limiting
 the characters to < 1000 is not very feasible in this scenario.

 Are you saying that increasing the column size of REG_VALUE is not a
 good idea?

 Thanks,
 NuwanD.


 On Fri, May 9, 2014 at 5:22 PM, Ajith Vitharana wrote:

> Hi Nuwan,
>
> We store the each filed as properties of the artifacts, that is the
> data model used. Anyway, having the 1000 characters for the given field is
> a special case.
> So, it is not better to increase the default schema to handle this use
> case.
>
> Can't we limit the characters length for that  text-area ?
>
> Thanks.
> Ajith.
>
>
> On Fri, May 9, 2014 at 3:18 PM, Nuwan Dias  wrote:
>
>> Hi,
>>
>> I have an rxt on which I am using a text-area field. However I get
>> the following error if I am to put more that 1000 characters in the 
>> field.
>>
>> org.h2.jdbc.JdbcSQLException: Value too long for column "REG_VALUE
>> VARCHAR(1000)": "STRINGDECODE('> class=\""votecell\"">\n> class=\""vote-count-post \"">2\n... (1107)"; SQL statement:
>> INSERT INTO REG_PROPERTY (REG_NAME, REG_VALUE, REG_TENANT_ID) VALUES
>> (?, ?, ?) [90005-140]
>>
>> The reason for the above problem is due to the fact that each field
>> in the rxt is also saved as a rxt property. The column length in the
>> database for the property value is 1000 characters. Therefore basically 
>> its
>> not possible to have a field in the rxt which is more than 1000 
>> characters
>> long.
>>
>> I see this as a serious limitation. The only possible workaround I
>> see is to increase the column size. Any other solutions to this? Why do 
>> we
>> need to have a property corresponding to each field in the rxt? If we can
>> get rid of that, then we're good IMO.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> Ajith Vitharana.
> WSO2 Inc. - http://wso2.org
> Email  :  aji...@wso2.com
> Mobile : +94772217350
>
>


 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729

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


>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> Ajith Vitharana.
>> WSO2 Inc. - http://wso2.org
>> Email  :  aji...@wso2.com
>> Mobile : +94772217350
>>
>>
>
>
> --
> Nuwan Dias
>
> Associate Tech Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Suresh Attanayake
Senior Softw

Re: [Dev] Value too long for REG_VALUE issue in Registry

[Ajith Vitharana]

Hi Nuwan,


On Sat, May 10, 2014 at 6:54 AM, Nuwan Dias  wrote:

> On Fri, May 9, 2014 at 9:25 PM, Ajith Vitharana  wrote:
>
>> Hi Uvindra,
>>
>>
>> On Fri, May 9, 2014 at 5:47 PM, Uvindra Dias Jayasinha 
>> wrote:
>>
>>> This limitation was highlighted during the discussion we had with Ajith
>>> just before work on the API Store forum was started. As I mentioned we ran
>>> into the same limitation when developing the development governance
>>> solution. The text area that was to store custom javascript rules could not
>>> accommodate anything exceeding 1000 characters. In the end after discussing
>>> with Senaka we solved the problem by increasing the column size of
>>> REG_VALUE to 5000 and changing the DB scripts that were shipped with the
>>> solution accordingly.
>>>
>>
>> So, what happen when the length is 5001 ? :)
>>
>
> Yes, I think we should someday fix this rxt field to property mapping.
> Otherwise there's no point in having a field called 'text-area' in the rxt
> right? Its capabilities become limited to same as the 'text' field.
> Besides, from a user POV, there's no point in creating a property in the
> rxt for each field. And when you comes across the need to store more than
> 1000 characters in an artifact, you're totally blocked from doing so and
> have to resort to other complicated measures.
>
> So I suggest that we make it a point to fix this urgently when
> appropriate. Kernel 4.3.0 or C5 at least. Sooner the better :)
>

As I mentioned early, property is the storage model we used for RXT.
Storing the whole content as XML  (BLOB) and  parsing XML each time is NOT
a solution at all.
Registry schema is a generic one to platform and it can't be change the
with the requirement of all new features. So, what we can do is use the
existing feature combinations to support the new requirement.

If you want to store the large content/doc with artifact, then store that
content as separate resource and build the dependency/association with the
artifacts.

WDYT ?

Thanks.
Ajith.



>
>> Thanks.
>> Ajith.
>>
>>>
>>>
>>> On Fri, May 9, 2014 at 5:29 PM, Nuwan Dias  wrote:
>>>
 Hi Ajith,

 We're developing a forum for the API Store using the registry as the
 storage medium. Each topic/reply is stored in the registry as an artifact.
 Topics/Replies have a rich text editor which supports code blocks, etc.
 This text-area has been mapped to a text-area field in the rxt. So limiting
 the characters to < 1000 is not very feasible in this scenario.

 Are you saying that increasing the column size of REG_VALUE is not a
 good idea?

 Thanks,
 NuwanD.


 On Fri, May 9, 2014 at 5:22 PM, Ajith Vitharana wrote:

> Hi Nuwan,
>
> We store the each filed as properties of the artifacts, that is the
> data model used. Anyway, having the 1000 characters for the given field is
> a special case.
> So, it is not better to increase the default schema to handle this use
> case.
>
> Can't we limit the characters length for that  text-area ?
>
> Thanks.
> Ajith.
>
>
> On Fri, May 9, 2014 at 3:18 PM, Nuwan Dias  wrote:
>
>> Hi,
>>
>> I have an rxt on which I am using a text-area field. However I get
>> the following error if I am to put more that 1000 characters in the 
>> field.
>>
>> org.h2.jdbc.JdbcSQLException: Value too long for column "REG_VALUE
>> VARCHAR(1000)": "STRINGDECODE('> class=\""votecell\"">\n> class=\""vote-count-post \"">2\n... (1107)"; SQL statement:
>> INSERT INTO REG_PROPERTY (REG_NAME, REG_VALUE, REG_TENANT_ID) VALUES
>> (?, ?, ?) [90005-140]
>>
>> The reason for the above problem is due to the fact that each field
>> in the rxt is also saved as a rxt property. The column length in the
>> database for the property value is 1000 characters. Therefore basically 
>> its
>> not possible to have a field in the rxt which is more than 1000 
>> characters
>> long.
>>
>> I see this as a serious limitation. The only possible workaround I
>> see is to increase the column size. Any other solutions to this? Why do 
>> we
>> need to have a property corresponding to each field in the rxt? If we can
>> get rid of that, then we're good IMO.
>>
>> Thanks,
>> NuwanD.
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>
>
> --
> Ajith Vitharana.
> WSO2 Inc. - http://wso2.org
> Email  :  aji...@wso2.com
> Mobile : +94772217350
>
>


 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729

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

[Dev] Serializing a namespace in Bean Mediator

[Sohani Weerasinghe]

Hi All,

When serializing a Bean Mediator in ESB management console, a namespace is
adding in the configuration as shown below


<*axis2ns4*:bean xmlns:axis2ns4="http://ws.apache.org/ns/synapse";
class="ClassA" action="CREATE" var="x" property="property_name"
value="value" target="target">

AFAIK this has occurred due to defining a synapse namespace as shown below,
while creating the OMElement inside the serialize method of the
BeanMediator.

private static final QName BEAN_Q = new
QName(XMLConfigConstants.SYNAPSE_NAMESPACE, "bean");

OMElement beanElem = fac.createOMElement(BEAN_Q);


Instead this can be defined as,

OMElement beanElem = fac.createOMElement("bean", synNS);

Please correct me if this is wrong.

Regards,

Sohani


Sohani Weerasinghe
Software Engineer
WSO2, Inc: http://wso2.com

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

Re: [Dev] Value too long for REG_VALUE issue in Registry

[Senaka Fernando]

Hi all,

I think we are heading in the wrong direction here. IIRC, we discussed to
implement a social component. The UES guys are or will be working on this.
The idea was to keep this outside of the registry. Can you'll chat with
Ruchira as well and try to understand how all of this fits together. The AM
and the ES and the rest of the social aspects have to line up or these will
increasingly become incompatible.

And, WRT Uvindra's case. That solution was a highly subjective one Uvindra.
As Ajith says, we cannot make it a generic solution and be done with that.
This has to be solved properly. But, for the scenario of a forum I don't
think any of that was discussed here is going to work as I have explained
above.

Thanks,
Senaka.


On Sat, May 10, 2014 at 3:37 PM, Ajith Vitharana  wrote:

> Hi Nuwan,
>
>
> On Sat, May 10, 2014 at 6:54 AM, Nuwan Dias  wrote:
>
>>  On Fri, May 9, 2014 at 9:25 PM, Ajith Vitharana  wrote:
>>
>>> Hi Uvindra,
>>>
>>>
>>> On Fri, May 9, 2014 at 5:47 PM, Uvindra Dias Jayasinha >> > wrote:
>>>
 This limitation was highlighted during the discussion we had with Ajith
 just before work on the API Store forum was started. As I mentioned we ran
 into the same limitation when developing the development governance
 solution. The text area that was to store custom javascript rules could not
 accommodate anything exceeding 1000 characters. In the end after discussing
 with Senaka we solved the problem by increasing the column size of
 REG_VALUE to 5000 and changing the DB scripts that were shipped with the
 solution accordingly.

>>>
>>> So, what happen when the length is 5001 ? :)
>>>
>>
>> Yes, I think we should someday fix this rxt field to property mapping.
>> Otherwise there's no point in having a field called 'text-area' in the rxt
>> right? Its capabilities become limited to same as the 'text' field.
>> Besides, from a user POV, there's no point in creating a property in the
>> rxt for each field. And when you comes across the need to store more than
>> 1000 characters in an artifact, you're totally blocked from doing so and
>> have to resort to other complicated measures.
>>
>> So I suggest that we make it a point to fix this urgently when
>> appropriate. Kernel 4.3.0 or C5 at least. Sooner the better :)
>>
>
> As I mentioned early, property is the storage model we used for RXT.
> Storing the whole content as XML  (BLOB) and  parsing XML each time is NOT
> a solution at all.
> Registry schema is a generic one to platform and it can't be change the
> with the requirement of all new features. So, what we can do is use the
> existing feature combinations to support the new requirement.
>
> If you want to store the large content/doc with artifact, then store that
> content as separate resource and build the dependency/association with the
> artifacts.
>
> WDYT ?
>
> Thanks.
> Ajith.
>
>
>
>>
>>> Thanks.
>>> Ajith.
>>>


 On Fri, May 9, 2014 at 5:29 PM, Nuwan Dias  wrote:

> Hi Ajith,
>
> We're developing a forum for the API Store using the registry as the
> storage medium. Each topic/reply is stored in the registry as an artifact.
> Topics/Replies have a rich text editor which supports code blocks, etc.
> This text-area has been mapped to a text-area field in the rxt. So 
> limiting
> the characters to < 1000 is not very feasible in this scenario.
>
> Are you saying that increasing the column size of REG_VALUE is not a
> good idea?
>
> Thanks,
> NuwanD.
>
>
> On Fri, May 9, 2014 at 5:22 PM, Ajith Vitharana wrote:
>
>> Hi Nuwan,
>>
>> We store the each filed as properties of the artifacts, that is the
>> data model used. Anyway, having the 1000 characters for the given field 
>> is
>> a special case.
>> So, it is not better to increase the default schema to handle this
>> use case.
>>
>> Can't we limit the characters length for that  text-area ?
>>
>> Thanks.
>> Ajith.
>>
>>
>> On Fri, May 9, 2014 at 3:18 PM, Nuwan Dias  wrote:
>>
>>> Hi,
>>>
>>> I have an rxt on which I am using a text-area field. However I get
>>> the following error if I am to put more that 1000 characters in the 
>>> field.
>>>
>>> org.h2.jdbc.JdbcSQLException: Value too long for column "REG_VALUE
>>> VARCHAR(1000)": "STRINGDECODE('>> class=\""votecell\"">\n>> class=\""vote-count-post \"">2\n... (1107)"; SQL statement:
>>> INSERT INTO REG_PROPERTY (REG_NAME, REG_VALUE, REG_TENANT_ID) VALUES
>>> (?, ?, ?) [90005-140]
>>>
>>> The reason for the above problem is due to the fact that each field
>>> in the rxt is also saved as a rxt property. The column length in the
>>> database for the property value is 1000 characters. Therefore basically 
>>> its
>>> not possible to have a field in the rxt which is more than 1000 
>>> characters
>>> long.
>

Re: [Dev] [Private PaaS] Can't Spawn any instances

[Melan Nimesh]

This issue is no longer there in the master branch,  Thanks for the fix

On Sat, May 10, 2014 at 12:06 AM, Melan Nimesh  wrote:

> Hi All,
>
> I noticed the $subject in packs from master branch , I am getting
> following error [1] . Did we made any changes to rule files recenlty?
>
> [1]
>
> TID: [0] [STRATOS] [2014-05-09 23:46:00,093] ERROR
> {org.apache.stratos.autoscaler.monitor.LbClusterMonitor} -  Cluster
> monitor: Monitor failed. LbClusterMonitor [clusterId=lbisuruh.lk.domain,
> serviceId=lb] {org.apache.stratos.autoscaler.monitor.LbClusterMonitor}
> Exception executing consequence for rule "Minimum Rule" in
> org.apache.stratos.autoscaler.rule: [Error: null]
> [Near : {... $delegator.delegateSpawn($ctxt }]
>  ^
> [Line: 1, Column: 1]
> at
> org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> at
> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1297)
> at
> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> at
> org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> at
> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> at
> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
> at
> org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
> at
> org.apache.stratos.autoscaler.rule.AutoscalerRuleEvaluator.evaluateMinCheck(AutoscalerRuleEvaluator.java:86)
> at
> org.apache.stratos.autoscaler.monitor.LbClusterMonitor.monitor(LbClusterMonitor.java:91)
> at
> org.apache.stratos.autoscaler.monitor.LbClusterMonitor.run(LbClusterMonitor.java:63)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: [Error: null]
> [Near : {... $delegator.delegateSpawn($ctxt }]
>  ^
> [Line: 1, Column: 1]
> at
> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:435)
> at
> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
> at
> org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
> at
> org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
> at
> org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
> at
> org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
> at
> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> ... 9 more
> Caused by: java.lang.IllegalArgumentException
> 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.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1104)
> at
> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
> at
> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
> ... 19 more
>
>
> Thanks,
> Melan
>
> --
> *Melan Nimesh*
> Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: melan AT wso2.com;
> Mobile: +94 77 631 6759
>
>


-- 
*Melan Nimesh*
Software Engineer;
WSO2 Inc.;  http://wso2.org
E-mail: melan AT wso2.com;
Mobile: +94 77 631 6759
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Private PaaS] Can't Spawn any instances

[Sajith Kariyawasam]

Hi Melan,

The above issue was due to a change I did for the rule file while adding
clustering support to private paas. Now I have fixed that issue.

Thanks,
Sajith


On Sat, May 10, 2014 at 10:29 PM, Melan Nimesh  wrote:

>
> This issue is no longer there in the master branch,  Thanks for the fix
>
>
> On Sat, May 10, 2014 at 12:06 AM, Melan Nimesh  wrote:
>
>> Hi All,
>>
>> I noticed the $subject in packs from master branch , I am getting
>> following error [1] . Did we made any changes to rule files recenlty?
>>
>> [1]
>>
>> TID: [0] [STRATOS] [2014-05-09 23:46:00,093] ERROR
>> {org.apache.stratos.autoscaler.monitor.LbClusterMonitor} -  Cluster
>> monitor: Monitor failed. LbClusterMonitor [clusterId=lbisuruh.lk.domain,
>> serviceId=lb] {org.apache.stratos.autoscaler.monitor.LbClusterMonitor}
>> Exception executing consequence for rule "Minimum Rule" in
>> org.apache.stratos.autoscaler.rule: [Error: null]
>> [Near : {... $delegator.delegateSpawn($ctxt }]
>>  ^
>> [Line: 1, Column: 1]
>> at
>> org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
>> at
>> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1297)
>> at
>> org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
>> at
>> org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
>> at
>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
>> at
>> org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
>> at
>> org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
>> at
>> org.apache.stratos.autoscaler.rule.AutoscalerRuleEvaluator.evaluateMinCheck(AutoscalerRuleEvaluator.java:86)
>> at
>> org.apache.stratos.autoscaler.monitor.LbClusterMonitor.monitor(LbClusterMonitor.java:91)
>> at
>> org.apache.stratos.autoscaler.monitor.LbClusterMonitor.run(LbClusterMonitor.java:63)
>> at java.lang.Thread.run(Thread.java:744)
>> Caused by: [Error: null]
>> [Near : {... $delegator.delegateSpawn($ctxt }]
>>  ^
>> [Line: 1, Column: 1]
>> at
>> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:435)
>> at
>> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:143)
>> at org.mvel2.ast.ASTNode.optimize(ASTNode.java:159)
>> at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:115)
>> at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85)
>> at
>> org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123)
>> at
>> org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119)
>> at
>> org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:113)
>> at org.mvel2.MVEL.executeExpression(MVEL.java:930)
>> at
>> org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:104)
>> at
>> org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
>> ... 9 more
>> Caused by: java.lang.IllegalArgumentException
>> 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.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:1104)
>> at
>> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:987)
>> at
>> org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:377)
>> ... 19 more
>>
>>
>> Thanks,
>> Melan
>>
>> --
>> *Melan Nimesh*
>> Software Engineer;
>> WSO2 Inc.;  http://wso2.org
>> E-mail: melan AT wso2.com;
>> Mobile: +94 77 631 6759
>>
>>
>
>
> --
> *Melan Nimesh*
> Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: melan AT wso2.com;
> Mobile: +94 77 631 6759
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*--*
*Sajith Kariyawasam*
*Mobile: +94772269575*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Value too long for REG_VALUE issue in Registry

[Ruchira Wageesha]

Hi Senaka,

Yes, UES team is supposed to do this and have already completed most of the
base of it using cassandra. But, depending a AM's commitment, they wanted
to implement something quickly, AFAIK, probably within 2 weeks.

You can find the thread on that at @architecture "[Architecture] Developer
Forum for the API Store" [1]

[1] https://mail-archive.com/architecture%40wso2.org/msg03817.html


On Sat, May 10, 2014 at 10:10 PM, Senaka Fernando  wrote:

> Hi all,
>
> I think we are heading in the wrong direction here. IIRC, we discussed to
> implement a social component. The UES guys are or will be working on this.
> The idea was to keep this outside of the registry. Can you'll chat with
> Ruchira as well and try to understand how all of this fits together. The AM
> and the ES and the rest of the social aspects have to line up or these will
> increasingly become incompatible.
>
> And, WRT Uvindra's case. That solution was a highly subjective one
> Uvindra. As Ajith says, we cannot make it a generic solution and be done
> with that. This has to be solved properly. But, for the scenario of a forum
> I don't think any of that was discussed here is going to work as I have
> explained above.
>
> Thanks,
> Senaka.
>
>
> On Sat, May 10, 2014 at 3:37 PM, Ajith Vitharana  wrote:
>
>> Hi Nuwan,
>>
>>
>> On Sat, May 10, 2014 at 6:54 AM, Nuwan Dias  wrote:
>>
>>>  On Fri, May 9, 2014 at 9:25 PM, Ajith Vitharana wrote:
>>>
 Hi Uvindra,


 On Fri, May 9, 2014 at 5:47 PM, Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> This limitation was highlighted during the discussion we had with
> Ajith just before work on the API Store forum was started. As I mentioned
> we ran into the same limitation when developing the development governance
> solution. The text area that was to store custom javascript rules could 
> not
> accommodate anything exceeding 1000 characters. In the end after 
> discussing
> with Senaka we solved the problem by increasing the column size of
> REG_VALUE to 5000 and changing the DB scripts that were shipped with the
> solution accordingly.
>

 So, what happen when the length is 5001 ? :)

>>>
>>> Yes, I think we should someday fix this rxt field to property mapping.
>>> Otherwise there's no point in having a field called 'text-area' in the rxt
>>> right? Its capabilities become limited to same as the 'text' field.
>>> Besides, from a user POV, there's no point in creating a property in the
>>> rxt for each field. And when you comes across the need to store more than
>>> 1000 characters in an artifact, you're totally blocked from doing so and
>>> have to resort to other complicated measures.
>>>
>>> So I suggest that we make it a point to fix this urgently when
>>> appropriate. Kernel 4.3.0 or C5 at least. Sooner the better :)
>>>
>>
>> As I mentioned early, property is the storage model we used for RXT.
>> Storing the whole content as XML  (BLOB) and  parsing XML each time is NOT
>> a solution at all.
>> Registry schema is a generic one to platform and it can't be change the
>> with the requirement of all new features. So, what we can do is use the
>> existing feature combinations to support the new requirement.
>>
>> If you want to store the large content/doc with artifact, then store that
>> content as separate resource and build the dependency/association with the
>> artifacts.
>>
>> WDYT ?
>>
>> Thanks.
>> Ajith.
>>
>>
>>
>>>
 Thanks.
 Ajith.

>
>
> On Fri, May 9, 2014 at 5:29 PM, Nuwan Dias  wrote:
>
>> Hi Ajith,
>>
>> We're developing a forum for the API Store using the registry as the
>> storage medium. Each topic/reply is stored in the registry as an 
>> artifact.
>> Topics/Replies have a rich text editor which supports code blocks, etc.
>> This text-area has been mapped to a text-area field in the rxt. So 
>> limiting
>> the characters to < 1000 is not very feasible in this scenario.
>>
>> Are you saying that increasing the column size of REG_VALUE is not a
>> good idea?
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Fri, May 9, 2014 at 5:22 PM, Ajith Vitharana wrote:
>>
>>> Hi Nuwan,
>>>
>>> We store the each filed as properties of the artifacts, that is the
>>> data model used. Anyway, having the 1000 characters for the given field 
>>> is
>>> a special case.
>>> So, it is not better to increase the default schema to handle this
>>> use case.
>>>
>>> Can't we limit the characters length for that  text-area ?
>>>
>>> Thanks.
>>> Ajith.
>>>
>>>
>>> On Fri, May 9, 2014 at 3:18 PM, Nuwan Dias  wrote:
>>>
 Hi,

 I have an rxt on which I am using a text-area field. However I get
 the following error if I am to put more that 1000 characters in the 
 field.

 org.h2.jdbc.JdbcSQLException: Value too l

Re: [Dev] OSGI Issue when trying to use Script Mediator in APIM

[Ruwan Yatawara]

Hi All,

After much research, we rounded up the problem, this is caused by the API
Manager host object using both synapse and jaggery. As I explained in my
previous email, when we use two different bundles that use different
versions of the same package, inside the same class space, "package use
conflicts" are encountered.

As a remedy to this problem, we need to upgrade the org.mozilla.javascript
version used by jaggery to version 1.7.0. This will also involve a possible
upgrade of bsf versions / changing the synapse ScriptMediator to
accommodate for possible API changes.

Thanks much, Kisanthan, Ruchira and Manu for all your help.

Thanks and Regards,

Ruwan Yatawara

WSO2 Inc.

email : ruw...@wso2.com
mobile : +94 77 9110413
blog : http://thoughts.ruwan-ace.com/
www: :http://wso2.com



On Fri, May 9, 2014 at 10:56 AM, madhuka udantha
wrote:

> Hi,
>
> This[1] can be helpful for such scenario,
> And you issue encounter is correct,
> *You can check some AS releases, where it also occurred and fixed as we
> added jaggery and mashup to AS.*
>
> [1]
> http://madhukaudantha.blogspot.com/2014/02/writing-hostobject-for-jaggery.html
>
>
>
> On Fri, May 9, 2014 at 8:53 AM, Ruchira Wageesha  wrote:
>
>> Please meet me in the office. Will be able to help you.
>>
>> /Ruchira
>>
>>
>> On Fri, May 9, 2014 at 12:02 AM, Ruwan Yatawara  wrote:
>>
>>> Hi All,
>>>
>>> We ran in to $subject when trying to use the script mediator in API
>>> Manager.
>>>
>>> When trying to use script mediator in AM APIs the following error is
>>> thrown.
>>>
>>> *Caused by: java.lang.NoClassDefFoundError:
>>> com/sun/phobos/script/javascript/RhinoScriptEngineFactory*
>>> * at
>>> org.apache.synapse.mediators.bsf.ScriptMediator.initScriptEngine(ScriptMediator.java:472)*
>>> * at
>>> org.apache.synapse.mediators.bsf.ScriptMediator.initInlineScript(ScriptMediator.java:338)*
>>> * at
>>> org.apache.synapse.mediators.bsf.ScriptMediator.(ScriptMediator.java:148)*
>>>
>>>
>>> To the best of my understanding, following is whats happening here.
>>>
>>> The script mediator depends on the bsf-all_3.0.0.wso2v2, which needs
>>> org.mozilla.javascript; version="1.6.0" or above to function.
>>>
>>> Jaggery is built to support org.mozilla.javascript; version="1.7.0" and
>>> above, and the API Manager host object, depends on both jaggery and synapse
>>> to function. When all of this comes together, we believe synapse has a
>>> problem with wiring the correct bundles (package usage conflict), leading
>>> to above quoted error.
>>>
>>> To overcome this, there are two options, and both seem to have
>>> considerable consequences
>>>
>>> a) Update the BSF jar to use org.mozilla.javascript; version="1.7.0"
>>>
>>> b) Update Synapse, restricting it to use org.mozilla.javascript;
>>> version="1.6.0", only and APIM host objects to use 1.7.0 specifically.
>>>
>>>
>>> Since Option A might require changes to ESB script mediator, as API
>>> changes may be in effect, we went ahead with option (b). This leads to
>>> errors in the API Manager Host objects and the bundle goes in to INSTALLED
>>> state. The following error is thrown, at startup and there are also errors
>>> when trying to invoke the API.
>>>
>>> *[2014-05-08 23:56:16,246] ERROR - ModuleManager Error while adding
>>> HostObject : APIStore org.wso2.carbon.apimgt.hostobjects.APIStoreHostObject*
>>> *java.lang.ClassNotFoundException:
>>> org.wso2.carbon.apimgt.hostobjects.APIStoreHostObject*
>>> * at
>>> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501)*
>>> * at
>>> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421)*
>>>
>>>
>>> Has anyone encountered such an issue before? How should we go about
>>> fixing this? Your thoughts/ideas/suggestions are welcome.
>>>
>>>
>>> Thanks and Regards,
>>>
>>> Ruwan Yatawara
>>>
>>> WSO2 Inc.
>>>
>>> email : ruw...@wso2.com
>>> mobile : +94 77 9110413
>>> blog : http://thoughts.ruwan-ace.com/
>>> www: :http://wso2.com
>>>
>>>
>>
>>
>> --
>>
>> *Ruchira Wageesha**Associate Technical Lead*
>> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com *
>>
>> *email: ruch...@wso2.com ,   blog:
>> ruchirawageesha.blogspot.com ,
>> mobile: +94 77 5493444 <%2B94%2077%205493444>*
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Cheers,
> Madhuka Udantha
> http://madhukaudantha.blogspot.com
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev