configuring jxta via the ext:config library is trivial. using ext:config one can specify desired deployment models declaratively via profiles.

most applications these days include configuration of some sort. further, it is quite common to specify configuration data via xml. nothing new here.

the ext:config profile is yet another xml structure and as such applications that wish to leverage the conviences profile offers must mechanisms to create and/or manipulate this structure, likely foreign to the hosting application. further, it is quite likely that within the hosting applications native configuration structures, some if not all of the needed ext:config profile can be extracted. xml code slingers don't flinch at this commonplace practice. well, most don't.

alex milowski has augmented the ext:config work flow by pre-processing his applications native configuration structures with an xslt transform thereby creating the derived and specialized profile as a very late binding.

very cool! this further eases jxta configuration in general for a significantly large class of jxta applications. so cool, in fact, that we have an open issue to simply add an optional xslt style sheet to the relevant Profile methods to perform this transform within ext:config, further lessening the jxta configuration overlap into a hosting applications code space.

MyJXTA :: use it - learn it - do it

Java == platform independence
XML == application independence
JXTA == network independence

Secure End-to-End Computing

in my ears: Bloc Party/Silent Alarm/Pioneers