|
NetKernel News Volume 1 Issue 43
August 27th 2010
What's new this week?
Catch up on last week's news here
Repository Updates
The following updates are available in both the NKEE and NKSE repositories...
- layer1 1.18.1
- Fixes potential recursive search for SimpleDynamicImport imports
- nkse-cron 1.10.1
- Prevents a null request firing immediately after restart if removing a module with cron jobs
- nkse-doc-content 1.24.1
- Fixed a documentation bug in the Creating a Module tutorial. (Thanks to Kevin Ansberry for reporting this).
- wiki-core 1.6.1
- Removes superfluous <span> tags around XHTML macro engine invocations. These tags could lead to ill-formed HTML. It is now the responsibility of the macro engine to provide any CSS class or block formatting in their output.
NetKernel ClassLoaders
I've recently been working with René Jansen from the IBM NetRexx team helping them to integrate NetRexx as a dynamic language runtime for NetKernel. The following discussion of the NK classloader might be of interest to anyone working on a library integration - especially involving dynamic class loading...
I asked René how I could give the NetRexx interpreter, in an experimental language runtime accessor, an NK-aware classloader. To which I received this question...
To which I replied...
The problem is not finding NetRexxC.jar, as you can see in the module I sent you, NK will automatically discover any jar file contained in the lib/ directory of a module.
The issue is to do with the nature of a language runtime. When a user writes a script they may want to reference classes in their module. NK has a rich dynamic classpath model which allows classes from a local module, mounted local lib/ jars, contextually scoped application modules, the NK core and the JVM to be accessed (in that approximate order)
For details see here...
http://docs.netkernel.org/book/view/book:guide:physicalreference/doc:physicalreference:classloader
By default any thread entering an Accessor onSource() method will have its ContextClassLoader set to an instance of a "simple" contextual NK module classloader. This classloader gives access to the inverted classpath described in the reference docs and is usually more than adequate for "everyday use".
However more generally, especially for a language runtime, an end user expects that their script should be able to reference classes in the location from which their script is invoked. Importantly, this is not the same as the location of the language runtime endpoint, which is down in its parent module. Therefore we always ensure that a language runtime is given a contextual RequestScopeClassLoader which has access back up the "superstack" into the user's request context.
It might help to see an example of the other languages (just look in their module for the source). For example here is how the Python script compiler receives its RequestScopeClassLoader...
import org.netkernel.layer0.util.RequestScopeClassLoader; RequestScopeClassLoader cl= new RequestScopeClassLoader( context.getKernelContext().getThisKernelRequest().getRequestScope() ); try { PyCode result; synchronized(sJythonSync) { PySystemState.initialize(); PySystemState pss=new PySystemState(); pss.setClassLoader(cl); pss.path=new PyList(new PyObject[] {new PyString("")}); pss.registry=sRegistry; Py.setSystemState(pss); sContext=context; sSourceName=srcname; result = Py.compile(new ByteArrayInputStream(srccode.getBytes()), srcname, CompileMode.exec); } context.createResponseFrom(result); } catch(PySyntaxError pe) { //Not shown... }
If NetRexx uses the Thread ContextClassloader then a quick hack would be to construct a RequestScopeClassLoader and set the Thread context classloader to that - making sure to swap it back before returning.
Talk: Resource Oriented Cloud Architectures
I'll be giving a talk on Resource Oriented Cloud Architectures at SkillsMatter in London on the 21st September. Here's the blurb...
In this talk Peter Rodgers will show how the Resource Oriented approach enables the clean separation of concerns of "code" from "system architecture". He shows that a small set of core "Resource Oriented Computing" building blocks are all that is required to create elegant non-distributed "server-side architecture". Showing how "ROC-Inside" offers a wealth of powerful engineering-led patterns such as concurrency management, system-wide caching, fault tolerance, long-term absorption of change etc.
After introducing the localized features of ROC-design it is shown that a natural consequence is that ROC solutions are scale-invariant. It will be demonstrated how, with no further modifications, a solution can be seamlessly scaled out across a distributed cloud platform.
As usual its a free evening event which usually ends-up down the pub. It requires registration, so book here now.
Have a great weekend.
Comments
Please feel free to comment on the NetKernel Forum
Follow on Twitter:
@pjr1060 for day-to-day NK/ROC updates
@netkernel for announcements
@tab1060 for the hard-core stuff
To subscribe for news and alerts
Join the NetKernel Portal to get news, announcements and extra features.