You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2009/10/06 06:17:12 UTC
Issues running Tuscany applications in Google AppEngine
Below are the list of issues I found while getting the store scenario
working in Google AppEngine:
- The JSON-RPC Binding is using Commons HTTP Client, which spawn
threads which is not allowed in the AppEngine environment. I have a
local version of the binding using only URLOpenConnection, but it
would be good if we could have a extension point and provide a way to
plug a alternative implementation that is single threaded.
- The JSON-RPC reference wasn't properly setting the JSON databinding
in the service contract, which I have fixed and will be committing
this soon.
- The JAXBContext is a restricted class in the Google AppEngine
environment, to avoid application loading issues I had to remove
tuscany-databinding-jaxb and tuscany-interface-java-jaxws dependencies
from my application, which were causing databinding problems as
core-databinding have hard dependencies on processors from these
modules. We should revisit this and make things more flexible :
--- a/modules/core-databinding/src/main/java/org/apache/tuscany/sca/core/databinding/module/DataBindingModuleActivator.java
+++ b/modules/core-databinding/src/main/java/org/apache/tuscany/sca/core/databinding/module/DataBindingModuleActivator.java
@@ -50,7 +50,7 @@ public class DataBindingModuleActivator implements
ModuleActivator {
DataBindingExtensionPoint dataBindings =
registry.getExtensionPoint(DataBindingExtensionPoint.class);
TransformerExtensionPoint transformers =
registry.getExtensionPoint(TransformerExtensionPoint.class);
- XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
+ //XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
FaultExceptionMapper faultExceptionMapper =
registry.getExtensionPoint(UtilityExtensionPoint.class).getUtility(FaultExceptionMapper.class);
@@ -82,10 +82,10 @@ public class DataBindingModuleActivator implements
ModuleActivator {
FactoryExtensionPoint modelFactories =
registry.getExtensionPoint(FactoryExtensionPoint.class);
JavaInterfaceFactory javaFactory =
modelFactories.getFactory(JavaInterfaceFactory.class);
// Add the WebServiceInterfaceProcessor to mark the interface remotable
- javaFactory.addInterfaceVisitor(new WebServiceInterfaceProcessor());
+ //javaFactory.addInterfaceVisitor(new WebServiceInterfaceProcessor());
// Introspect the data types
javaFactory.addInterfaceVisitor(new
DataBindingJavaInterfaceProcessor(dataBindings));
- javaFactory.addInterfaceVisitor(new
JAXWSJavaInterfaceProcessor(dataBindings, faultExceptionMapper,
xmlAdapterExtensionPoint));
+ //javaFactory.addInterfaceVisitor(new
JAXWSJavaInterfaceProcessor(dataBindings, faultExceptionMapper,
xmlAdapterExtensionPoint));
javaFactory.addInterfaceVisitor(new
WrapperJavaInterfaceProcessor(dataBindings));
RuntimeWireProcessorExtensionPoint
wireProcessorExtensionPoint =
registry.getExtensionPoint(RuntimeWireProcessorExtensionPoint.class);
- Several commented out databindings transformers had to be re-enabled
in order to properly transform to and from JSON. Enable all commented
databindings from
/modules/databinding/src/main/resources/META-INF/services/org.apache.tuscany.sca.databinding.PullTransformer.
Can we get them enabled with a lower/different weight so applications
without JAXB databinding just works ?
- Management classes are restricted in Google AppEngine environment,
and some of these classes are used by NodeImpl which is already
annotated with [FIXME] tags from Raymond. We should revisit this, but
it looks like commenting these management related code out of nodeImpl
had no visible side-effect.
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Issues running Tuscany applications in Google AppEngine
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Oct 6, 2009 at 11:56 PM, ant elder <an...@apache.org> wrote:
>
> You should be able to configure HTTP Client to not use multiple
> threads, have you looked at the HTTP Client doc? And we could control
> that configuration by defining tuscany specific attributes on http
> binding.
>
I looked at the docs, it seems that it has two types of connection
manager, a MultiThreadedHttpConnectionManager and a
SimpleHttpConnectionManager that is used by default. I have tried both
without success.
> I'm happy to help with the new http binding, would you like to work on
> it together?
>
Off course, if you provide variations of initializing the HTTP Client,
I could give it a try in the app engine and provide feedback... or you
could try and provide feedback, whichever is easier for you.
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Issues running Tuscany applications in Google AppEngine
Posted by ant elder <an...@apache.org>.
On Tue, Oct 6, 2009 at 5:38 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Tue, Oct 6, 2009 at 2:12 AM, ant elder <an...@gmail.com> wrote:
>> On Tue, Oct 6, 2009 at 5:17 AM, Luciano Resende <lu...@gmail.com> wrote:
>>
>>> - The JSON-RPC Binding is using Commons HTTP Client, which spawn
>>> threads which is not allowed in the AppEngine environment. I have a
>>> local version of the binding using only URLOpenConnection, but it
>>> would be good if we could have a extension point and provide a way to
>>> plug a alternative implementation that is single threaded.
>>>
>>
>> What I think would be a good approach is to update the http binding
>> for the draft http binding spec, implementing full support for
>> wireformats, operation selectors, and customizable plug points, and
>> then have the other http based bindings like jsonp and jsonrpc
>> delegate to the http binding runtime code. So the <binding.jsonp> is
>> just gets translated to a <binding.http> and whatever config
>> attributes the http binding needs to support jsonp.
>>
>> ...ant
>>
>
> Although I like the idea of having the binding-http supporting
> wireformats and operation selection to allow returning resources in
> different formats (e.g json, html, xml, etc)...and have this on my
> list of todos... this wouldn't solve the problem, right ? We still
> need a extension point to allow plug a "HTTP Client", which in most of
> cases will be the Commons HTTP one we are using, but when in AppEngine
> we would want a different one (single threaded based purely on
> URLOpenConnection)
>
You should be able to configure HTTP Client to not use multiple
threads, have you looked at the HTTP Client doc? And we could control
that configuration by defining tuscany specific attributes on http
binding.
I'm happy to help with the new http binding, would you like to work on
it together?
...ant
Re: Issues running Tuscany applications in Google AppEngine
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Oct 6, 2009 at 2:12 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Oct 6, 2009 at 5:17 AM, Luciano Resende <lu...@gmail.com> wrote:
>
>> - The JSON-RPC Binding is using Commons HTTP Client, which spawn
>> threads which is not allowed in the AppEngine environment. I have a
>> local version of the binding using only URLOpenConnection, but it
>> would be good if we could have a extension point and provide a way to
>> plug a alternative implementation that is single threaded.
>>
>
> What I think would be a good approach is to update the http binding
> for the draft http binding spec, implementing full support for
> wireformats, operation selectors, and customizable plug points, and
> then have the other http based bindings like jsonp and jsonrpc
> delegate to the http binding runtime code. So the <binding.jsonp> is
> just gets translated to a <binding.http> and whatever config
> attributes the http binding needs to support jsonp.
>
> ...ant
>
Although I like the idea of having the binding-http supporting
wireformats and operation selection to allow returning resources in
different formats (e.g json, html, xml, etc)...and have this on my
list of todos... this wouldn't solve the problem, right ? We still
need a extension point to allow plug a "HTTP Client", which in most of
cases will be the Commons HTTP one we are using, but when in AppEngine
we would want a different one (single threaded based purely on
URLOpenConnection)
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Issues running Tuscany applications in Google AppEngine
Posted by ant elder <an...@gmail.com>.
On Tue, Oct 6, 2009 at 5:17 AM, Luciano Resende <lu...@gmail.com> wrote:
> - The JSON-RPC Binding is using Commons HTTP Client, which spawn
> threads which is not allowed in the AppEngine environment. I have a
> local version of the binding using only URLOpenConnection, but it
> would be good if we could have a extension point and provide a way to
> plug a alternative implementation that is single threaded.
>
What I think would be a good approach is to update the http binding
for the draft http binding spec, implementing full support for
wireformats, operation selectors, and customizable plug points, and
then have the other http based bindings like jsonp and jsonrpc
delegate to the http binding runtime code. So the <binding.jsonp> is
just gets translated to a <binding.http> and whatever config
attributes the http binding needs to support jsonp.
...ant
Re: Issues running Tuscany applications in Google AppEngine
Posted by Raymond Feng <en...@gmail.com>.
1. Some of the transformers are used to convert the XML value of SCA
properties into the java type. We use JAXB for both simple java types and
complex types. The commented out transformers in the databinding module uses
java reflections to deal with Java/DOM conversion and they don't follow a
standard Java/XML mapping rules. To get around the Google App Engine
restrictions on JAXB [1], you can enable them with a higher weight like
90000 so that the JAXB ones take precedence.
2. The Java InterfaceVisitor, ClassVisitor and some data transformers are
added to the related extension points by code in the Module Activators. This
creates code dependencies in the core-databinding module. We should turn
them into declarative extensions.
Thanks,
Raymond
--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Monday, October 05, 2009 9:17 PM
To: "tuscany-dev" <de...@tuscany.apache.org>
Subject: Issues running Tuscany applications in Google AppEngine
> Below are the list of issues I found while getting the store scenario
> working in Google AppEngine:
>
> - The JSON-RPC Binding is using Commons HTTP Client, which spawn
> threads which is not allowed in the AppEngine environment. I have a
> local version of the binding using only URLOpenConnection, but it
> would be good if we could have a extension point and provide a way to
> plug a alternative implementation that is single threaded.
>
> - The JSON-RPC reference wasn't properly setting the JSON databinding
> in the service contract, which I have fixed and will be committing
> this soon.
>
> - The JAXBContext is a restricted class in the Google AppEngine
> environment, to avoid application loading issues I had to remove
> tuscany-databinding-jaxb and tuscany-interface-java-jaxws dependencies
> from my application, which were causing databinding problems as
> core-databinding have hard dependencies on processors from these
> modules. We should revisit this and make things more flexible :
>
> ---
> a/modules/core-databinding/src/main/java/org/apache/tuscany/sca/core/databinding/module/DataBindingModuleActivator.java
> +++
> b/modules/core-databinding/src/main/java/org/apache/tuscany/sca/core/databinding/module/DataBindingModuleActivator.java
> @@ -50,7 +50,7 @@ public class DataBindingModuleActivator implements
> ModuleActivator {
> DataBindingExtensionPoint dataBindings =
> registry.getExtensionPoint(DataBindingExtensionPoint.class);
> TransformerExtensionPoint transformers =
> registry.getExtensionPoint(TransformerExtensionPoint.class);
>
> - XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
> registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
> + //XMLAdapterExtensionPoint xmlAdapterExtensionPoint =
> registry.getExtensionPoint(XMLAdapterExtensionPoint.class);
>
> FaultExceptionMapper faultExceptionMapper =
> registry.getExtensionPoint(UtilityExtensionPoint.class).getUtility(FaultExceptionMapper.class);
>
> @@ -82,10 +82,10 @@ public class DataBindingModuleActivator implements
> ModuleActivator {
> FactoryExtensionPoint modelFactories =
> registry.getExtensionPoint(FactoryExtensionPoint.class);
> JavaInterfaceFactory javaFactory =
> modelFactories.getFactory(JavaInterfaceFactory.class);
> // Add the WebServiceInterfaceProcessor to mark the interface
> remotable
> - javaFactory.addInterfaceVisitor(new
> WebServiceInterfaceProcessor());
> + //javaFactory.addInterfaceVisitor(new
> WebServiceInterfaceProcessor());
> // Introspect the data types
> javaFactory.addInterfaceVisitor(new
> DataBindingJavaInterfaceProcessor(dataBindings));
> - javaFactory.addInterfaceVisitor(new
> JAXWSJavaInterfaceProcessor(dataBindings, faultExceptionMapper,
> xmlAdapterExtensionPoint));
> + //javaFactory.addInterfaceVisitor(new
> JAXWSJavaInterfaceProcessor(dataBindings, faultExceptionMapper,
> xmlAdapterExtensionPoint));
> javaFactory.addInterfaceVisitor(new
> WrapperJavaInterfaceProcessor(dataBindings));
>
> RuntimeWireProcessorExtensionPoint
> wireProcessorExtensionPoint =
> registry.getExtensionPoint(RuntimeWireProcessorExtensionPoint.class);
>
>
> - Several commented out databindings transformers had to be re-enabled
> in order to properly transform to and from JSON. Enable all commented
> databindings from
> /modules/databinding/src/main/resources/META-INF/services/org.apache.tuscany.sca.databinding.PullTransformer.
> Can we get them enabled with a lower/different weight so applications
> without JAXB databinding just works ?
>
> - Management classes are restricted in Google AppEngine environment,
> and some of these classes are used by NodeImpl which is already
> annotated with [FIXME] tags from Raymond. We should revisit this, but
> it looks like commenting these management related code out of nodeImpl
> had no visible side-effect.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/