You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/09/02 12:28:48 UTC
[RT] Servicing/Composition
I have followed the discussion regarding how to provide
dependencies to a component - i.e. do we do it via a
ServiceManager, do we use setter methods or do we
use constructors (like MicroContainer)?
-oOo-
I has a little RT regarding how one could use attributes to
pass dependencies. Two ways:
Via Constructor
---------------
This is based on allowing attributes to be added not just to
methods and constructors, but to parameters as well.
public class MyComponent {
/**
* @@.std RequireDependencyAttribute ( "standard" )
* @@.err RequireDependencyAttribute ( "error" )
*/
public MyComponent( OutputTarget std, OutputTarget err ) { ... }
}
Then a container can get attributes for each constructor parameter
and use those to figure out what component to pass in.
(Yes, when you not only just have a hammer, but manufacture hammers,
all problems look like nails...)
Random question - are attributes inherited here?
Via Field
---------
The AccessibleObject.setAccessible method is cool. It allows you to
access private fields if the security manager says so (this is how
the serialization process can serialize private fields via reflection).
This means we can directly populate the fields of a component:
public class MyComponent {
/**
* @@Dependency
* @@RequireDependencyAttribute ( "standard" )
*/
private OutputTarget standard;
/**
* @@Dependency
* @@RequireDependencyAttribute ( "error" )
*/
private OutputTarget error;
}
A container can now get attributes for all fields (even the private
ones)
and set the dependencies just after invoking the constructor.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Servicing/Composition
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> 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
RE: [RT] Servicing/Composition
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> Leo Sutic wrote:
> > /**
> > * @@.std RequireDependencyAttribute ( "standard" )
> > * @@.err RequireDependencyAttribute ( "error" )
> > */
> > public MyComponent( OutputTarget std, OutputTarget
> err ) { ...
> > }
>
> I still really like:
>
> public MyComponent( OutputTarget standard, OutputTarget error
> ) { ... }
>
> (note: lack of attributes) allowing you to do away with the
> specification of the attributes at all here (the information
> you need is already there: its the parameter name).
I just wanted to throw in *some* way of specifying *some* additional
requirements for the dependency besides the type.
Maybe parameter name + attributes is the way to go. But I prefer not to
encode
much meaning in the parameter name - what if you want a standard
OutputTarget
and a standard (as opposed to secure) SocketManager?
> Hacked that together based on
> commons-sandbox-attributes (those dumb java .class files don't record
> the parameter name), but currently too ugly to submit a patch.
Submit it when you want. Sometimes it is better to just get the code
in than to wait for perfection...
> hmmmmmm.....potentially neat.....how feasible is it to run something
> like this in a J2EE or servlet container?
Depends on security settings. I'm not sure, but I think that by default
you can do anything to objects you yourself create. It's only when you
try to do funny stuff of objects you don't "own" that the
SecurityManager
throws a fit.
> 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.
Since the container does the setting, it can to all validation
neccessary.
> Another concern: how expensive is field reflection in comparison to
> constructor reflection? I can imagine more than a few
> differences there...
I don't know. Anyone?
I'm sorry if my answers are just too damn short - gotta run.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Servicing/Composition
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> /**
> * @@.std RequireDependencyAttribute ( "standard" )
> * @@.err RequireDependencyAttribute ( "error" )
> */
> public MyComponent( OutputTarget std, OutputTarget err ) { ... }
I still really like:
public MyComponent( OutputTarget standard, OutputTarget error ) { ... }
(note: lack of attributes) allowing you to do away with the
specification of the attributes at all here (the information you need is
already there: its the parameter name). Hacked that together based on
commons-sandbox-attributes (those dumb java .class files don't record
the parameter name), but currently too ugly to submit a patch.
Still, IMVHO it is the future of COP! (until I find myself a new pet
idea, which I'm trying to do every week)
> Random question - are attributes inherited here?
I'd say not. Constructors aren't inherited either.
---
> 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.
> A container can now get attributes for all fields (even the private
> ones) and set the dependencies just after invoking the constructor.
Another concern: how expensive is field reflection in comparison to
constructor reflection? I can imagine more than a few differences there...
g'night!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org