techno.blog("Dion")

A fair amount of Adigio projects have taken advantage of Acegi Security instead of container managed security. They just released version 0.7.

Dear Spring Community

I’m pleased to announce the Acegi Security System for Spring release 0.7.0 is now available from http://acegisecurity.sourceforge.net. The project provides comprehensive security services for The Spring Framework. You can read about the features in detail at http://acegisecurity.sourceforge.net.

There are many changes, improvements and fixes in release 0.7.0 (as listed at http://acegisecurity.sourceforge.net/changes-report.html). The major new feature areas are:

* Significant improvements to ACL security services
* AspectJ support (useful for instance-level security)
* Refactoring of ObjectDefinitionSources (especially useful for web URI
security)
* Automatic propagation of security identity via RMI and HttpInvoker
* Integration with Servlet Spec’s getRemoteUser()
* Refactoring of Contacts sample to use the new ACL security services
* Additional event publishing (now includes authorisation, not just
authentication)
* CVS restructure to use Maven as the build system
* A new project web site with FAQs, links to external articles etc

The new ACL security services deserve special mention, as they make it possible to develop applications that require complex instance-based security without any custom code. The entire configuration of such applications can be declared in the IoC container using standard Acegi Security services, so this should help significantly improve architecture and development time.

As per the Apache APR project versioning guidelines, this is a major release. We expect the next major release will be 1.0.0, although release 0.7.0 should be considered stable enough for most projects to use. There are detailed upgrade instructions included in the release ZIP and on the Acegi Security home page.

For Maven users, Acegi Security’s latest JARs are available from http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. We will also be adding release 0.7.0 and above to iBiblio.

We hope you find this new release useful in your projects.

Best regards
Ben

The top two posts on TheServerSide are:

• AspectJ and AspectWerkz Merge Forces
• JDO 2.0 Public Review Ballot

These give a glimpse at the good and the bad side of the Java community.

On the ‘good’ side we have the AOP news. Here we have two communities coming together for the greater good of the overall community. There isn’t the politics, nor the egos of “my app is better than yours”. They got together and talked about how they could work together and end up with a merger which is going to change AOP forever.

On the ‘bad’ side we have the JDO 2.0 ballot news. Here we have politics getting in the way. There are JDO users who are desperate to get JDO 2.0 implementations into their hands. They need it to take care of their business. Take a look at the vendors who went against the spec, and those who are for it.

I was optimistic, yet worried at the same time, about the EJB 3 / JDO 2 news that came out. It appears that some people are using that news as a way to hold back the JDO 2 spec. A lot of people have spent a LOT of time on that work, and our users deserve it right now.

P.s. I really liked Aslak’s quote regarding the AOP merger:

Forking seems to be more common than merging in the OSS world. This is great news. I wish you good luck.

I understand that a lot of standards end up being lowest common denominators. That is one of the issues with design by commitee.

However, I wish that the standards would have defined hooks that allow you to write code which uses the standard but adds on functionality.

Take the Servlet API for an example. This is one of the better APIs in J2EE. It is pretty darn portable. I try really hard to be able to have a .war that can be placed in a container and have it just run, but this isn’t always the case. If I have to open up a server.xml I think I failed :)

One example is Container Managed Security. Their are a couple of features that I really wish were in the spec. How about the ability to LOG OUT (not just nuking the session!). What about enhancing the security piece?

Take a login box. Form-based security allows you to setup a username and password and get authentication/authorization going. However, what if you want to do something like a ‘Remember me?’ check box, or the security image that I talked about last week.

Since the spec doesn’t have any hooks, and doesn’t easily allow a filter to kick in before the security piece, this becomes really tough. Well, on some servlet containers. Remember Me? functionality is built into Resin. I don’t have to do a thing. But, unless I know that I want to only run on Resin, I am kinda stuck.

I said before that I wanted to be able to create a .war file that runs in any container. To do this now I use another system for handling security. Trying to get around the CMS system is more trouble than it is worth. Is there a nice programatic API to log someone in and out? No.

For this reason I end up using something like Acegi Security for Spring.

Come on guys, give me some hooks!

And, let’s not get started on JAAS and how there isn’t a standard API to create users/groups in the system! Argh!

Kirk talks about the new regionMatches(..) methods available in the Java 5 String class.

There were questions on readability, and Kirk has a benchmark to proove the micro-performance.

I think the methods definitely harder to grok at first, and there is room for helper methods (e.g. in the first case: foo.startsWithIgnoreCase(bar)).

Case-folding startsWith()

If you

Kirk talks about the new regionMatches(..) methods available in the Java 5 String class.

There were questions on readability, and Kirk has a benchmark to proove the micro-performance.

I think the methods definitely harder to grok at first, and there is room for helper methods (e.g. in the first case: foo.startsWithIgnoreCase(bar)).

Case-folding startsWith()

If you

CP has talked about porting web app security between different application servers.

Whenever I read about these things, I wish that the specs would cover more, so we didn’t have to do this kind of infrastructure work.

The Servlet spec does a good job and giving us portability among app servers (unlike the EJB experience), however there is still room for improvement.

You can’t just drop a war file in, if you are doing wacky security stuff. It would be nice if this info could be put in the standard, so we COULD. Cookie auth should be a flag that you can just turn on. There should be a standard Realm interface which you can extend and tie together in the web.xml to handle the authentication, etc etc. All should be pluggable, and defined in one place.

J2EE always seems to only go part of the way there when it comes to items like this. Another example is how JAAS allows you to have pluggable authentication/authorization, but how about a standard was to actually manage users? How about a standard createUser(…)/edit/delete?

This is what we have available in PAM on Unix, and we want it at an API level in J2EE!

After hearing more about EJB 3, and talking to various people, why are we putting dependency Injection semantics in an EJB spec?

I can see one reason: “Let’s just get EJB 3 done”

This is a reason for not splitting the persistence API into a truly seperate JSR (although it IS mean to be a seperate spec/tck/runtime).

Dependency injection is a very generic concern, and one that should be shared throughout a bunch of specs. One tiny JSR could flush out the semantics
of dependency injection, and end up with javax.dependency.*.

Then EJB 3 would specify that “When you @Inject a transaction manager…. you must do X”. A future Servlet spec could do the same thing for their resources, etc etc.

Also, lightweight containers would have the option of groking these annotations too, without needing some ejb.jar.

Wouldn’t that be nice?

A lot of people in the community have been bugging Sun that they need to shake off the “Java == the language” view, and think more about the platform.

Tim Bray definitely saw this, and he pulled together a summit between top dynamic languages folk, and the main Sun Java players.

As soon as I heard about the summit I was really excited. When smart people get together good things happen. And it sounds like they did. Hey, there was even talk of adding an opcode here and there if it really made sense!

On Tuesday a summit was held at Sun, “with a few of our internal Java leaders, and on the dynamic-languages side, Larry Wall and Dan Sugalski (Perl and Parrot), Guido van Rossum, Samuele Pedroni and Sean McGrath (Python), and James Strachan (Groovy)”.

There were a couple of action items to report back on this or that, but the take-aways were pretty clear. For my money, the important thing about the meeting was bridge-building; the dynamic-language guys now know who to shout at in Javaland, and the Java guys know who in dynamic-language land to pester about what works and what doesn

Poor Pat asked Mark Roth of Sun to not jump in a take peoples syntax.

The problem is that once JSP (via JSTL) says “${foo} will resolve to X”. Other frameworks don’t get a look in. Pat was worried that #{..} would be eaten up yet and OGNL uses that for maps and such!

Matt Raible was on the chat session with Mark Roth and asked these questions:

I asked the following question as part of the chat:

Is there any chance that web frameworks (like WebWork) could override the default settings for the EL? So ${myForm} can look in areas other than page/request/session/application scope – i.e. WebWorks’s ValueStack?

It looks like this *is* going to be a part of JSP 2.1 – from Mark Roth:

JSP 2.1 is not only concerned about supporting Faces. We also want to support other frameworks. the new unified EL 2.1 API supports the concept of a pluggable VariableResolver (similar to the one that Faces has) which allows you to plug in your own logic for how variables like ${myForm} are resolved. So yes, this will be supported.

Imagine that? Pluggable Resolvers? Now we can live nicely together.

Note to Self: Write a nasty revolver which does weird things with ${} and get it somewhere to confuse people on projects:

Why does ${foo} print out SO YOU WANTED SOME FOO DID YAH! instead of the value?

The Apache DB group voted on a new JDO proposal. The new proposal spells out a place for some serious JDO work to happen.

It has been brought together with leaders in the Apache, other open source, and JDO worlds:

• Abe White, SolarMetric, JDO expert group member
• Brian McCallister, OJB committer
• Craig Russell, Sun, JDO Specification Lead
• Dain Sundstrom, GlueCode, Geronimo committer
• Erik Bengtson, JPOX committer
• Geir Magnusson, GlueCode, Geronimo committer
• Michael Bouschen, JDO expert group member
• Michelle Caisse, Sun, JDO TCK developer
• Patrick Linskey, SolarMetric, JDO expert group member
• Victor Kirkebo, Sun, JDO TCK developer

There are six initial subprojects envisioned:

• JDO 1.0 API
• JDO 1.0 Reference Implementation
• JDO 1.0 Technology Compatibility Kit
• JDO 2.0 API
• JDO 2.0 Technology Compatibility Kit
• JDO 2.0 Geronimo integration

I witnessed a lot of good talk at ApacheCon, and I am happy to hear that it is coming to fruition. With these fine blokes behind it, I am hopeful for a top notch JDO implementation with an Apache brand.

Someone already asked “Doesn’t OJB support JDO?” to which Brian McCallister replied:

OJB supports a JDO interface via a plugin to the JDO 1.0.X reference implementation (which is SCSL, non-commercial variant) so is basically useless right now. This same RI is part of the initial codebase for this project, so the OJB JDO 1.0.X interface can actually become useful =)