Hi Rasika,
We use the same implementation and use javax.script.*; even with the bsf
and bsf also provide the rhino16 engine. In script mediator we need to use
the Scriptable interface and that interface package name is different in
JDK7 and JDK8 when the script is executed. and also internal class
Hi Rasika,
Agree on all you the points.
>>IMO I think it doesn't matter whether internal or external library, when
someone lacks parsing error trace it will always reported as a WSO2 product
issue.
Let me explain the issue,
The JDK/JVM is not we provide or have control over. Customer will choose
a
@Nuwan and All,
I am not very familiar with BSF. Besides Apache BSF does not appear to have
active development. My suggestion is we should go with Scripting API(JSR223
). This javax.script.* API is available on runtime(rt.jar).
Any scripting language which implements it, we can support through th
Hi All,
I would not use the internal JS engine, whether Rhino or Nashorn, it is for
any critical server tasks due to,
1. This will cause any bugs in JS engine, or integration, to be reported as
WSO2 product issue. e.g. Historically similar integrations cause bugs like
[1] yield OOM in applications.
Hi Manuranga,
if the script engine is loaded from bsf-all(rhino16),
org.mozilla.javascript.Context will be used. But script engine is loaded
from JDK, sun.org.mozilla.javascript.internal.Context is used and those are
available in JDK itself. Nashorn or Rhino7 does not depend any third part
librar
Hi Nuwan,
Maybe `org.mozilla.javascript.Context` is the one you are looking for, not `
sun.org.mozilla.javascript.internal.Context`?
On Wed, May 4, 2016 at 11:13 AM, Nuwan Wimalasekara wrote:
> Hi Manuranga and Rasika,
>
> Thanks for the reply. But this is a different one. Below are the classes
Hi Manuranga and Rasika,
Thanks for the reply. But this is a different one. Below are the classes we
can not use in our class since those are internal classes in JDK and we can
not compile a class with below imports since those are only available in
runtime.
import sun.org.mozilla.javascript.inte
Hi Nuwan and all,
We also faced the same issue when accessing Nashorn on OSGi environment. To
overcome the class-loading issues; you can modify system bundle's package
exports to include the Nashorn scripting API package(using Fragment Hosts
approach suggested in [1]).
Please refer "nashorn-osgi-
Hi Nuwan,
Is the limitation you are facing due to OSGi level class def not found
exceptions? We faced something slimier and that was due to Nashorn classes
not been exposed via OSGi. We created a fragment bundle for the system
bundle to solve this. Please contact Rasika if that's the case.
Hi,
*Adding a suggestion to this thread given its related to improving the
ScripMediator:*
Also in addition another improvement to the ScriptMediator could be to
allow for functions in external js files to be referred to by the main
script file indicated in the ScripMediator (when those external
Hi
We could fix the limitation that script mediator can not handle message
payload larger than 64KB by only upgrading the rhino version to 1.7.0.R4.
But we have not upgraded script engine version to 17.
Currently ESB 5.0.0 loads script engines from apache-commons-bsf-3.0 and
java script engine is
Kasun we should move to Nashorn - we're already doing that in UUF and
that's the future.
On Wed, Apr 13, 2016 at 1:58 AM, Manuranga Perera wrote:
> I assume the current script engine use evaluate method. We can support
> evaluating once and invoking per request. This will add significant
> per-r
I assume the current script engine use evaluate method. We can support
evaluating once and invoking per request. This will add significant
per-request performance improvements.
Also when switching to nashorn we may be able to support IDEA debugging
like we have done for new UI framework.
On Mon,
I think for a major release such as 5.0, its quite important to get this
kind of major limitations fixed (this has been raised in several occasions
AFAIR)
Lets spend sometime and evaluate the effort involves with this.
For Connectors, if this introduce any issues, we have to fix them and
re-releas
Hi all,
Current script mediator implementation depends on apache-commons-bsf-3.0 to
get the script engines for Rhino, Ruby, Groovy and Jython [1][2]. However,
moving forward if we are to support newer Rhino and Nashorn (for Java 8) we
can directly use these engines or any other implementation of o
@PrabathAR - Can you give us more details on this please?
Inside Rhino engine, we can set optimization levels[1] which change the
behavior of the engine. Default level is 0 and no optimizations are
performed, but we can set this level in between -1 and 9 for the different
optimizations. We can set
We have to check if all use cases are supported if we are going to upgrade
or going for an alternative solutions.
Also some connectors are heavily using script mediator.
IMO we should not plan to do this for the immediate release.
On Mon, Apr 11, 2016 at 12:34 PM, Vanjikumaran Sivajothy
wrote:
With JDK 8, there is an in-build JS engine called Nashorn. Isn't that worth
to leverage the JS support by using native implementation to JDK 8?
[1]
http://www.oracle.com/technetwork/articles/java/jf14-nashorn-2126515.html
On Sun, Apr 10, 2016 at 11:57 PM, Malaka Silva wrote:
> PrabathAR has al
+1.
How about the effort involves in moving to the new version? Anyway, better
to do this enhancement for ESB 5.0.
On Mon, Apr 11, 2016 at 12:22 PM, Nuwan Pallewela wrote:
> Hi All,
>
> There is a limitation in wso2 script mediator when we try to manipulate
> payloads with JavaScript as the scri
PrabathAR has already found a way to support this using existing rhino
version. There is a configuration to optimize the execution.
@PrabathAR - Can you give us more details on this please?
On Mon, Apr 11, 2016 at 12:22 PM, Nuwan Pallewela wrote:
> Hi All,
>
> There is a limitation in wso2 scri
Hi All,
There is a limitation in wso2 script mediator when we try to manipulate
payloads with JavaScript as the scripting language, when the Payload size
is larger than 64KB, ESB throws an exception. Cause for this is Rhino
version which is used by the script mediator has a limitation of handling
21 matches
Mail list logo
