What Comes after Configuration?

The soon be released JXTA JSE 2.4 "Umqhusho" provides some exiting enhancements to one of JXTA's long term weak areas, configuration. Users and developers have been complaining for a long time that the process of determining and specifying configurations for JXTA peers is inflexible, complicated, inscrutable, inconvenient, buggy and probably a few more negative things. With the newest builds of JXTA this is hopefully changing.

We've been making steady progress for the last couple of releases to improve developers' initial experience with JXTA and fixing configuration is a big part of the changes. The JXTA 2.3.7 release saw important improvements to the ext.config JavaDocs, a few critical features such as private peer group support along with some critical bug fixes and some enhancements to how the home directory JXTA JSE uses is specified. The JXTA 2.4 release continues the progress with significant improvements to ext.config's reliability, better default handling and improvements to the clarity of profiles.

The JXTA JSE 2.4 release introduces a new programmatic configuration class, NetworkConfigurator. This class provides a simplified, single class, programmatic configuration API. While NetworkConfigurator lacks some of the extensibility, functionality and features of ext.config it is probably a lot easier to understand for the new JXTA developer. NetworkConfigurator was originally developed as ConfigurationFactory, a utility for the JXTA sample programs so that users could run the tutorials out of the box. Users found it useful and told us that it fit their configuration needs. We would like to thank all of those who contributed code, reviews and feedback for this new feature.

We've also added two new classes which provide applications more flexibility and simpler control over how JXTA is started, WorldPeerGroupFactory and NetPeerGroupFactory. PeerGroupFactory is still available, though it is now deprecated. Over the next couple of months we will be updating the sample code, JXTA tutorials and Programmers Guide to use the new Peer Group constructors.

The title of this entry is meant to be a bit ironic. Too frequently we've heard that the problems that new users encountered with JXTA configuration and startup prevented them from ever getting fully exposed to JXTA. This has been a big disappointment, and it's something we have heard too many times. The good news is that hopefully our recent efforts at fixing the problem have begun to pay off. By a couple of measures the new user experience with JXTA is improving--the most obvious evidence is the questions being asked by users on the JXTA mailing lists. Configuration and initial setup issues have begun to diminish in proportion to questions about the core JXTA APIs. This is a good thing!

The second meaning of this entry's title is to discuss what's next. Firstly, everything is not "done" for improving the configuration and startup process. There have been recent discussions regarding how to abstractly configure JXTA services, some exciting work which performs JXTA configuration using Spring, and a great discussion regarding building a JXTA container which would run packaged & configured JXTA based services. Secondly, I am hoping that for the next JXTA JSE release, scheduled for October 2006, that we will be able to improve the Peer Group creation and instantiation process, the PeerGroup.newGroup() methods. The primary goal is to provide a per-peer group configuration capability, but we are also looking to simplify and clarify the process of creating, publishing and instantiating peer groups. If you are interested in this topic consider getting involved by adding comments, issues and yourself as a cc: to Issue #1545

So, what comes after configuration? Hopefully, lots of JXTA!


Good stuff. Reflecting on Vanessa's Spring contribution - I think this is going to be very important work, and it certainly appears to be a first for the platform. Spring is my first priority these days - learn it and learn to think in it. So I thank Vanessa for injecting Spring into JXTA. Mark

Posted by Mark Petrovic on June 19, 2006 at 08:33 AM PDT #

I think the most important bug fixes are the ones concerning data transmission on jxta sockets and bidipipes. I've found that lost of data quite annoying and, as far as I know, that kind of bug is still arising from time to time. The performance of this layer would be a big plus too, but I would not bother if JXTA transmission is far slow if I could assure that it is really reliable.

Posted by jacques defarge on June 19, 2006 at 11:59 AM PDT #

Post a Comment:
Comments are closed for this entry.



« June 2016