Help with proxies and component context's getInstance

[Rania Khalaf <rk...@watson.ibm.com>]

Hi everyone,

I am experimenting with adding XSLT as an implementation type (with a 
WSDL interface for now). I have looked at the javascript container and 
found it very helpful, but I have two questions about the use of 
ComponentContext and proxy factories.

Among other things, I have created :

public class XSLTComponentContext extends AbstractContext implements 
AtomicContext

In XSLT the components are stateless: you just run the whole stylesheet 
and return the result tree.

I am confused about what getInstance should return if one is dealing 
with a non-Java implementation type. The Java container returns the 
actual class that implements the component's Java interface and the 
javascript container returns a proxy from a proxy factory...

One option is to return what getTargetInstance returns (the XSLTInvoker) 
but that avoids the proxy chains so doesn't feel right... On the other 
hand, if i do something similar to what the javascript implementation 
does, then the result from locateService is something of class $Proxy37 
that has JDKInvocationHandler .. Not sure what one would do with that 
(?). Am I supposed to create my own proxy factory and plug it in somehow ?

Any insight appreciated into the right way to set up the proxies and the 
getInstance method so that a non-java implementation type that is 
stateless fits properly.


thanks!
Rania





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

Re: Help with proxies and component context's getInstance

[ant elder <an...@gmail.com>]

Hi Rania,

Probably the core guys can give you more insight into what you should be
doing, but comparing the Java and JavaScript code it looks like the
JavaScript code may be a little behind in keeping up with all the extension
changes.  Couldn't you make your XSLTComponentContext similar to the
org.apache.tuscany.container.java.context.JavaAtomicContext but use your own
XSLT ObjectFactory instead of the PojoObjectFactory?

Note also that there's been some doc written recently with a lot of detail
about writing new container extensions. Its not yet up on the website but
you can read it in the JIRA at:
http://issues.apache.org/jira/browse/TUSCANY-289

   ...ant

On 6/6/06, Rania Khalaf <rk...@watson.ibm.com> wrote:
>
> Hi everyone,
>
> I am experimenting with adding XSLT as an implementation type (with a
> WSDL interface for now). I have looked at the javascript container and
> found it very helpful, but I have two questions about the use of
> ComponentContext and proxy factories.
>
> Among other things, I have created :
>
> public class XSLTComponentContext extends AbstractContext implements
> AtomicContext
>
> In XSLT the components are stateless: you just run the whole stylesheet
> and return the result tree.
>
> I am confused about what getInstance should return if one is dealing
> with a non-Java implementation type. The Java container returns the
> actual class that implements the component's Java interface and the
> javascript container returns a proxy from a proxy factory...
>
> One option is to return what getTargetInstance returns (the XSLTInvoker)
> but that avoids the proxy chains so doesn't feel right... On the other
> hand, if i do something similar to what the javascript implementation
> does, then the result from locateService is something of class $Proxy37
> that has JDKInvocationHandler .. Not sure what one would do with that
> (?). Am I supposed to create my own proxy factory and plug it in somehow ?
>
> Any insight appreciated into the right way to set up the proxies and the
> getInstance method so that a non-java implementation type that is
> stateless fits properly.
>
>
> thanks!
> Rania
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>