You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by lookman sanni <lo...@gmail.com> on 2009/08/12 00:08:01 UTC
Progress update: GSO09 Tuscany-->Android
*Blocking issues due to android platform*
- Thread.currentThread().getClassLoader() always return null on android.
To fix this, i had to pass dalvik classLoader from the client side to all
places in Tuscany's modules where classLoader is recquired.
- ClassLoader.getResources() doesn't work neither under android. Dalvik's
pathClassLoader may be a solution. But as we're working on a lightweight
system, it'll surely be heavy to open stream on about 43 services files
(needed to run calculator). Instead, i just set up system properties so that
each service name will represent a system property and it's implementation
class would be the property's value. This will involve no code refactoring
on tuscany's modules as for resolving services, system properties are
firstly checked.
- org.w3c.Node implementation under android doesn't contain
getTextContent method. I replaced all calls to it by getNodeValue().
*Current state*
Calculator-android can run till ContributionProcessor resolution. In other
words, definitions.xml loading's step is already performed. What I'm trying
to do now is to implement a an APKContributionProcessor for the new
PackageType.APK somehow like those existing for JAR and Folder
ContributionProcessors.
- APK structure: An archive uncompressable with any archiver, which
contain all resources attached to the sources, and a classes.dex file
resulting from the dexification of all java sources. I guess artifacts i'll
need to retrieve in the APKContributionProcessor will be the classes inside
the classes.dex file.
*Long term: perspective*s
Instead of continuing with the current host-android or host-embedded ( i
don't know yet what's exactly inside), i suggest we rewrite it like an
android application that'll setup needed system properties on a world
readable way ( to make it available to any other android application), and
bootstrap at build time resources files into a given directory on the
android system. These resources files will be needed in addition to system
properties as we need to provide a description of all services (classname,
servicename, url).
*The Calculator-android project*
The one existing is targeting an older version of android sdk. I've just
recreated a new project, by importing services sources from the sample
calculator.
*List of needed tuscany's modules for running calculator-android*
*assembly-xml
> assembly-xsd
> binding-sca
> binding-sca-xml
> contribution
> contribution-impl
> contribution-java
> contribution-namespace
> contribution-xml
> core
> core-databinding
> core-spi
> databinding
> databinding-jaxb
> definitions
> definitions-xml
> endpoint
> extensibility
> implementation-java
> implementation-java-runtime
> implementation-java-xml
> implementation-node
> interface
> interface-java
> interface-java-jaxws
> interface-java-xml
> monitor
> node-api
> node-impl
> policy
> policy-xml
> policy-xml-ws
> sca-api
> sca-api-extension
> workspace
> workspace-impl
> workspace-xml
> xsd
> *
*Services and implementations used*
*
*
org.apache.tuscany.sca.node.SCANodeFactory, ---->
org.apache.tuscany.sca.node.impl.NodeFactoryImpl,
org.apache.tuscany.sca.core.UtilityExtensionPoint, ---->
org.apache.tuscany.sca.core.DefaultUtilityExtensionPoint,
org.apache.tuscany.sca.work.WorkScheduler, ---->
org.apache.tuscany.sca.core.work.DefaultWorkScheduler,
org.apache.tuscany.sca.interfacedef.InterfaceContractMapper, ---->
org.apache.tuscany.sca.interfacedef.impl.InterfaceContractMapperImpl,
org.apache.tuscany.sca.contribution.ModelFactoryExtensionPoint, ---->
org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint,
org.apache.tuscany.sca.invocation.MessageFactory, ---->
org.apache.tuscany.sca.core.invocation.MessageFactoryImpl,
org.apache.tuscany.sca.core.invocation.ProxyFactoryExtensionPoint, ---->
org.apache.tuscany.sca.core.invocation.DefaultProxyFactoryExtensionPoint,
org.apache.tuscany.sca.core.ModuleActivator, ---->
org.apache.tuscany.sca.core.databinding.module.DataBindingModuleActivator,
org.apache.tuscany.sca.databinding.DataBindingExtensionPoint, ---->
org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint,
org.apache.tuscany.sca.databinding.TransformerExtensionPoint, ---->
org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint,
org.apache.tuscany.sca.databinding.jaxb.XMLAdapterExtensionPoint, ---->
org.apache.tuscany.sca.databinding.jaxb.DefaultXMLAdapterExtensionPoint,
org.apache.tuscany.sca.databinding.Mediator, ---->
org.apache.tuscany.sca.databinding.impl.MediatorImpl,
org.apache.tuscany.sca.interfacedef.java.JavaInterfaceFactory, ---->
org.apache.tuscany.sca.interfacedef.java.DefaultJavaInterfaceFactory,
org.apache.tuscany.sca.runtime.RuntimeWireProcessorExtensionPoint, ---->
org.apache.tuscany.sca.runtime.DefaultWireProcessorExtensionPoint,
org.apache.tuscany.sca.implementation.java.JavaImplementationFactory,
---->
org.apache.tuscany.sca.implementation.java.DefaultJavaImplementationFactory,
org.apache.tuscany.sca.context.PropertyValueFactory, ---->
org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory,
org.apache.tuscany.sca.context.ContextFactoryExtensionPoint, ---->
org.apache.tuscany.sca.context.DefaultContextFactoryExtensionPoint,
org.apache.tuscany.sca.provider.ProviderFactoryExtensionPoint, ---->
org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint,
org.apache.tuscany.sca.assembly.SCABindingFactory, ---->
org.apache.tuscany.sca.binding.sca.impl.SCABindingFactoryImpl,
org.apache.tuscany.sca.contribution.ContributionFactory, ---->
org.apache.tuscany.sca.contribution.DefaultContributionFactory,
org.apache.tuscany.sca.monitor.MonitorFactory, ---->
org.apache.tuscany.sca.monitor.impl.DefaultMonitorFactoryImpl,
org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessorExtensionPoint,
---->
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint,
org.apache.tuscany.sca.contribution.processor.StAXAttributeProcessorExtensionPoint,
---->
org.apache.tuscany.sca.contribution.processor.DefaultStAXAttributeProcessorExtensionPoint,
org.apache.tuscany.sca.contribution.processor.URLArtifactProcessorExtensionPoint,
---->
org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProcessorExtensionPoint,
org.apache.tuscany.sca.contribution.processor.URLArtifactProcessor, ---->
org.apache.tuscany.sca.assembly.xml.ComponentTypeDocumentProcessor,
org.apache.tuscany.sca.contribution.resolver.ModelResolverExtensionPoint,
---->
org.apache.tuscany.sca.contribution.resolver.DefaultModelResolverExtensionPoint,
org.apache.tuscany.sca.contribution.processor.PackageProcessorExtensionPoint,
---->
org.apache.tuscany.sca.contribution.processor.DefaultPackageProcessorExtensionPoint,
org.apache.tuscany.sca.contribution.service.ContributionListenerExtensionPoint,
---->
org.apache.tuscany.sca.contribution.service.DefaultContributionListenerExtensionPoint,
org.apache.tuscany.sca.endpointresolver.EndpointResolverFactoryExtensionPoint,
---->
org.apache.tuscany.sca.endpointresolver.DefaultEndpointResolverFactoryExtensionPoint,
org.apache.tuscany.sca.core.conversation.ConversationManager, ---->
org.apache.tuscany.sca.core.conversation.ConversationManagerImpl,
org.apache.tuscany.sca.provider.SCADefinitionsProviderExtensionPoint,
---->
org.apache.tuscany.sca.provider.DefaultSCADefinitionsProviderExtensionPoint,
org.apache.tuscany.sca.provider.SCADefinitionsProvider, ---->
org.apache.tuscany.sca.binding.sca.SCABindingDefinitionsProvider,
org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessor,
----> org.apache.tuscany.sca.assembly.xml.ComponentTypeProcessor,
org.apache.tuscany.sca.implementation.node.NodeImplementationFactory,
---->
org.apache.tuscany.sca.implementation.node.impl.NodeImplementationFactoryImpl,
org.apache.tuscany.sca.contribution.processor.PackageProcessor, ---->
org.apache.tuscany.sca.contribution.processor.impl.APKContributionProcessor,
org.apache.tuscany.sca.contribution.resolver.ModelResolver, ---->
org.apache.tuscany.sca.assembly.xml.CompositeModelResolver,
org.apache.tuscany.sca.contribution.processor.ValidationSchema,
tuscany-sca.xsd,
org.apache.tuscany.sca.assembly.ExtensionFactory, ---->
org.apache.tuscany.sca.assembly.DefaultExtensionFactory,
org.apache.tuscany.sca.contribution.service.ContributionListener, ---->
org.apache.tuscany.sca.contribution.java.impl.JavaImportExportListener,
org.apache.tuscany.sca.contribution.java.ContributionClassloaderProviderExtensionPoint,
---->
org.apache.tuscany.sca.contribution.java.DefaultContributionClassloaderProviderExtensionPoint,
org.apache.tuscany.sca.contribution.java.ContributionClassLoaderProvider,
---->
org.apache.tuscany.sca.contribution.java.DefaultContributionClassLoaderProvider,
org.apache.tuscany.sca.assembly.EndpointFactory, ---->
org.apache.tuscany.sca.assembly.DefaultEndpointFactory,
org.apache.tuscany.sca.provider.BindingProviderFactory, ---->
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCABindingProviderFactory,
*Coming soon*
- Zip of the new calculator-android
- Patch of all modifications on tuscany's modules
--
Best Regards
Lookman SANNI
http://blog.lookouster.org
MSBI Intern at Umanis Tours Services;
Re: Progress update: GSO09 Tuscany-->Android
Posted by lookman sanni <lo...@gmail.com>.
[1:] http://developer.android.com/guide/topics/security/security.html#userid
On Tue, Aug 18, 2009 at 3:06 PM, lookman sanni <lo...@gmail.com> wrote:
>
>
> On Sat, Aug 15, 2009 at 3:03 AM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Tue, Aug 11, 2009 at 3:08 PM, lookman sanni<lo...@gmail.com>
>> wrote:
>> > Blocking issues due to android platform
>> >
>> > Thread.currentThread().getClassLoader() always return null on android.
>> To
>> > fix this, i had to pass dalvik classLoader from the client side to all
>> > places in Tuscany's modules where classLoader is recquired.
>> > ClassLoader.getResources() doesn't work neither under android. Dalvik's
>> > pathClassLoader may be a solution. But as we're working on a lightweight
>> > system, it'll surely be heavy to open stream on about 43 services files
>> > (needed to run calculator). Instead, i just set up system properties so
>> that
>> > each service name will represent a system property and it's
>> implementation
>> > class would be the property's value. This will involve no code
>> refactoring
>> > on tuscany's modules as for resolving services, system properties are
>> > firstly checked.
>> > org.w3c.Node implementation under android doesn't contain getTextContent
>> > method. I replaced all calls to it by getNodeValue().
>> >
>> > Current state
>> > Calculator-android can run till ContributionProcessor resolution. In
>> other
>> > words, definitions.xml loading's step is already performed. What I'm
>> trying
>> > to do now is to implement a an APKContributionProcessor for the new
>> > PackageType.APK somehow like those existing for JAR and Folder
>> > ContributionProcessors.
>> >
>> > APK structure: An archive uncompressable with any archiver, which
>> contain
>> > all resources attached to the sources, and a classes.dex file resulting
>> from
>> > the dexification of all java sources. I guess artifacts i'll need to
>> > retrieve in the APKContributionProcessor will be the classes inside the
>> > classes.dex file.
>> >
>> > Long term: perspectives
>> > Instead of continuing with the current host-android or host-embedded ( i
>> > don't know yet what's exactly inside), i suggest we rewrite it like an
>> > android application that'll setup needed system properties on a world
>> > readable way ( to make it available to any other android application),
>> and
>> > bootstrap at build time resources files into a given directory on the
>> > android system. These resources files will be needed in addition to
>> system
>> > properties as we need to provide a description of all services
>> (classname,
>> > servicename, url).
>>
>> If you make the runtime as an app, how you are going to make other
>> apps run on this app, in other words, how calculator app will run on
>> top of tuscany app ?
>> The idea of host-android (which started as a copy of host-embedded)
>> was to remove the extensibility we were currently using based on
>> Service Discover and getResources and hard code the initialization of
>> these extensions to avoid most of the issues you described above.
>>
>
> I'm not aiming in fact to make the runtime as an app. There'll still be
> runtime module(s). But the installer i'm talking about will just to send
> meta-inf files on the device, and set some system properties or preferences
> any other app like calculator can access. In fact, only ways i think we can
> use to send files on android's device are adb shell and android java
> project. Please have a look to he user ids and file access section of the
> page in [1]
> >
> > The Calculator-android project
> > The one existing is targeting an older version of android sdk. I've just
> > recreated a new project, by importing services sources from the sample
> > calculator.
> >
>
>> This should be a good candidate for a patch.
>
> I think i'll sent an archive of the project instead of a patch. I went in
> fact through some quite gloomy build problems with android sdk, due to sdk
> version problems and may be others.
>
>>
>>
>> ...
>>
>> > Coming soon
>> >
>> > Zip of the new calculator-android
>> > Patch of all modifications on tuscany's modules
>>
>> What's kind of modifications do you have for the tuscany modules ? I
>> guess we don't want to make the existent Tuscany modules more rigid
>> just to run Android.
>>
>
> I assume we will need to rewrite about 2 to 5 tuscany modules, in order to
> get classLoader passed everywhere, and some fixes on uses of org.w3c.Node
> due to non existence of some methods on android.
>
>
>>
>> >
>> > --
>> > Best Regards
>> >
>> > Lookman SANNI
>> > http://blog.lookouster.org
>> > MSBI Intern at Umanis Tours Services;
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> Best Regards
>
> Lookman SANNI
> http://blog.lookouster.org
> MSBI Intern at Umanis Tours Services;
>
--
Best Regards
Lookman SANNI
http://blog.lookouster.org
MSBI Intern at Umanis Tours Services;
Re: Progress update: GSO09 Tuscany-->Android
Posted by lookman sanni <lo...@gmail.com>.
On Sat, Aug 15, 2009 at 3:03 AM, Luciano Resende <lu...@gmail.com>wrote:
> On Tue, Aug 11, 2009 at 3:08 PM, lookman sanni<lo...@gmail.com>
> wrote:
> > Blocking issues due to android platform
> >
> > Thread.currentThread().getClassLoader() always return null on android. To
> > fix this, i had to pass dalvik classLoader from the client side to all
> > places in Tuscany's modules where classLoader is recquired.
> > ClassLoader.getResources() doesn't work neither under android. Dalvik's
> > pathClassLoader may be a solution. But as we're working on a lightweight
> > system, it'll surely be heavy to open stream on about 43 services files
> > (needed to run calculator). Instead, i just set up system properties so
> that
> > each service name will represent a system property and it's
> implementation
> > class would be the property's value. This will involve no code
> refactoring
> > on tuscany's modules as for resolving services, system properties are
> > firstly checked.
> > org.w3c.Node implementation under android doesn't contain getTextContent
> > method. I replaced all calls to it by getNodeValue().
> >
> > Current state
> > Calculator-android can run till ContributionProcessor resolution. In
> other
> > words, definitions.xml loading's step is already performed. What I'm
> trying
> > to do now is to implement a an APKContributionProcessor for the new
> > PackageType.APK somehow like those existing for JAR and Folder
> > ContributionProcessors.
> >
> > APK structure: An archive uncompressable with any archiver, which contain
> > all resources attached to the sources, and a classes.dex file resulting
> from
> > the dexification of all java sources. I guess artifacts i'll need to
> > retrieve in the APKContributionProcessor will be the classes inside the
> > classes.dex file.
> >
> > Long term: perspectives
> > Instead of continuing with the current host-android or host-embedded ( i
> > don't know yet what's exactly inside), i suggest we rewrite it like an
> > android application that'll setup needed system properties on a world
> > readable way ( to make it available to any other android application),
> and
> > bootstrap at build time resources files into a given directory on the
> > android system. These resources files will be needed in addition to
> system
> > properties as we need to provide a description of all services
> (classname,
> > servicename, url).
>
> If you make the runtime as an app, how you are going to make other
> apps run on this app, in other words, how calculator app will run on
> top of tuscany app ?
> The idea of host-android (which started as a copy of host-embedded)
> was to remove the extensibility we were currently using based on
> Service Discover and getResources and hard code the initialization of
> these extensions to avoid most of the issues you described above.
>
I'm not aiming in fact to make the runtime as an app. There'll still be
runtime module(s). But the installer i'm talking about will just to send
meta-inf files on the device, and set some system properties or preferences
any other app like calculator can access. In fact, only ways i think we can
use to send files on android's device are adb shell and android java
project. Please have a look to he user ids and file access section of the
page in [1]
>
> The Calculator-android project
> The one existing is targeting an older version of android sdk. I've just
> recreated a new project, by importing services sources from the sample
> calculator.
>
> This should be a good candidate for a patch.
I think i'll sent an archive of the project instead of a patch. I went in
fact through some quite gloomy build problems with android sdk, due to sdk
version problems and may be others.
>
>
> ...
>
> > Coming soon
> >
> > Zip of the new calculator-android
> > Patch of all modifications on tuscany's modules
>
> What's kind of modifications do you have for the tuscany modules ? I
> guess we don't want to make the existent Tuscany modules more rigid
> just to run Android.
>
I assume we will need to rewrite about 2 to 5 tuscany modules, in order to
get classLoader passed everywhere, and some fixes on uses of org.w3c.Node
due to non existence of some methods on android.
>
> >
> > --
> > Best Regards
> >
> > Lookman SANNI
> > http://blog.lookouster.org
> > MSBI Intern at Umanis Tours Services;
> >
>
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
--
Best Regards
Lookman SANNI
http://blog.lookouster.org
MSBI Intern at Umanis Tours Services;
Re: Progress update: GSO09 Tuscany-->Android
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Aug 11, 2009 at 3:08 PM, lookman sanni<lo...@gmail.com> wrote:
> Blocking issues due to android platform
>
> Thread.currentThread().getClassLoader() always return null on android. To
> fix this, i had to pass dalvik classLoader from the client side to all
> places in Tuscany's modules where classLoader is recquired.
> ClassLoader.getResources() doesn't work neither under android. Dalvik's
> pathClassLoader may be a solution. But as we're working on a lightweight
> system, it'll surely be heavy to open stream on about 43 services files
> (needed to run calculator). Instead, i just set up system properties so that
> each service name will represent a system property and it's implementation
> class would be the property's value. This will involve no code refactoring
> on tuscany's modules as for resolving services, system properties are
> firstly checked.
> org.w3c.Node implementation under android doesn't contain getTextContent
> method. I replaced all calls to it by getNodeValue().
>
> Current state
> Calculator-android can run till ContributionProcessor resolution. In other
> words, definitions.xml loading's step is already performed. What I'm trying
> to do now is to implement a an APKContributionProcessor for the new
> PackageType.APK somehow like those existing for JAR and Folder
> ContributionProcessors.
>
> APK structure: An archive uncompressable with any archiver, which contain
> all resources attached to the sources, and a classes.dex file resulting from
> the dexification of all java sources. I guess artifacts i'll need to
> retrieve in the APKContributionProcessor will be the classes inside the
> classes.dex file.
>
> Long term: perspectives
> Instead of continuing with the current host-android or host-embedded ( i
> don't know yet what's exactly inside), i suggest we rewrite it like an
> android application that'll setup needed system properties on a world
> readable way ( to make it available to any other android application), and
> bootstrap at build time resources files into a given directory on the
> android system. These resources files will be needed in addition to system
> properties as we need to provide a description of all services (classname,
> servicename, url).
If you make the runtime as an app, how you are going to make other
apps run on this app, in other words, how calculator app will run on
top of tuscany app ?
The idea of host-android (which started as a copy of host-embedded)
was to remove the extensibility we were currently using based on
Service Discover and getResources and hard code the initialization of
these extensions to avoid most of the issues you described above.
>
> The Calculator-android project
> The one existing is targeting an older version of android sdk. I've just
> recreated a new project, by importing services sources from the sample
> calculator.
>
This should be a good candidate for a patch.
...
> Coming soon
>
> Zip of the new calculator-android
> Patch of all modifications on tuscany's modules
What's kind of modifications do you have for the tuscany modules ? I
guess we don't want to make the existent Tuscany modules more rigid
just to run Android.
>
> --
> Best Regards
>
> Lookman SANNI
> http://blog.lookouster.org
> MSBI Intern at Umanis Tours Services;
>
--
Luciano Resende
http://people.apache.org/~lresende
http://lresende.blogspot.com/