[jira] Commented: (NANO-69) support for avalon components

The following comment has been added to this issue:

     Author: Leo Simons
    Created: Fri, 23 Apr 2004 5:36 AM
       Body:
> 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.
---------------------------------------------------------------------
View this comment:
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=NANO-69&page=comments#action_18978

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=NANO-69

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: NANO-69
    Summary: support for avalon components
       Type: New Feature

     Status: Unassigned
   Priority: Major

 Original Estimate: 1 day
 Time Spent: Unknown
  Remaining: 1 day

    Project: NanoContainer

   Assignee: 
   Reporter: Leo Simons

    Created: Tue, 20 Apr 2004 9:42 AM
    Updated: Fri, 23 Apr 2004 5:36 AM

Description:
It would be nice if Avalon-Framework-compatible components could run inside a PicoContainer unmodified.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira