Hi All, After having a meeting with Kasun Indrasiri, Isuru Udana, Nuwan Wimalasekara and Asitha Nanayakkara we have decided to use "language" attribute to differentiate between, using Rhino based implementation and using Nashorn based implementation when return script mediator instance through factory. Also we have performed evaluation between element access time of Rhino engine with E4X xml objects and Nashorn with DOMparser and XPath query. To access single element Rhino based implementation took average time of 1.301ms while Nashorn based implementation only took 0.368ms. Hereby I have attached the document with test details and complete results also.
Thanks. On Sat, Jul 22, 2017 at 11:33 PM, Dinesh J Weerakkody <[email protected]> wrote: > Instead of introducing a new mediator, can't we use the *Language* > attribute to differentiate the two. May be language="js" will use the Rhino > and language="js/nashorn". Just an idea. > > Thanks > > *Dinesh J. Weerakkody* > Senior Software Engineer > WSO2 Inc. > lean | enterprise | middleware > M : +94 710 868676 <+94%2071%20086%208676> | E : [email protected] | W : > www.wso2.com > > On Wed, Jul 19, 2017 at 11:11 PM, Himasha Guruge <[email protected]> > wrote: > >> +1 for a new mediator.There seem to be differences such as calling static >> methods on a Java class instance in Rhino vs Nashorn[1], which can be >> cumbersome/confusing for a user who is migrating the artifacts from Rhino >> to Nashorn (users of older versions of ESB). >> >> >> [1]http://nashorn.36665.n7.nabble.com/Bug-report-can-t-call- >> static-methods-on-a-Java-class-instance-td2196.html#a2206 >> >> Thanks, >> >> On Wed, Jul 19, 2017 at 9:30 PM, Malaka Silva <[email protected]> wrote: >> >>> +1 to introduce a new mediator due to following. >>> >>> Most of the current connectors are using script mediator. Also how sure we >>> are the Nashorn based script mediator can handle all the use cases we >>> used the handle? >>> >>> >>> >>> On Wed, Jul 19, 2017 at 8:29 PM, Isuru Udana <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> If we cannot get Nashorn to work with E4X or E4X style syntax, we >>>> shouldn't simply change the JS engine to Nashorn in current Script >>>> Mediator. We need to make sure our releases are backward compatible. >>>> So in that case we need to introduce a new mediator. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> On Wed, Jul 19, 2017 at 7:39 PM, Harshana Eranga Martin < >>>> [email protected]> wrote: >>>> >>>>> Hi Malaka, >>>>> >>>>> If you drop the support for E4X when moving to Nashorn, what happens >>>>> to the customers who want to migrate their artefacts from an old ESB >>>>> version (say 4.8.1) to the new version? >>>>> >>>>> Re-writting the entire JS artefacts will not be a possibility for >>>>> many. So you need to have a serious think about how to provide a safe and >>>>> pain free migration path for old E4X based code to the new engine. >>>>> >>>>> Thanks and Regards, >>>>> Harshana >>>>> -- >>>>> Harshana Eranga Martin >>>>> >>>>> Committer - Eclipse ECF: http://www.eclipse.org/ecf/ >>>>> Blog: http://harshana05.blogspot.com >>>>> Profile: https://www.google.com/profiles/harshana05 >>>>> >>>>> On 19 July 2017 at 21:14, Malaka Gangananda <[email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Current script mediator use Rhino as its JavaScript engine and we are >>>>>> in the process of upgrading the script mediator to use new Nashorn >>>>>> engine. >>>>>> So we will be providing the capability of using Rhino as javascript >>>>>> engine >>>>>> for java 7 users and Nashorn for java 8 users in script mediator. But in >>>>>> the process we have found some issues and solved them. Such as when >>>>>> trying >>>>>> to set Json payload the existing Rhino engine will use its native objects >>>>>> to pass Json payload so in existing script mediator it use different >>>>>> serialization techniques for each Rhino native object type. But in >>>>>> Nashorn >>>>>> the passed object will be always ScriptObjectMirror type. We have >>>>>> overcome >>>>>> this issue by serializing these objects using serialization functionality >>>>>> of Nashorn native "JSON" object. So when handling the Json payloads the >>>>>> used engine will not be an issue. But the main issue was usage of E4X xml >>>>>> objects when handling xml payloads with Rhino engine. Because as stated >>>>>> in[1] E4X is deprecated and it does not supported by Nashorn engine. To >>>>>> overcome this when using Nashorn, DOMparser can be used to parse xml >>>>>> strings rather than using xml objects. But then the users who are using >>>>>> script mediator with new Nashorn engine will not be able to use xml >>>>>> objects >>>>>> in javascript but they will be able to use setPayloadXML and >>>>>> getPayloadXML >>>>>> methods in script mediator by using string representations of xml. So the >>>>>> decision we need to make is whether to use existing mediator with Nashorn >>>>>> engine support but without using E4X(which is deprecated but still using >>>>>> Rhino engine it will be supported) or writing new mediator separately for >>>>>> javascript with Nashorn engine support. >>>>>> >>>>>> >>>>>> [1] https://developer.mozilla.org/en-US/docs/Archive/Web/E4X/Pro >>>>>> cessing_XML_with_E4X >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> Malaka. >>>>>> -- >>>>>> Malaka Gangananda - Software Engineer | WSO2 >>>>>> Email : [email protected] >>>>>> Mobile : +94713564340 <+94%2071%20356%204340> >>>>>> Web : http://wso2.com >>>>>> <http://wso2.com/signature> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Isuru Udana* >>>> Senior Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> email: [email protected] cell: +94 77 3791887 <077%20379%201887> >>>> blog: http://mytecheye.blogspot.com/ >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Malaka Silva >>> Associate Director / Architect >>> M: +94 777 219 791 <+94%2077%20721%209791> >>> 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 >>> https://wso2.com/signature >>> http://www.wso2.com/about/team/malaka-silva/ >>> <http://wso2.com/about/team/malaka-silva/> >>> https://store.wso2.com/store/ >>> >>> Don't make Trees rare, we should keep them with care >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Himasha Guruge >> *Software Engineer* >> WS*O2* *Inc.* >> Mobile: +94 777459299 <+94%2077%20745%209299> >> [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Malaka. -- Malaka Gangananda - Software Engineer | WSO2 Email : [email protected] Mobile : +94713564340 Web : http://wso2.com <http://wso2.com/signature>
E4X Vs DOMparser accessing xml element through Xpath - Sheet1.pdf
Description: Adobe PDF document
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
