Loom viability

Forgive me if parts of this message are redundant or have been answered 
before... I am new to this list.  If any part has been answered, please 
point me in the right direction.

When is a Loom release planned? My shop and I are what could be called 
"Phoenix refugees".  We have a large investment in the Phoenix 
platform.  One of the primary problems that I have observed with Avalon 
over the years is that it tends to drift towards "ivory tower" thinking 
quite often.  It seems that radical changes of direction happen 
regularly without a huge eye towards maintaining compatibility (this is 
just an observation... please don't flame me).  Just from browsing the 
JContainer site and the DNA library (which looks a lot like Avalon 
framework but without all of the silly package distinctions), it seems 
that this project is focused more on real-world problems than Avalon 
is/was.

With development on Phoenix ended, I need to come up with a migration 
path towards whatever the best solution is. I have been tracking Merlin 
for a bit, but I am uncomfortable with it for a number of reasons.

So, I am leaning towards adoption of Loom to preserve our existing 
investments and as a platform for the future.  However, I have been 
burned once by adopting pre-release Phoenix capabilities and I would 
like a clear statement of direction.

In addition to a direction, comments on the following points would be 
appreciated.

1.  In my environment, it is infeasible to introduce an entirely new 
"top level" container.  For a number of reasons (many of which are 
political instead of technical), it is easier to embed a system like 
Phoenix into an existing container (ie. servlet container) instead of 
hosting it standalone.  I know that Phoenix (even into the 4.1 branch) 
was not very good at this.  We accomplished it by creating a 
"SimpleAppEmbeddor" which managed all of the steps of assembling the 
minimum pieces of the kernel required to get a functional Phoenix 
system.  This implementation did not support JMX, the classloading 
semantics, security constaints or deployment of SAR files.  It simply 
ran off of the existing classpath and was parameterized with an 
assembly and a config file (no environment file).  We then provided 
bindings which allowed this SimpleAppEmbeddor to be easily brought up 
in a Servlet.  This light-weight implementation was so successful that 
we created a CLI version which allowed us to launch daemon processes by 
just providing the assembly and config file (again bypassing the SAR 
process).

The problem with this approach is that the APIs that SimpleAppEmbeddor 
relied on were Phoenix internal and changed constantly.  In addition, 
the dependencies of each of the kernel components was not documented, 
and they too changed frequently.

I think there is value to having a light-weight version of the 
container which is easily useable like this.  It lowers the bar for 
adoption and makes doing simple things simple.  If the application 
outgrows the confines of this limited environment, it could always be 
converted to a SAR and hosted in the larger Phoenix/Loom container with 
little re-engineering effort.

Are there any plans for supporting such a paradigm?  If not, are there 
plans for at least shoring up the internal Loom kernel structures so 
that a third party implementation such as this would be relatively 
stable from version to version?  Assuming you are not opposed to such 
an idea, would you care for code contributions that allowed Loom to be 
run in this embedded mode?

2.  One of the features which I believe made Phoenix attractive arrived 
in the 4.1 developer branch.  This was the notations around specifying 
maps or arrays of dependencies (appending [] or {} to the role).  It 
seems that the rest of the Avalon community is stuck in some kind of 
religious war revolving around whether ServiceSelector is evil and what 
to do about it.  I thought that the multi-dependency notation was a 
good solution to this problem that no one seems to like but clearly 
needs a solution.  Is this functionality sanctioned in Loom?  Are you 
planning any extensions to it?

3. It is clear that Loom and the JContainer project are intended to be 
complete forks of Avalon.  My observation is that DNA is analogous to 
Avalon framework (with much simplified names).  This is all well and 
good, but is there a commitment to keep Loom capable of hosting 
components/blocks written to the Avalon framework interfaces as opposed 
to the DNA interfaces?

BTW - I like how Loom only has a couple of dependencies.  It was 
getting night-marish keeping the Avalon/Phoenix/Excalibur dependencies 
straight.

Thanks for your time.
Terry Laurenzo