support for avalon components

The attachment is an early version of a ComponentAdapter, ComponentAdapterFactory, and some support code, that allows one to run avalon-framework ("type 1") components inside PicoContainer. While the code /might/ work, there are no tests yet (because most of it was copied from a custom container project whose tests are not so easily ported). I'm currently working on porting existing tests for this code, but wanted to give a preview and solicit some early feedback.

this is a fixed version with a basic integration test that shows things work. That'll be all for today.

Hi Leo,

while I would "naturally" have chosen also this name, I am not sure, if we are allowed to use "Avalon" in a "Nano Avalon" brand. Comments?

Alternatives:
Nano Mist
Nano Morgaine
Nano Navalon (too close ?)
Nano Picalon (since you depend on Pico only, are you ??)

Regards,
Jörg

Microsoft uses it. So why can't we?

Joerg – good point. We will be able to use it when a release under the 2.0 license is out.
Aslak – because of the apache license, v1.1, this used to be messy. The relevant snippets from http://www.ibiblio.org/maven/avalon-framework/licenses/LICENSE.txt are

• 3. The end-user documentation included with the redistribution,
• if any, must include the following acknowledgment:
• "This product includes software developed by the
• Apache Software Foundation (http://www.apache.org/)."
• Alternately, this acknowledgment may appear in the software
• itself, if and wherever such third-party acknowledgments
• normally appear.
  *
• 4. The names "Jakarta", "Avalon", and "Apache Software Foundation"
• must not be used to endorse or promote products derived from this
• software without prior written permission. For written
• permission, please contact apache@apache.org.

version 2 of the apache license contains none of that mess (just an attribution clause), so when a new revision of avalon framework is released (which will probably happen before this bit of code is ever released), the problem will go away.

oh, by the way, someone already sent me a few patches privately, so you'll really want to hold off committing this until I get that in place. I think I need to fix a license header or two as well (always the friggin' license crap :/).

sorry for the noise, but I'm just used to "release early, release often", as in, at least once every hour of work. This latest patch has all the simple tests written (and some bugs found), proper license headers, and near-full javadocs. To run the tests and build the jar....

1) cd picocontainer/java/picocontainer
2) cvs up -Pd
3) maven jar:install
4) cd ..
5) unzip nanocontainer-avalon-1.0-alpha-1-dev_v3.zip
6) cd tck
7) maven jar:install
8) cd ../avalon
9) maven jar:install

it should be clear how to use stuff from the BasicIntegrationTestCase.

and with v4 of this patch we're up to 100% test coverage, almost no javadoc errors, and reasonably readable, organized, and documented code (IMHO). I'm not going to touch this anymore for a week or so; would be real happy if someone found time to commit it :-D

This is very forging right Leo?

Phoenix used to barf if a comp tried to get a dependanct comp in the service() method that had not previously (externally) been declared as a need.

You're not checking the .xinfo file or the Merlin equiv are you? You're just making all the containerized componets avalable to the Avalon comp right?

I'm very impressed with this. However I have a question ... do we really need it? Personally I am busy moving all of my Avalon using code to ctor injector. There are Spice components that give me the equiv from Avalon-Cornerstone. I just don't need Avalon anymore.

Do you have a real case dude?

Alsom we should try to minimise class/package names containing the word Avalon as it is protected by Apache (refer 1.1 license that were distributed by Apache with Avalon).

Hi Paul,

well, at least I may have the need to include Leif's instrumentation into my application. Since I did not have a closer look at the code and how tight it is integrated with Avalon, so I am glad, that Leo did this work for me ...

IMHO it does not hurt to have an Avalon wrapper even if it does not support currently the xinfo and Merlin stuff. But it might offer a migration path for other users especially if you look at the current discussions in Avalon. If they get used to Pico, they will refactore and picofy their Avalon components anyway <g>

Concerning naming, there are already some suggestions here in JIRA ...

Regards,
Jörg

> This is very forging right Leo?

forging? What do you mean?

> Phoenix used to barf if a comp tried to get a dependanct comp in the
> service() method that had not previously (externally) been declared
> as a need.

no such thing happens here. There's no dependency checking other than what pico provides. Metadata is not checked nor respected, nor are interfaces like ThreadSafe or SingleThreaded. I've tried to structure the code in small pieces so that checks like against .xinfo could be added if someone needs it, but I'm not going to do it.

> You're not checking the .xinfo file or the Merlin equiv are you?
> You're just making all the containerized componets avalable to the
> Avalon comp right?

yep. The only avalon bit depended upon (and supported) is the basic avalon-framework; it should be obvious why we need that dependency :-D. One neat trick is using XStream to convert config beans to Configuration objects; that's the other dependency. I think its worth it.

> I'm very impressed with this.

thanks!

> However I have a question ... do we really need it? Personally I am
> busy moving all of my Avalon using code to ctor injector. There are
> Spice components that give me the equiv from Avalon-Cornerstone. I
> just don't need Avalon anymore.

a lot of people are not in that position :-D

> Do you have a real case dude?

Yep. For example,

http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/
http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-fulcrum/
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/

have some components that I want to use in a picofied application, and that other people want to use. There's dozens and dozens of avalon components out there in production that people would like to drop in (the binary) and use it with picocontainer.

> Alsom we should try to minimise class/package names containing the
> word Avalon as it is protected by Apache (refer 1.1 license that
> were distributed by Apache with Avalon).

yeah, with 2.0 license it should be okay though. Probably best to change it though just to be on the safe side. How about org.nanocontainer.type1? (and Type1Util, Type1Adapter, ...) I don't particularly care, as there should be a frontend that makes it transparent anyway.

Like I said on the mailing list, if you have doubts about putting this in nano, it can be hosted elsewhere, no worries, just say the word. I just think that having something generally usable "close to the source" will make the life of a lot of users a little easier.

Changes:

• removed use of the TCK kit (test coverage still 100%)
• renamed package from o.n.avalon to o.n.type1, and renamed maven project and directory to match
• renamed classes and methods from Avalon to Type1
• bump version

May I add this? Please assign me ... though I would not use type1, since we exchanged in all our docs the "type X" definition and even renamed CICA and SICA accordingly. So what about picalon?

in summary: name is not important enough to waste bandwidth on.

Joerg wrote:
> May I add this?

I'd like to do that, actually :-D

> Please assign me ... though I would not use type1, since we exchanged in all our docs the "type X" definition and even renamed CICA and SICA accordingly.

What's in a name? You think this matters a lot? I think its more important to us (developers) we understand what it means than to the average user (who should be isolated from most terminology anyway).

The nice thing about Fowler's article is that it has this descriptive name for dependency injection, namely dependency injection. No such thing for the old patterns. Something similar for avalon might be dependency provision, but that is too generic (injection is provision), and also not quite fitting, since avalon also splits out the lifecycle into many small pieces.

Until someone figures out a generic term for "type 1" IoC that is still unique enough so it is clear that this is about IoC, I think we're stuck with it.

> So what about picalon?

I don't like having lots of names all that much. I think its a lot more confusing than having just 1 or 2. But, no biggie, if you think a non-descriptive name is better, I can go and change the package names again :/

>in summary: name is not important enough to waste bandwidth on.

> I'd like to do that, actually :-D
First official act <bg>

> What's in a name? You think this matters a lot?
Well, if you look at Aslaks refactorings concerning names ... )

[snipped Fowler part]
IIRC he created some term like Interface injection. Unfortunately ever IoC of this type will need an unique adapter though. OTOH how many do we have despite Avalon (or not build on top of it) ?

> Until someone figures out a generic term for "type 1" IoC that is still
> unique enough so it is clear that this is about IoC, I think we're stuck with it.

Isn't Niclas/Stephen nearly ready with the release? As you've already pointed out the new license would allow the usage of "Avalon". Personally I would not like having a Nanocontainer-type1 component, but I am not going to argue any further. Maybe our despots can make a decision ... c'mon guys, make your job

[snip]

Regards,
Jörg

We have names that replace type1 :- http://picocontainer.org/Inversion+of+Control+Types

"Contextualized dependency lookup"

I'm still cool on Avalon support

Can we close this issue? Isn't the code in CVS?

If nobody objects, I'll rename the project to nanocontainer-avalon again. Avalon is released with the new ASF 2.0 and it is no longer an issue to use tha name. Additionally - since type 1 injection is tied to framework specific marker interfaces - it does not make sense to use a generic name like "type1" or "club".

+1 to rename type -> avalon.

I think it should be renamed to org.nanocontainer.avalon too

Renaming done.