ant elder wrote:
I think its a interesting idea. Perhaps it is true that the current
SCA mechanisms are sufficient but this does have some appeal (to me
anyway) even if thats from a fun coding challenge perspective.
From the list below of issues:
1. - Tuscany knows all the artifacts in a contribution so we can
easily get all the classes in a package and introspect those for SCA
annotations
>
Good point. Contributions can also import classes from other
contributions, but Tuscany could find out about those classes as well.
2. - Tuscany is also in control of all the class loading so we can
manipulate the byte code with asm or cglib (these are already used by
the Tuscany core runtime) to add constructor interceptors to do the
things like the reference proxy injection, or perhaps use AOP with
aspectj.
>
This is possible but there's a further complication because these objects
are being instantiated by the application, not by Tuscany. This means
that the generated bytecode would need to call a Tuscany runtime API
under the covers to say "I belong to service X, so please inject me with
all the references and properties that service X defines." This is
similar to the SCAInjector that Sebastien has proposed.
3. - I'm not sure i follow this point, what is it about? And is the
main class really needed or could it be optional and when its not used
have all the classes found with @Service annotations used to make up
an implementation with multiple services?
If all the application classes are having their bytecodes manipulated
as described in point 2 above, then my point 3 doesn't apply. It would
apply if Tuscany was only getting control when the "main" class (i.e.,
the class with the @Service annotation) is being instantiated.
The "main" class is needed because <implementation.java> names a single
class. If this were extended to allow multiple classes to be named,
then it wouldn't be necessary to have a "main" class.
Using the approach described above, I can see that it would be possible
to make this work. I'm still not convinced that the benefit is worth
the complexity.
Simon
...ant
On Tue, Sep 21, 2010 at 10:52 PM, Simon Nash <[email protected]> wrote:
Millies, Sebastian wrote:
Hello there,
I have an idea for a Tuscany extension. Would it not be possible to
introduce an additional attribute "package" on the implementation.java
element, the purpose of which would be to specify all classes in
one (or more) Java package(s) as collectively making up the component
implementation. Tuscany could then inject proxies for the referenced
services at any point where the @Reference annotation is used in any
class of the packages. Similarly for @Context etc. (The value of the
"class" attribute would still denote the main class, which provides
the component's external interface.)
Would this make sense in your opinion? Would it be hard to implement?
I think it would be hard to implement because:
1. Tuscany would need a way to enumerate all the classes in the
package so that it could find all the @Reference annotations.
2. Tuscany would need to discover the runtime instance relationships
between all these application classes so that it could find the
right instance objects on which to perform the injections.
This is just about impossible because the "non-main" objects are
instantiated by the application and not by Tuscany.
3. When Tuscany creates the instance of the "main" class, the other
application instance objects that need to be injected might not
exist at that time.
I think the current SCA mechanisms are sufficient to allow application
classes to propagate these references to wherever they are needed, and
I think that handling such propagation is best left to application code.
Simon
-- Sebastian
-----Original Message-----
From: Simon Nash [mailto:[email protected]]
Sent: Tuesday, September 21, 2010 8:26 PM
To: [email protected]
Subject: Re: Q: Best practice for making service references available
in a component?
Millies, Sebastian wrote:
Hello there,
this is a question about coding style. SCA components are coarse
grained,
i. e. the actual component implementation can consist of many
classes, only
one of which is defined as _the_ component implementation class in
the composite
XML. It is only on this class that annotations like @Reference can be
used to
inject dependencies to other services. It is likely, however, that
the referenced
services really need to be called from one of the other classes in
the component
implementation.
How do you pass the values of these reference variables to those
ordinary Java
classes? Is there a special "SCA way" of doing this, perhaps making
these References
globally available in a component, or do you just use normal Java
programming idioms
like property setters, or constructor/method parameters?
-- Sebastian
There isn't any specific SCA way of doing this. You can treat
the injected proxy as a regular Java object and pass it around
however you wish. However it's useful to bear in mind that SCA
offers 3 different ways to obtain the reference proxy:
as a constructor parameter
as a setter parameter
as an injected field
Depending on how you want to pass the value around, one or other
of these might be more appropriate.
Simon
