Mailing List Set up
At JavaOne the members of JSR107 present agreed to conduct technical deliberations in public view. Anyone can go to https://jsr107.dev.java.net and see what we are up to. In particular discussions are taking place on the jsr107 AT jsr107.dev.java.net mailing list. Go to https://jsr107.dev.java.net/servlets/ProjectMailingListList
to search the archive or set up an RSS feed.
JSR107 Development Philosophy
I believe it is a widely held community view that there has been a problem in the JCP that some JSRs have failed because they created technology and APIs with insufficient community involvement. Based on things I have seen and read I do not think the original JSR107 draft API is well considered in the community.
Given the length of time that has elapsed since the start of JSR107, we are now in a situation where the open source and commercial caches have evolved a feature set and APIs based on organic growth, driven by demand. There are many instances where ehcache, which started out simply, got requests for feature xxx like in OSCache, or “other caches do this so why don’t you”. These caches are now around 4 years old so this process has had that long to run its course.
The second point is that caching is now very widely used. There are therefore a large group of people with expectations about how caching works in Java.
So, I think the community will be expecting JSR107 to deliver something like they already get from the various open source caches and to a lesser extent the commercial caches. These caches provide a lot of utility. Simply standardising the API and the SPI so that the community can use an implementation with a low cost of change is, I think, the most valuable part of JSR107.
I see the involvement of representatives from Ehcache, JBossCache and Tangosol as being key to delivering on this expectation.
I also think it vital to allow simple, no-overhead, read-only access to the technical debates on features so that possibility of feedback from the community to EG members is possible.
So this is the background I have to the current JSR107 deliberations. It might be useful to get an exchange of these philosophical views now rather than playing them out feature by feature.
The spnego project has released version 1. The Spnego project is a Kerberos over SPNEGO plugin for JSR196 compliant application servers. Right now the Glassfish betas are compliant, with other appservers like JBoss expected to be compliant soon.
The plugin lets your Java web applications participate in a Kerberise Single Sign On environment. Log in to Kerberos in an enterprise, and you will not even need a login page in your web apps. IE, Firefox and Safari all work. And Windows, Mac OS X and Linux all work.
This project is something of a missing link for Java application servers. Apache has had mod_auth_kerb which does the same thing for Apache apps for some time. And Websphere and Weblogic have had proprietary implementations. But this release lets you use any application server.
See http://spnego.dev.java.net for full documentation and downloads.