On Tue, Aug 11, 2009 at 3:08 PM, lookman sanni<[email protected]> 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/
