NetKernel News Volume 1 Issue 40

August 6th 2010

What's new this week?

• NKEE RC2 available now.
• NKSE Repo updates
• Tip: NK Continuity of service during install
• What's with the Wiki?

Catch up on last week's news here

NetKernel Enterprise Edition v4.1.1 RC2

Well we ended up going for an RC2 build after all. It's available for download here:

https://cs.1060research.com/csp/download/ (registration required)

We decided to take the extra time this week to make some changes now, that might have production implications if we added them later down the line...

Mapper Resolution

A notable enhancement is that the mapper resolution model has been changed. To date, a resolved (mapped) sub-request would be issued into the overlay space of the mapper. If it failed to resolve inside the space, the mapper would detect this and prevent the request from travelling out into the superstack address space.

This pattern therefore meant that anything that you wanted to map to had to appear inside the mapper address space. This constraint meant that sometimes an application rootspace would need to express two sets of imports one outside and one inside the mapper space. While this was strictly correct and had no system significance, it could look somewhat strange and confusing to developers.

Another nit with this pattern was that the classical NK3 style of a request rewrite in the same context space, became less easy to do. So for example, the bounced mapping pattern of going down to res:/blah and back up to httpRequest:/param/blah, couldn't be done without a script inside the mapper space.

We didn't screw up when we implemented this pattern, it was well intentioned since we were concerned that it might be too easy during development to accidentally trigger recursive requests.

However, we now think that this was too cautious, and led to an inconsistent and ultimately limiting situation. So we've changed the one line of code in the mapper which was terminating the upwards resolution. The updated mapper (in both NKEE RC2 and in the NKSE repos) now will first issue requests for resolution into the mapper space, but if they don't resolve now allows them to try the superstack.

What are the consequences of this change?

Well for an existing application, there is no affect, since to work with the old mapper pattern, they had to be providing a resolvable endpoint inside the mapper space. So they will carry on working as before. (For reassurance, all our production systems are now running on RC2 with the new pattern mapper with no issues).

You now have the freedom to do the patterns described above. You will also find it more intuitive to find imports when using the mapper.

We've added some recursion detection to the mapper - so our fears of development time runaway are taken care of too.

So, you see why we thought we'd play safe and issue another RC. This change is subtle but ultimately is in the right direction - better to have consistent, uniform implementation of the abstraction, than to have a peculiar corner case.

If you were happy with the old approach or want an extra safety net, then you can reproduce the exact previous pattern by placing a limiter endpoint as the last item in the mapper space.

Refactor of Wiki Macro Engines

We've been playing with Wiki's recently (see below) and realized that we'd made a silly decision with the wiki:core library. We'd put a small set of macro engines into the same space as the recursive wiki processing runtime. This meant that these macros could never be overridden or replaced by alternate implementations.

So we've factored the macro engines out into a new space urn:org:netkernel:wiki:macros

So if you want the macro engines import that space together with the original urn:org:netkernel:wiki:core.

Because this library is used by a number of system applications (apposite, docs, unit tests, search) we had to ship updates with the two-for-one import change. Hence you'll see those modules updated in the repositories.

Release Plans

Barring any last minute rethinks on the fundamental ROC abstraction! The RC2 will be what gets declared gold next week.

NKSE Repository Updates

The following updates are available in the NKSE repos...

• layer0 1.33.1
• module-standard 1.21.1
  • Changes to the mapper resolution.
• database-relational 1.7.1
  • Added documentation for the ResultSetRepresentation.
• nkse-cron 1.8.1
  • Fixed a possible error condition when a job fired while a target module was being recommissioned.

Wiki Refactor

The following modules were affected by the wiki:core refactor...

• nkse-dev-tools 1.22.1
• nkse-doc-content 1.23.1
• nkse-docs 1.12.1
• nkse-search 1.10.1
• nkse-unit-tests 0.9.1
• nkse-xunit 1.5.1
• wiki-core 1.5.1
• wink 1.6.1

Production Tip: Install a new NK without taking down existing server

The default backend for a NK installation is port 1060. The default for installing a new NK distribution is also port 1060. On face value, this means you have to shut down the existing instance before you can install the new distribution.

Not if you set the netkernel.http.backend.port property in the JVM before firing up the distro jar...

java -jar -Dnetkernel.http.backend.port=1070 1060-NetKernel-EE-4.1.1.jar

Now you'll have the old system running on http://localhost:1060 and the new system ready to be installed and running on http://localhost:1070.

If you want to carry on configuring the new NK instance whilst still keeping the older version up, then add -Dnetkernel.http.backend.port=1070 to the installed jvm properties [ install ]/bin/jvmsettings.cnf before you boot the new install.

What's with the Wiki?

Those of you who've been receiving the weekly news emails for a while will no doubt be suffering culture shock at this point. We finally got around to setting up a production installation of the WiNK wiki app. And since I added search to it last week. It felt like it might be a better way of sharing and archiving the contents of my weekly rambling.

Also we have a new toy to share with you. Brian Sletten and I have been collaborating on a macro library that allows Slidy presentations to be written in wiki text and "executed" on top of the WiNK runtime. It's kind of a long story so here's a live example of what it does...

SliNKi = Slidy + WiNK

The slinki macros are installable from the repositories - look for wink-slinki in Apposite. A copy of the demo presentation, showing how we structured a rich presentation application into a module can also be installed as wink-slinki-demo

Well, hope you like the new format. As usual, have a great weekend!