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 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 about module versioning and nested modules
>>>       - can be accessed via http://localhost:9763/demo2
>>>    3. https://github.com/ruchiraw/jaggery/tree/master/apps/demo3
>>>       - this shows how you can implement *.jag support on top of
>>>       app.serve()
>>>       - can be accessed via http://localhost:9763/demo3/index.jag
>>>       - you can click on "See Docs" link too
>>>       - at the moment, this doesn't support all the APIs of the current
>>>       version, but this is a PoC for that.
>>>    4. https://github.com/ruchiraw/jaggery/tree/master/apps/demo4
>>>       1. this shows the usage of express like routing module developed
>>>       by SameeraM[3]
>>>       2. can be accessed via http://localhost:9763/demo4/users/1 or
>>>       http://localhost:9763/demo4/apps/1
>>>    5. https://github.com/ruchiraw/jaggery/tree/master/apps/demo5
>>>       - by copying this into the webapps directory of an apache tomcat
>>>       server, you can try out how Jaggery can work on tomcat
>>>       - this app is exactly like aboute demo4, but this time, it runs
>>>       on tomcat.
>>>       - can be accessed via http://localhost:8080/demo5/users/1 or
>>>       http://localhost:8080/demo5/apps/1
>>>
>>> When, above demos are run, you will be able to see module resolution log
>>> messages at the moment. Hence, if you are doing any kind of load testing
>>> etc.,
>>>
>>>    - If it is Jaggery server, please make "development" as false in
>>>    jaggery.conf
>>>    - If it is on tomcat, set "jaggery.development" as false in web.xml.
>>>
>>> This will enable caching for loaded modules, pooling for script engines
>>> and async servlets. Further, you can fine tune the performances using the
>>> jaggery.conf[4] parameters on Jaggery and web.xml[5] parameters on tomcat.
>>> I have done only a small load test to test the server concurrency. Will do
>>> a proper benchmarking round after improving further.
>>>
>>> *Command Line Tool*
>>>
>>>    - In order to use the cmd tool, you need to first set the
>>>    environment variable JAGGERY_HOME pointing to your unzipped Jaggery
>>>    distribution
>>>       - export
>>>       
>>> JAGGERY_HOME=/Users/ruchira/binaries/jaggery/1.0.0/m0/jaggery-0.9.0-SNAPSHOT
>>>    - Then download *.jar at [8]
>>>    - Execute the downloaded *.jar using
>>>       - java -jar
>>>       org.jaggeryjs.cmd-0.9.0-SNAPSHOT-jar-with-dependencies.jar
>>>       - You can require the modules
>>>       - relative to your working directory. e.g. require('./foo') if it
>>>       the module foo is at <cwd>/foo.js or <cwd>/foo/
>>>       - If you have a jaggery-modules directory working direcotry as
>>>       <cwd>/jaggery-modules, then you can require any module exists there 
>>> using
>>>       require('foo') etc.
>>>
>>> Current implementation is just the core to get started and demonstrate
>>> what I have mentioned above. We have plans along the line to write
>>> a comprehensive Jaggery Package Manager, a maven plugin to execute unit
>>> tests etc.
>>>
>>> [1] https://github.com/ruchiraw/jaggery
>>> [2]
>>> https://github.com/ruchiraw/sandbox/raw/master/jaggery/1.0.0/m0/jaggery-0.9.0-SNAPSHOT.zip
>>> [3] https://github.com/splinter/jaggery-pipe
>>> [4]
>>> https://github.com/ruchiraw/jaggery/blob/4560a303f809d532ad041125c1a29ecc2eb9df55/apps/tomgery/jaggery.conf
>>> [5]
>>> https://github.com/ruchiraw/jaggery/blob/master/apps/demo5/WEB-INF/web.xml
>>> [6] https://github.com/vladimirvivien/clamshell-cli
>>> [7]
>>> https://wiki.openjdk.java.net/display/Nashorn/Using+Rhino+JSR-223+engine+with+JDK8
>>> [8]
>>> https://github.com/ruchiraw/sandbox/raw/master/jaggery/1.0.0/m0/org.jaggeryjs.cmd-0.9.0-SNAPSHOT-jar-with-dependencies.jar
>>>
>>>
>>> --
>>>
>>> *Ruchira Wageesha**Associate Technical Lead*
>>> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>> <http://wso2.com>*
>>>
>>> *email: ruch...@wso2.com <ruch...@wso2.com>,   blog:
>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>,
>>> mobile: +94 77 5493444 <%2B94%2077%205493444>*
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Cheers,
>> Madhuka Udantha
>> http://madhukaudantha.blogspot.com
>>
>> _______________________________________________
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Ruchira Wageesha**Associate Technical Lead*
> *WSO2 Inc. - lean . enterprise . middleware |  wso2.com <http://wso2.com>*
>
> *email: ruch...@wso2.com <ruch...@wso2.com>,   blog:
> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>,
> mobile: +94 77 5493444 <%2B94%2077%205493444>*
>
> _______________________________________________
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Cheers,
Madhuka Udantha
http://madhukaudantha.blogspot.com
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to