Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
+1 for Nashron integration. I think we need give some priority to Package manager. AFAIK nodejs[1] get huge demand and community support due to NPM[2] and it would be great to have similar Avatar.js[3]. [1] nodejs.org [2] https://www.npmjs.org/ [3] https://avatar-js.java.net/ *Dakshika Jayathilaka* Software Engineer WSO2, Inc. lean.enterprise.middleware 0771100911 On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With this, we expect people to write more command line tools such as built tools, package managers etc. using Jaggery *Demo Apps* 1.
Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
Hi, Ruchira 'app.server()' is similar for existing 'application.serve()' in jaggery , isn't it regard functionality? Here[1] is sample for application.serve(). [1] https://github.com/Madhuka/MadhukaBlogRepo/tree/master/SampleApps/JaggeryApps/service/ On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With this, we expect people to write more command line tools such as built tools, package managers etc. using Jaggery *Demo Apps* 1. https://github.com/ruchiraw/jaggery/tree/master/apps/demo1 - this is the bare minimal with app.server() - can be accessed
Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
Yes, it is the same, except application object itself is replaced by a module. On Mon, Jun 2, 2014 at 12:33 PM, madhuka udantha madhukaudan...@gmail.com wrote: Hi, Ruchira 'app.server()' is similar for existing 'application.serve()' in jaggery , isn't it regard functionality? Here[1] is sample for application.serve(). [1] https://github.com/Madhuka/MadhukaBlogRepo/tree/master/SampleApps/JaggeryApps/service/ On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With this, we expect people to write more command line tools such as built tools, package managers
Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
On Mon, Jun 2, 2014 at 12:46 PM, Ruchira Wageesha ruch...@wso2.com wrote: Yes, it is the same, except application object itself is replaced by a module. +1 On Mon, Jun 2, 2014 at 12:33 PM, madhuka udantha madhukaudan...@gmail.com wrote: Hi, Ruchira 'app.server()' is similar for existing 'application.serve()' in jaggery , isn't it regard functionality? Here[1] is sample for application.serve(). [1] https://github.com/Madhuka/MadhukaBlogRepo/tree/master/SampleApps/JaggeryApps/service/ On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With
Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
+1 for the Nashorn update. Is it possible for us to follow an API similar to NodeJS? This will make it easy for JavaScript developers to use Jaggery runtime. Also would love to get console.log() for logging instead of making Log objects and logging things (just a thought). Cheers~ On Mon, Jun 2, 2014 at 2:02 AM, madhuka udantha madhukaudan...@gmail.com wrote: On Mon, Jun 2, 2014 at 12:46 PM, Ruchira Wageesha ruch...@wso2.com wrote: Yes, it is the same, except application object itself is replaced by a module. +1 On Mon, Jun 2, 2014 at 12:33 PM, madhuka udantha madhukaudan...@gmail.com wrote: Hi, Ruchira 'app.server()' is similar for existing 'application.serve()' in jaggery , isn't it regard functionality? Here[1] is sample for application.serve(). [1] https://github.com/Madhuka/MadhukaBlogRepo/tree/master/SampleApps/JaggeryApps/service/ On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification
Re: [Dev] [Architecture] Introducing JSR-223 into Jaggery along with Nashorn Support
Ruchira, did you already had a session with Sanjiva? Let me know if we need to schedule. Do you have an example how app.server() works? On Sun, Jun 1, 2014 at 12:58 PM, Ruchira Wageesha ruch...@wso2.com wrote: Hi All, We have started the integration of JSR-223 i.e. javax.script API with Jaggery. Sorry for the lengthy mail, but this is just to share the status and get your all kinds of feedbacks. A Jaggery fork and a distribution with the following improvements can be found at [1] and [2] respectively. In case you want to try this out before sharing your feedbacks, you can download a Jaggery distribution with all the above implementations at [2]. It consists of 5 demo apps. (At the moment, this has been tested only on linux/mac and you will have to run this either on JDK 7 or 8. As JDK 6 supports only an older version of ECMAScript, this pack will not work. But in order to get the support even on JDK 6, we will have to pack the JSR-223 rhino implementation with a rhino 1.7 version, following a similar way described at [7]) With the integration with JSR-223, we had to and thought to do a few changes and improvements to Jaggery which will be detailed below. BUT, please note that, every existing Jaggery application will work as it is, independent of those improvements. i.e. With a version field in jaggery.conf, we internally decide, whether to go with the newer version. *Key Decisions* 1. JSR-223 support - With this, Jaggery will use Nashorn from JDK8 onwards and will fallback to JDK's embeded Rhino version with JDK7 or below. 2. Saying good bye for hostobjects - Hostobjects are a concept of Rhino and it was needed to follow certain conventions when you write your hostobjects. With JSR-223, we cannot have it anymore. But, instead of that, you can refactor only the hostobject *.java class into *.js file which contains the Java code and plug it. 3. Dropping E4X support - E4X was an extension to ECMAScripts and usage of E4X is being deprecated in many places. Also, AFAIK, there is no support for E4X in nashorn. This will be replaced by a Axiom/DOM like modules. i.e. without altering the spec. 4. Except the bare minimal, everything else is separated into commonjs modules - This will give much more flexibility and extendability for Jaggery. i.e. In order to extend Jaggery, developers don't need to be Java developers anymore 5. Introduction of app.server() method - In the current version, routing mechanism has been implemented by Jaggery core and there is no way to intercept that. This makes it harder to write cooler modules for Jaggery, such as express, connect for node. Using app.server(), Jaggery core delegates request serving to a single callback. But, via that callback, users can call their own routing modules and do whatever they want. You can even implement the current *.jag model, on top of app.server()[refer demo3]. Also, we have written an express like routing framework which can be used to define REST APIs very easily through Jaggery. This will be a good alternative for JAX-RS developers too. 6. Servlet 3.0 Async support - Another key feature is utilizing Async servlet support. So, concurrency will not be restricted by the available thread count anymore. 7. CommonJS module system - At the moment, Jaggery has its own module system. Instead of that, we though of going ahead with commonjs module specification. With this, commonjs compliant modules will be able to use within Jaggery. i.e. Any node module which doesn't depend on node core APIs, can be used in Jaggery as well, without doing any change. 8. Module versioning and nested module support - Another improvement is, adding module versioning support for Jaggery modules. i.e. x app(or module) can use y1 version of y module, while another z app(or module) can use y2 without conflicting each other. For this too, we are also using package.json as per the commonjs specification 9. Support for deploying directly on top of tomcat - With the above Jaggery core minimisations, a Jaggery app can be even deployed on top of tomcat, subjecting to a WEB-INF directory which contains jaggery core jars and web.xml 10. Improved command line tool - clamshell-cli based command line tool with history support etc. With this, we expect people to write more command line tools such as built tools, package managers etc. using Jaggery *Demo Apps* 1. https://github.com/ruchiraw/jaggery/tree/master/apps/demo1 - this is the bare minimal with app.server() - can be accessed via http://localhost:9763/demo1 2. https://github.com/ruchiraw/jaggery/tree/master/apps/demo2 - this shows
