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>*
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
