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
library. It load all required classes from JDK it self. and also If we use
JDK to load the script engine, behaviour may also be changed according to
JDK we are running.
Thanks,
Nuwanw
On Wed, May 4, 2016 at 8:47 PM, Manuranga Perera <m...@wso2.com> wrote:
> 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 <nuw...@wso2.com>
> wrote:
>
>> 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.internal.Context;
>> import sun.org.mozilla.javascript.internal.Scriptable;
>> import sun.org.mozilla.javascript.internal.ScriptableObject;
>> import sun.org.mozilla.javascript.internal.xml.XMLObject;
>>
>> Thanks,
>> Nuwanw
>>
>> On Wed, May 4, 2016 at 8:30 PM, Rasika Perera <rasi...@wso2.com> wrote:
>>
>>> 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-fragment" module [2] in UUF.
>>>
>>> <Fragment-Host>system.bundle;extension:=framework</Fragment-Host>
>>> <Export-Package>jdk.nashorn.api.scripting;
>>> version="${nashorn-osgi-fragment.version}"</Export-Package>
>>>
>>> Thanks
>>>
>>> [1] https://github.com/mszu/nashorn-scripting-api-fragment
>>> [2]
>>> https://github.com/wso2/carbon-uuf/blob/master/nashorn-osgi-fragment/pom.xml
>>>
>>> On Wed, May 4, 2016 at 8:04 PM, Manuranga Perera <m...@wso2.com> wrote:
>>>
>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> With Regards,
>>>
>>> *Rasika Perera*
>>> Software Engineer
>>> M: +94 71 680 9060 E: rasi...@wso2.com
>>> LinkedIn: http://lk.linkedin.com/in/rasika90
>>>
>>> WSO2 Inc. www.wso2.com
>>> lean.enterprise.middleware
>>>
>>
>>
>>
>> --
>> Nuwan Wimalasekara
>> Senior Software Engineer - Test Automation
>> WSO2, Inc.: http://wso2.com
>> lean. enterprise. middleware
>>
>> phone: +94 71 668 4620
>>
>>
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
--
Nuwan Wimalasekara
Senior Software Engineer - Test Automation
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware
phone: +94 71 668 4620
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
