New version of JSPWiki In The Cloud

I deployed new version of Google App Engine JSPWiki port. Caching mechanism was added (by means of Google App Engine MemCache). Performance improves a little bit but it is not a significant change.
Sources are available on GitHub.
I also moved demo version to http://myjspwiki.appspot.com/ because previous location is infested by spam.

MVP framework, application and localization

Introduction
Several new features have been added to my MVP framework.
Localization
It is possible to create a fully localized application. Some localized message are framework embedded (for instance messages like: Yes, No, Accept, Resign) and it is possible also to create application specific messages.
More detailed description is available here.
Example of localized application (Google App  Engine).
English (default)
Polish
In both cases U/P is admin/admin
Check list widget utilization
In application available from above a check list widget is used in order to specify permission for the specific user in the specific hotel.
Development/production
The purpose is to develop Web application business logic only in Jython code without recompiling and redeploying the application. It means that during development every request should read fresh copy of jython code and dialog XML format. But of course it should be avoided in production code because it means significant reduction in performance. So development mode is introduced with the following features:

1. Jython code, XML dialog and message bundles outside java class loader to avoid constantly republishing application to application server (when Eclipse project is open)
2. No caching, just load resources directly form file system.
3. Restart Jython with every request
4. Every request takes a new copy of bundle messages.

Start of Java Hotel development
The application above is the first step in creating Java Hotel application. So far simple administration part is created - allows defining hotels, user and permissions.
Full source code of Java Hotel application created so far is available here. Also not Google App Engine (JPA based) version has been created.
Next step
Authentication to Java Hotel application using realm created in Administrative part described above.

New version of JSPWiki in the clouds

Problem
I realized that my humble JSPWiki implementation for Google App Engine is under spam attack. Nasty anonymous user is constantly adding spam message to the main page. I also realized that ACL (Access Control List for pages) does not work in my implementation so I was unable to restrict access to this page.
Solution
After spending some time I enabled ACL for page access. So one can add to the pages stuff like [{ALLOW view SocialCommittee}] and the access is limited. The problem was awkward binding ACL list with the 'WikiPage' class I found in the standard version. But now it seems working, I restricted access to the 'Main' page and although the page was under spam attach all the time the spam message was not added. I also put the spam address to the blacklist (using solution described here) and the battle with spam is over and victorious for the time being.

New version of JSPWiki

I uploaded a new version of JSPWiki. It has attachment feature enabled, one can download and upload attachments to the pages. An example of page having attachment added - look here.
To keep attachments a Blob data type is used. Source code to entity is here, it is simple key (page name) -> Blob content schema. So it shares 1MB limitation of blob size.
It is possible to overcome this limitation by using Google App Engine Blobstore service , no problem to replace WikiPageBlob entity with Blobstore Api. It is also possible to combine this two options together, attachments less then 1MB keep in entity, for greater attachment use Blobstore service.

JSPWiki in the Cloud, JAAS security

I spent some time enabling JAAS security implemented in JSPWiki. After removing some bugs in the JSPWiki I was successful in the development mode (with options like: "Log in", "Preferences", "Adding new user", "Adding group" etc.). But after deploying to Google App Engine it failed with message like:

2012-05-18 23:41:43.072

org.apache.log4j.Logger error: Failed to start managers.
java.security.AccessControlException: access denied (javax.security.auth.AuthPermission modifyPrincipals)
 at java.security.AccessControlContext.checkPermission(AccessControlContext.java:355)
 at java.security.AccessController.checkPermission(AccessController.java:567)
 at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 at com.google.apphosting.runtime.security.CustomSecurityManager.checkPermission(CustomSecurityManager.java:56)
 at javax.security.auth.Subject$SecureSet.add(Subject.java:1076)
 at java.util.Collections$SynchronizedCollection.add(Collections.java:1634)
 at org.apache.wiki.WikiSession.invalidate(WikiSession.java:615)
 at org.apache.wiki.WikiSession.guestSession(WikiSession.java:775)
 at org.apache.wiki.WikiSession.staticGuestSession(WikiSession.java:805)
 at org.apache.wiki.WikiSession.getWikiSession(WikiSession.java:744)

I also realized the in the development mode I added the following parameter to "Run" configuration : -D--enable_all_permissions=true just turning the security off. But of course it is out of my control in the production mode.
It seems that although javax.security.auth is listed on the Google App Engine list of supported packages it does not work and there is no way to overcome it.
So after spending some time I'm again at the very beginning with JSPWiki security. I see two options available : create security mechanism on my own or reuse some existing security framework (like Spring security).

JSPWiki in the Cloud

I started a cleaning phase and deployed a new version of JSPWikiForClouds.  So far I remove all references to javax.management. This package is not supported by Google App Engine and cannot figure out how to overcome. It does not seem impact core functionality. Solution implemented by javax.management (for instance: user management) should be resolved completely differently.
Current development status is available here.
Next step
Next step is to remove oscache package. This package is deprecated and not supported any longer. I will have to understand what is the role of this package in the JSPWiki application and decide if it can be simply removed or replaced with JCache (Google App Engine supports JCache to some extends).

JSPWiki in the Cloud

Story
I have been a user of the JSPWiki for years. I have it installed on my computer and simply using it as a local place for keeping different information and links. But for some time I have been wondering about putting it in the cloud (Google App Engine) and have it available from every computer I'm using, not only from my desktop. The only problem seemed to be that current PageProvider implementation (the way how wiki pages are persisted) does not support Google App Engine data store. But plugin based design of JSPWiki seemed to make it simple - just next implementation of PageProvider interface. So I started working moving JSPWiki into to the world (heaven) of clouds.
But I realized soon that Google App Engine implementation of PageProvider is the simplest piece of work.  The current implementation of JSPWiki cannot be executed in Google App Engine and substantial changes are necessary. What more important,  after having it running in development mode a lot of problems came up after deploying to a production environment. Also keeping backward compatibility with existing implementation JSPWiki is not possible. For instance : threads are not supported in Google App Engine but thread based services are not implemented as plugins but embedded inside the code.
The list of problems I found and solutions implemented is available here.
But finally, after fighting, loosing and winning a lot of battles, the first version emerged. It is only a subset of all features available but the core functionality is working. It also proves that the task (Google App Engine migration) is doable at all - this question was hovering over me all the time. So the PoC is passed.
Full source code is available here - I opened a new Open Source project.
What next
The purpose is of course to enable all features available but I cannot tell now when this target will be hit. The very first stage is cleaning. After breaking backward compatibility with the main JSPWiki trunk just remove all stuff  not used and temporary fixes.
After having the code clean the first feature implemented is security. Implementing authentication and authorization using services supported by Google App Engine. Probably the best method of authentication is Google authentication.