avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [RT] Servicing/Composition
Date Wed, 03 Sep 2003 13:30:17 GMT


> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> 
> >     public class MyComponent {
> > 
> >         /**
> >          * @@Dependency
> >          * @@RequireDependencyAttribute ( "standard" )
> >          */
> >         private OutputTarget standard;
> 
> hmmmmmm.....potentially neat.....how feasible is it to run something 
> like this in a J2EE or servlet container? And on second thought, this 
> doesn't allow you to do any kind of validity checking in the 
> component. 
> Any kind of exception (likely, NPE) resulting from a 
> composition error 
> is not thrown during composition but on a method call. I think. Using 
> aspectwerkz or somethin' one could advise the field access 
> though.......
> 
> oh, and (same point again)
> 
>          /** @@Dependency */
>          private OutputTarget standard;
> 
> is just a /little/ more neat I think. When we get the meta 
> JSR stuff in 
> place (like, in 4 years, when JDK1.5 is a realistic 
> deployment target):
> 
>          private transient [Dependency] OutputTarget standard;
> 
> could become a reality.

I think it all boils down to how much you want to specify in a
dependency.
If all you want is an OutputTarget (no other requirements), then yes,

    /** @@Dependency */
    private OutputTarget standard;

is definitely the way to go. But in the case of - for example - wanting
a
secure SocketFactory, or a error OutputTarget or some other dependency
that
can't be completely described just by giving the type, then there must
be
some way to add these other requirements. That's why I put in the

     @@RequireDependencyAttribute ( "standard" )

in the example.

I'm against encoding requirements in the field name - just too high a
risk
of getting a namespace collision here...

Oh, and thanks for the comments!

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message