You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Oscar Castaneda <os...@gmail.com> on 2008/07/23 02:58:00 UTC
Embedding Tuscany/SCA in Google Android
Hi,
I've been mostly using another thread for issues and questions concerning
running Tuscany/SCA on Android. Some progress has been made and a new thread
was needed.
Recently, Adriano reported some errors while testing changes to the android
sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
look into calculator2 for coming up with a minimal set of modules necessary
to run calculator-android. I took the list of modules from the
tuscany-runtime2 and tuscany-api JARs of the revision that included
calculator2, and augmented it based on dependencies from revision 643746,
which was a previous revision, until the point in which I received the same
errors [2] that Adriano had reported. These errors result in the
RuntimeException shown below:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
org.osoa.sca.ServiceUnavailableException: Service not found for
component CalculatorServiceComponent reference setAddService
(bindingURI=null operation=add). Ensure that the composite containing
the service is loaded and started somewhere in the SCA domain and that
if running in a remote node that the interface of the target service
marked as @Remotable
Seeing this error the first question that came to mind was: how do I verify
whether the composite containing the service is being loaded? and, does it
actually exist? I was thinking that maybe the composite was not being
created and thus was resulting in the errors in [3]. To test this I changed
the first line of "calculator_composite" to read as follows:
<composite name="Calculator" autowire="true">
Setting the autowire attribute to true would make the runtime automatically
connect services and references in the composite, granted there actually was
one. This resulted in the error shown in [4] and included in more detail in
[5]. The fact that the runtime wires are being created makes me think that a
composite does exist, as documented in [6]. However, the error messages
confuse me and make me think otherwise, especially the one shown below:
java.lang.RuntimeException: Unable to start activity
ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
org.osoa.sca.ServiceRuntimeException:
org.osoa.sca.ServiceRuntimeException: Composite not found:
dex://calculator.android/raw/calculator.composite
Any suggestions or ideas from the Tuscany community to resolve this problem
will be greatly appreciated. As Adriano mentioned in the previous thread, we
have a feeling we're getting closer to successfully embedding Tuscany/SCA in
Android.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
[2] http://androidindelft.googlepages.com/21Jul2.jpg
[3]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
[4] http://androidindelft.googlepages.com/22Jul1.jpg
[5]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
[6]
http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Adriano,
The instructions in [1] will get you there. I'm also thinking of
alternatives to get this done with Maven, despite the fact that the
Retrotranslator plugin for Maven is currently missing some options used for
the needed translation.
Thanks for your help.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/23Jul2008+-+Steps+to+reproduce+workspace
On Wed, Jul 23, 2008 at 9:32 AM, Adriano Crestani <
adrianocrestani@apache.org> wrote:
> Good summary Oscar : )
>
> I would like to reproduce your workspace and get this exception with only
> the modules set your are using. I tried it, but I'm getting some errors
> related to missing classes from the modules I removed. Could you make a new
> step by step tutorial of how to reproduce a workspace like yours?
>
> Thanks,
> Adriano Crestani
>
>
> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda <
> oscar.castaneda.gsoc@gmail.com> wrote:
>
>> Hi,
>>
>> I've been mostly using another thread for issues and questions concerning
>> running Tuscany/SCA on Android. Some progress has been made and a new thread
>> was needed.
>>
>> Recently, Adriano reported some errors while testing changes to the
>> android sandbox and revision 674723 [1]. There was also a suggestion from
>> Luciano to look into calculator2 for coming up with a minimal set of modules
>> necessary to run calculator-android. I took the list of modules from the
>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> calculator2, and augmented it based on dependencies from revision 643746,
>> which was a previous revision, until the point in which I received the same
>> errors [2] that Adriano had reported. These errors result in the
>> RuntimeException shown below:
>>
>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceUnavailableException: Service not found for component CalculatorServiceComponent reference setAddService (bindingURI=null operation=add). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable
>>
>>
>> Seeing this error the first question that came to mind was: how do I
>> verify whether the composite containing the service is being loaded? and,
>> does it actually exist? I was thinking that maybe the composite was not
>> being created and thus was resulting in the errors in [3]. To test this I
>> changed the first line of "calculator_composite" to read as follows:
>>
>> <composite name="Calculator" autowire="true">
>>
>> Setting the autowire attribute to true would make the runtime
>> automatically connect services and references in the composite, granted
>> there actually was one. This resulted in the error shown in [4] and included
>> in more detail in [5]. The fact that the runtime wires are being created
>> makes me think that a composite does exist, as documented in [6]. However,
>> the error messages confuse me and make me think otherwise, especially the
>> one shown below:
>>
>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: Composite not found: dex://calculator.android/raw/calculator.composite
>>
>>
>>
>>
>> Any suggestions or ideas from the Tuscany community to resolve this
>> problem will be greatly appreciated. As Adriano mentioned in the previous
>> thread, we have a feeling we're getting closer to successfully embedding
>> Tuscany/SCA in Android.
>>
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> [3]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> [5]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> [6]
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>>
>
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Adriano,
Thanks for the clarification, now I understand that it's mostly a warning.
I've looked for the option in Eclipse but haven't found how to add such an
argument for the Android compiler. One option I was thinking was of passing
it through the dx utility instead of through Eclipse, i'll test it out in
the next few days and will follow-up.
Additionally, I saw your post on the Android Developer list; I had posted a
similar question [1] but haven't received a response either. If I find how
to do it I guess i'll respond to myself, lol. Anyway, i'll keep you posted.
[1]
http://groups.google.com/group/android-developers/browse_thread/thread/5cf26321827e0c71/73adde621c4455d2?lnk=gst&q=core+library#73adde621c4455d2
On Tue, Sep 2, 2008 at 4:33 AM, Adriano Crestani <adrianocrestani@apache.org
> wrote:
> Hi Oscar,
>
> I think it's ok to set this option...the QName class was indeed not added
> on the latest SDK version. I think It's complaining about you trying to add
> a core library class just because you are adding a class that is in the same
> package that the java JDK classes are placed. The error msg tells about a
> future error you can get if you ignore this error, but it will probably not
> occur because the QName does not use any native JDK method.
>
> OK, then I tried to add this argument on my android eclipse project, but I
> couldn't find an option to add arguments for the Android compiler. Could
> you?
>
> Regards,
> Adriano Crestani
>
>
> On Thu, Aug 28, 2008 at 8:48 AM, Oscar Castaneda <
> oscar.castaneda.gsoc@gmail.com> wrote:
>
>> Hi Adriano,
>>
>> It wasn't added, so I guess we still need to keep the class. Any other
>> ideas? One thing I'm thinking of is to pass "--core-library" as an option to
>> dex, even though the error message kinda of advices not to do so when
>> building applications. Anyhow, I'll keep you posted on any progress.
>>
>>
>> On Wed, Aug 27, 2008 at 11:44 PM, Adriano Crestani <
>> adrianocrestani@apache.org> wrote:
>>
>>> Hi Oscar,
>>>
>>> Please, check if in the latest Android SDK the javax.xml.namespace.QName
>>> was added. If it does, remove this class from the android-jdk-classes
>>> project.
>>>
>>> Regards,
>>> Adriano Crestani
>>>
>>>
>>> On Wed, Aug 27, 2008 at 2:38 PM, Oscar Castaneda <
>>> oscar.castaneda.gsoc@gmail.com> wrote:
>>>
>>>> Hi Luciano,
>>>>
>>>> Unfortunately, not yet. Sorry for the confusion, I should've mentioned
>>>> that with the reduced set of modules calculator2 runs with no problems on a
>>>> PC and not on Android.
>>>>
>>>> When testing with the new SDK the problem I'm facing is that when dex is
>>>> processing the stax-api-1.0-2.jar it shows the errors shown below. I haven't
>>>> found how to use the 'dx' utility from the SDK in such a way that I can pass
>>>> "--core-library" as an option, and neither have I found how to do this
>>>> through Eclipse. However, from the error message it seems like using this
>>>> option would not be a good idea. Any thoughts or ideas on this are welcomed
>>>> and appreciated.
>>>>
>>>> [2008-08-27 23:23:55 - calculator-android]
>>>> trouble processing "javax/xml/namespace/QName$1.class":
>>>> [2008-08-27 23:23:55 - calculator-android]
>>>> Attempt to include a core VM class in something other than a core
>>>> library.
>>>> It is likely that you have attempted to include the core library from a
>>>> desktop
>>>> virtual machine into an application, which will most assuredly not work.
>>>> If
>>>> you really intend to build a core library -- which is only appropriate
>>>> as
>>>> part of creating a full virtual machine binary, as opposed to compiling
>>>> an
>>>> application -- then use the "--core-library" option to suppress this
>>>> error
>>>> message. If you go ahead and use "--core-library" but are in fact
>>>> building
>>>> an application, then please be aware that your build will still fail at
>>>> some
>>>> point; you will simply be denied the pleasure of reading this helpful
>>>> error
>>>> message.
>>>> [2008-08-27 23:23:55 - calculator-android] 1 error; aborting
>>>> [2008-08-27 23:23:55 - calculator-android] Conversion to Dalvik format
>>>> failed with error 1
>>>>
>>>>
>>>> On Wed, Aug 27, 2008 at 10:23 PM, Luciano Resende <luckbr1975@gmail.com
>>>> > wrote:
>>>>
>>>>> Hey Oscar
>>>>>
>>>>> I was just looking into your latest updates in TUSCANY-2440, am I
>>>>> reading it right that you were able to successfully run a calculator2
>>>>> in Android using the new SDK ?
>>>>>
>>>>> On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
>>>>> <os...@gmail.com> wrote:
>>>>> > Hi Mike,
>>>>> >
>>>>> > Thanks for your suggestion. I discussed it with Adriano and the
>>>>> problem we
>>>>> > find is that even if we turn off introspection, either by using a
>>>>> > <componentType/> side file or removing annotations, the Android SDK
>>>>> would
>>>>> > still choke when encountering any code with annotations. Fortunately,
>>>>> > however, Google recently released an updated version of the SDK. We
>>>>> have
>>>>> > started testing it and have made some progress. I will continue
>>>>> helping
>>>>> > Adriano in these efforts.
>>>>> >
>>>>> > On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
>>>>> > <mi...@gmail.com> wrote:
>>>>> >>
>>>>> >> Folks,
>>>>> >>
>>>>> >> One thing worth considering - if it is the introspection of the Java
>>>>> >> implementation classes that is causing the problems, one possibility
>>>>> is to
>>>>> >> turn off this introspection and instead to supply the equivalent
>>>>> information
>>>>> >> as <componentType/> side files. Then everything just reads XML,
>>>>> which is
>>>>> >> known to work. I think the main use of introspection is in the
>>>>> computation
>>>>> >> of the componentType for the implementation classes.
>>>>> >>
>>>>> >>
>>>>> >> Yours, Mike.
>>>>> >>
>>>>> >> Adriano Crestani wrote:
>>>>> >>>
>>>>> >>> Good summary Oscar : )
>>>>> >>>
>>>>> >>> Yes, I know we haven't solved the problem yet, but now we know what
>>>>> it
>>>>> >>> is. Unfortunately we got back to the point before using
>>>>> retrotranslator, it
>>>>> >>> worked for what it was supposed to, but it messed something up :S.
>>>>> >>>
>>>>> >>> Yes, lets try the Luciano's suggestion and comment/workaround every
>>>>> SCA
>>>>> >>> code line that tries to use the Reflect API (please, check my last
>>>>> emails
>>>>> >>> about that on this thread). I think it will not take too much time,
>>>>> run the
>>>>> >>> app on the Android platform and when you get an error, just look at
>>>>> that
>>>>> >>> Android console for exception stack trace and fix it.
>>>>> >>>
>>>>> >>> Let us know if you have any questions
>>>>> >>>
>>>>> >>> Regards,
>>>>> >>> Adriano Crestani
>>>>> >>>
>>>>> >> <snip>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > best,
>>>>> > -oscar
>>>>> >
>>>>> > Oscar Castañeda
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Luciano Resende
>>>>> Apache Tuscany Committer
>>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>>> http://lresende.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> best,
>>>> -oscar
>>>>
>>>> Oscar Castañeda
>>>>
>>>
>>>
>>
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>>
>
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Hi Oscar,
I think it's ok to set this option...the QName class was indeed not added on
the latest SDK version. I think It's complaining about you trying to add a
core library class just because you are adding a class that is in the same
package that the java JDK classes are placed. The error msg tells about a
future error you can get if you ignore this error, but it will probably not
occur because the QName does not use any native JDK method.
OK, then I tried to add this argument on my android eclipse project, but I
couldn't find an option to add arguments for the Android compiler. Could
you?
Regards,
Adriano Crestani
On Thu, Aug 28, 2008 at 8:48 AM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Hi Adriano,
>
> It wasn't added, so I guess we still need to keep the class. Any other
> ideas? One thing I'm thinking of is to pass "--core-library" as an option to
> dex, even though the error message kinda of advices not to do so when
> building applications. Anyhow, I'll keep you posted on any progress.
>
>
> On Wed, Aug 27, 2008 at 11:44 PM, Adriano Crestani <
> adrianocrestani@apache.org> wrote:
>
>> Hi Oscar,
>>
>> Please, check if in the latest Android SDK the javax.xml.namespace.QName
>> was added. If it does, remove this class from the android-jdk-classes
>> project.
>>
>> Regards,
>> Adriano Crestani
>>
>>
>> On Wed, Aug 27, 2008 at 2:38 PM, Oscar Castaneda <
>> oscar.castaneda.gsoc@gmail.com> wrote:
>>
>>> Hi Luciano,
>>>
>>> Unfortunately, not yet. Sorry for the confusion, I should've mentioned
>>> that with the reduced set of modules calculator2 runs with no problems on a
>>> PC and not on Android.
>>>
>>> When testing with the new SDK the problem I'm facing is that when dex is
>>> processing the stax-api-1.0-2.jar it shows the errors shown below. I haven't
>>> found how to use the 'dx' utility from the SDK in such a way that I can pass
>>> "--core-library" as an option, and neither have I found how to do this
>>> through Eclipse. However, from the error message it seems like using this
>>> option would not be a good idea. Any thoughts or ideas on this are welcomed
>>> and appreciated.
>>>
>>> [2008-08-27 23:23:55 - calculator-android]
>>> trouble processing "javax/xml/namespace/QName$1.class":
>>> [2008-08-27 23:23:55 - calculator-android]
>>> Attempt to include a core VM class in something other than a core
>>> library.
>>> It is likely that you have attempted to include the core library from a
>>> desktop
>>> virtual machine into an application, which will most assuredly not work.
>>> If
>>> you really intend to build a core library -- which is only appropriate as
>>> part of creating a full virtual machine binary, as opposed to compiling
>>> an
>>> application -- then use the "--core-library" option to suppress this
>>> error
>>> message. If you go ahead and use "--core-library" but are in fact
>>> building
>>> an application, then please be aware that your build will still fail at
>>> some
>>> point; you will simply be denied the pleasure of reading this helpful
>>> error
>>> message.
>>> [2008-08-27 23:23:55 - calculator-android] 1 error; aborting
>>> [2008-08-27 23:23:55 - calculator-android] Conversion to Dalvik format
>>> failed with error 1
>>>
>>>
>>> On Wed, Aug 27, 2008 at 10:23 PM, Luciano Resende <lu...@gmail.com>wrote:
>>>
>>>> Hey Oscar
>>>>
>>>> I was just looking into your latest updates in TUSCANY-2440, am I
>>>> reading it right that you were able to successfully run a calculator2
>>>> in Android using the new SDK ?
>>>>
>>>> On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
>>>> <os...@gmail.com> wrote:
>>>> > Hi Mike,
>>>> >
>>>> > Thanks for your suggestion. I discussed it with Adriano and the
>>>> problem we
>>>> > find is that even if we turn off introspection, either by using a
>>>> > <componentType/> side file or removing annotations, the Android SDK
>>>> would
>>>> > still choke when encountering any code with annotations. Fortunately,
>>>> > however, Google recently released an updated version of the SDK. We
>>>> have
>>>> > started testing it and have made some progress. I will continue
>>>> helping
>>>> > Adriano in these efforts.
>>>> >
>>>> > On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
>>>> > <mi...@gmail.com> wrote:
>>>> >>
>>>> >> Folks,
>>>> >>
>>>> >> One thing worth considering - if it is the introspection of the Java
>>>> >> implementation classes that is causing the problems, one possibility
>>>> is to
>>>> >> turn off this introspection and instead to supply the equivalent
>>>> information
>>>> >> as <componentType/> side files. Then everything just reads XML,
>>>> which is
>>>> >> known to work. I think the main use of introspection is in the
>>>> computation
>>>> >> of the componentType for the implementation classes.
>>>> >>
>>>> >>
>>>> >> Yours, Mike.
>>>> >>
>>>> >> Adriano Crestani wrote:
>>>> >>>
>>>> >>> Good summary Oscar : )
>>>> >>>
>>>> >>> Yes, I know we haven't solved the problem yet, but now we know what
>>>> it
>>>> >>> is. Unfortunately we got back to the point before using
>>>> retrotranslator, it
>>>> >>> worked for what it was supposed to, but it messed something up :S.
>>>> >>>
>>>> >>> Yes, lets try the Luciano's suggestion and comment/workaround every
>>>> SCA
>>>> >>> code line that tries to use the Reflect API (please, check my last
>>>> emails
>>>> >>> about that on this thread). I think it will not take too much time,
>>>> run the
>>>> >>> app on the Android platform and when you get an error, just look at
>>>> that
>>>> >>> Android console for exception stack trace and fix it.
>>>> >>>
>>>> >>> Let us know if you have any questions
>>>> >>>
>>>> >>> Regards,
>>>> >>> Adriano Crestani
>>>> >>>
>>>> >> <snip>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > best,
>>>> > -oscar
>>>> >
>>>> > Oscar Castañeda
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Luciano Resende
>>>> Apache Tuscany Committer
>>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>>> http://lresende.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> -oscar
>>>
>>> Oscar Castañeda
>>>
>>
>>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Adriano,
It wasn't added, so I guess we still need to keep the class. Any other
ideas? One thing I'm thinking of is to pass "--core-library" as an option to
dex, even though the error message kinda of advices not to do so when
building applications. Anyhow, I'll keep you posted on any progress.
On Wed, Aug 27, 2008 at 11:44 PM, Adriano Crestani <
adrianocrestani@apache.org> wrote:
> Hi Oscar,
>
> Please, check if in the latest Android SDK the javax.xml.namespace.QName
> was added. If it does, remove this class from the android-jdk-classes
> project.
>
> Regards,
> Adriano Crestani
>
>
> On Wed, Aug 27, 2008 at 2:38 PM, Oscar Castaneda <
> oscar.castaneda.gsoc@gmail.com> wrote:
>
>> Hi Luciano,
>>
>> Unfortunately, not yet. Sorry for the confusion, I should've mentioned
>> that with the reduced set of modules calculator2 runs with no problems on a
>> PC and not on Android.
>>
>> When testing with the new SDK the problem I'm facing is that when dex is
>> processing the stax-api-1.0-2.jar it shows the errors shown below. I haven't
>> found how to use the 'dx' utility from the SDK in such a way that I can pass
>> "--core-library" as an option, and neither have I found how to do this
>> through Eclipse. However, from the error message it seems like using this
>> option would not be a good idea. Any thoughts or ideas on this are welcomed
>> and appreciated.
>>
>> [2008-08-27 23:23:55 - calculator-android]
>> trouble processing "javax/xml/namespace/QName$1.class":
>> [2008-08-27 23:23:55 - calculator-android]
>> Attempt to include a core VM class in something other than a core library.
>> It is likely that you have attempted to include the core library from a
>> desktop
>> virtual machine into an application, which will most assuredly not work.
>> If
>> you really intend to build a core library -- which is only appropriate as
>> part of creating a full virtual machine binary, as opposed to compiling an
>> application -- then use the "--core-library" option to suppress this error
>> message. If you go ahead and use "--core-library" but are in fact building
>> an application, then please be aware that your build will still fail at
>> some
>> point; you will simply be denied the pleasure of reading this helpful
>> error
>> message.
>> [2008-08-27 23:23:55 - calculator-android] 1 error; aborting
>> [2008-08-27 23:23:55 - calculator-android] Conversion to Dalvik format
>> failed with error 1
>>
>>
>> On Wed, Aug 27, 2008 at 10:23 PM, Luciano Resende <lu...@gmail.com>wrote:
>>
>>> Hey Oscar
>>>
>>> I was just looking into your latest updates in TUSCANY-2440, am I
>>> reading it right that you were able to successfully run a calculator2
>>> in Android using the new SDK ?
>>>
>>> On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
>>> <os...@gmail.com> wrote:
>>> > Hi Mike,
>>> >
>>> > Thanks for your suggestion. I discussed it with Adriano and the problem
>>> we
>>> > find is that even if we turn off introspection, either by using a
>>> > <componentType/> side file or removing annotations, the Android SDK
>>> would
>>> > still choke when encountering any code with annotations. Fortunately,
>>> > however, Google recently released an updated version of the SDK. We
>>> have
>>> > started testing it and have made some progress. I will continue helping
>>> > Adriano in these efforts.
>>> >
>>> > On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
>>> > <mi...@gmail.com> wrote:
>>> >>
>>> >> Folks,
>>> >>
>>> >> One thing worth considering - if it is the introspection of the Java
>>> >> implementation classes that is causing the problems, one possibility
>>> is to
>>> >> turn off this introspection and instead to supply the equivalent
>>> information
>>> >> as <componentType/> side files. Then everything just reads XML, which
>>> is
>>> >> known to work. I think the main use of introspection is in the
>>> computation
>>> >> of the componentType for the implementation classes.
>>> >>
>>> >>
>>> >> Yours, Mike.
>>> >>
>>> >> Adriano Crestani wrote:
>>> >>>
>>> >>> Good summary Oscar : )
>>> >>>
>>> >>> Yes, I know we haven't solved the problem yet, but now we know what
>>> it
>>> >>> is. Unfortunately we got back to the point before using
>>> retrotranslator, it
>>> >>> worked for what it was supposed to, but it messed something up :S.
>>> >>>
>>> >>> Yes, lets try the Luciano's suggestion and comment/workaround every
>>> SCA
>>> >>> code line that tries to use the Reflect API (please, check my last
>>> emails
>>> >>> about that on this thread). I think it will not take too much time,
>>> run the
>>> >>> app on the Android platform and when you get an error, just look at
>>> that
>>> >>> Android console for exception stack trace and fix it.
>>> >>>
>>> >>> Let us know if you have any questions
>>> >>>
>>> >>> Regards,
>>> >>> Adriano Crestani
>>> >>>
>>> >> <snip>
>>> >
>>> >
>>> >
>>> > --
>>> > best,
>>> > -oscar
>>> >
>>> > Oscar Castañeda
>>> >
>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany Committer
>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>> http://lresende.blogspot.com/
>>>
>>
>>
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>>
>
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Hi Oscar,
Please, check if in the latest Android SDK the javax.xml.namespace.QName was
added. If it does, remove this class from the android-jdk-classes project.
Regards,
Adriano Crestani
On Wed, Aug 27, 2008 at 2:38 PM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Hi Luciano,
>
> Unfortunately, not yet. Sorry for the confusion, I should've mentioned that
> with the reduced set of modules calculator2 runs with no problems on a PC
> and not on Android.
>
> When testing with the new SDK the problem I'm facing is that when dex is
> processing the stax-api-1.0-2.jar it shows the errors shown below. I haven't
> found how to use the 'dx' utility from the SDK in such a way that I can pass
> "--core-library" as an option, and neither have I found how to do this
> through Eclipse. However, from the error message it seems like using this
> option would not be a good idea. Any thoughts or ideas on this are welcomed
> and appreciated.
>
> [2008-08-27 23:23:55 - calculator-android]
> trouble processing "javax/xml/namespace/QName$1.class":
> [2008-08-27 23:23:55 - calculator-android]
> Attempt to include a core VM class in something other than a core library.
> It is likely that you have attempted to include the core library from a
> desktop
> virtual machine into an application, which will most assuredly not work. If
> you really intend to build a core library -- which is only appropriate as
> part of creating a full virtual machine binary, as opposed to compiling an
> application -- then use the "--core-library" option to suppress this error
> message. If you go ahead and use "--core-library" but are in fact building
> an application, then please be aware that your build will still fail at
> some
> point; you will simply be denied the pleasure of reading this helpful error
> message.
> [2008-08-27 23:23:55 - calculator-android] 1 error; aborting
> [2008-08-27 23:23:55 - calculator-android] Conversion to Dalvik format
> failed with error 1
>
>
> On Wed, Aug 27, 2008 at 10:23 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> Hey Oscar
>>
>> I was just looking into your latest updates in TUSCANY-2440, am I
>> reading it right that you were able to successfully run a calculator2
>> in Android using the new SDK ?
>>
>> On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
>> <os...@gmail.com> wrote:
>> > Hi Mike,
>> >
>> > Thanks for your suggestion. I discussed it with Adriano and the problem
>> we
>> > find is that even if we turn off introspection, either by using a
>> > <componentType/> side file or removing annotations, the Android SDK
>> would
>> > still choke when encountering any code with annotations. Fortunately,
>> > however, Google recently released an updated version of the SDK. We have
>> > started testing it and have made some progress. I will continue helping
>> > Adriano in these efforts.
>> >
>> > On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
>> > <mi...@gmail.com> wrote:
>> >>
>> >> Folks,
>> >>
>> >> One thing worth considering - if it is the introspection of the Java
>> >> implementation classes that is causing the problems, one possibility is
>> to
>> >> turn off this introspection and instead to supply the equivalent
>> information
>> >> as <componentType/> side files. Then everything just reads XML, which
>> is
>> >> known to work. I think the main use of introspection is in the
>> computation
>> >> of the componentType for the implementation classes.
>> >>
>> >>
>> >> Yours, Mike.
>> >>
>> >> Adriano Crestani wrote:
>> >>>
>> >>> Good summary Oscar : )
>> >>>
>> >>> Yes, I know we haven't solved the problem yet, but now we know what it
>> >>> is. Unfortunately we got back to the point before using
>> retrotranslator, it
>> >>> worked for what it was supposed to, but it messed something up :S.
>> >>>
>> >>> Yes, lets try the Luciano's suggestion and comment/workaround every
>> SCA
>> >>> code line that tries to use the Reflect API (please, check my last
>> emails
>> >>> about that on this thread). I think it will not take too much time,
>> run the
>> >>> app on the Android platform and when you get an error, just look at
>> that
>> >>> Android console for exception stack trace and fix it.
>> >>>
>> >>> Let us know if you have any questions
>> >>>
>> >>> Regards,
>> >>> Adriano Crestani
>> >>>
>> >> <snip>
>> >
>> >
>> >
>> > --
>> > best,
>> > -oscar
>> >
>> > Oscar Castañeda
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Luciano,
Unfortunately, not yet. Sorry for the confusion, I should've mentioned that
with the reduced set of modules calculator2 runs with no problems on a PC
and not on Android.
When testing with the new SDK the problem I'm facing is that when dex is
processing the stax-api-1.0-2.jar it shows the errors shown below. I haven't
found how to use the 'dx' utility from the SDK in such a way that I can pass
"--core-library" as an option, and neither have I found how to do this
through Eclipse. However, from the error message it seems like using this
option would not be a good idea. Any thoughts or ideas on this are welcomed
and appreciated.
[2008-08-27 23:23:55 - calculator-android]
trouble processing "javax/xml/namespace/QName$1.class":
[2008-08-27 23:23:55 - calculator-android]
Attempt to include a core VM class in something other than a core library.
It is likely that you have attempted to include the core library from a
desktop
virtual machine into an application, which will most assuredly not work. If
you really intend to build a core library -- which is only appropriate as
part of creating a full virtual machine binary, as opposed to compiling an
application -- then use the "--core-library" option to suppress this error
message. If you go ahead and use "--core-library" but are in fact building
an application, then please be aware that your build will still fail at some
point; you will simply be denied the pleasure of reading this helpful error
message.
[2008-08-27 23:23:55 - calculator-android] 1 error; aborting
[2008-08-27 23:23:55 - calculator-android] Conversion to Dalvik format
failed with error 1
On Wed, Aug 27, 2008 at 10:23 PM, Luciano Resende <lu...@gmail.com>wrote:
> Hey Oscar
>
> I was just looking into your latest updates in TUSCANY-2440, am I
> reading it right that you were able to successfully run a calculator2
> in Android using the new SDK ?
>
> On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
> <os...@gmail.com> wrote:
> > Hi Mike,
> >
> > Thanks for your suggestion. I discussed it with Adriano and the problem
> we
> > find is that even if we turn off introspection, either by using a
> > <componentType/> side file or removing annotations, the Android SDK would
> > still choke when encountering any code with annotations. Fortunately,
> > however, Google recently released an updated version of the SDK. We have
> > started testing it and have made some progress. I will continue helping
> > Adriano in these efforts.
> >
> > On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
> > <mi...@gmail.com> wrote:
> >>
> >> Folks,
> >>
> >> One thing worth considering - if it is the introspection of the Java
> >> implementation classes that is causing the problems, one possibility is
> to
> >> turn off this introspection and instead to supply the equivalent
> information
> >> as <componentType/> side files. Then everything just reads XML, which
> is
> >> known to work. I think the main use of introspection is in the
> computation
> >> of the componentType for the implementation classes.
> >>
> >>
> >> Yours, Mike.
> >>
> >> Adriano Crestani wrote:
> >>>
> >>> Good summary Oscar : )
> >>>
> >>> Yes, I know we haven't solved the problem yet, but now we know what it
> >>> is. Unfortunately we got back to the point before using
> retrotranslator, it
> >>> worked for what it was supposed to, but it messed something up :S.
> >>>
> >>> Yes, lets try the Luciano's suggestion and comment/workaround every SCA
> >>> code line that tries to use the Reflect API (please, check my last
> emails
> >>> about that on this thread). I think it will not take too much time, run
> the
> >>> app on the Android platform and when you get an error, just look at
> that
> >>> Android console for exception stack trace and fix it.
> >>>
> >>> Let us know if you have any questions
> >>>
> >>> Regards,
> >>> Adriano Crestani
> >>>
> >> <snip>
> >
> >
> >
> > --
> > best,
> > -oscar
> >
> > Oscar Castañeda
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Luciano Resende <lu...@gmail.com>.
Hey Oscar
I was just looking into your latest updates in TUSCANY-2440, am I
reading it right that you were able to successfully run a calculator2
in Android using the new SDK ?
On Wed, Aug 27, 2008 at 12:07 PM, Oscar Castaneda
<os...@gmail.com> wrote:
> Hi Mike,
>
> Thanks for your suggestion. I discussed it with Adriano and the problem we
> find is that even if we turn off introspection, either by using a
> <componentType/> side file or removing annotations, the Android SDK would
> still choke when encountering any code with annotations. Fortunately,
> however, Google recently released an updated version of the SDK. We have
> started testing it and have made some progress. I will continue helping
> Adriano in these efforts.
>
> On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>>
>> Folks,
>>
>> One thing worth considering - if it is the introspection of the Java
>> implementation classes that is causing the problems, one possibility is to
>> turn off this introspection and instead to supply the equivalent information
>> as <componentType/> side files. Then everything just reads XML, which is
>> known to work. I think the main use of introspection is in the computation
>> of the componentType for the implementation classes.
>>
>>
>> Yours, Mike.
>>
>> Adriano Crestani wrote:
>>>
>>> Good summary Oscar : )
>>>
>>> Yes, I know we haven't solved the problem yet, but now we know what it
>>> is. Unfortunately we got back to the point before using retrotranslator, it
>>> worked for what it was supposed to, but it messed something up :S.
>>>
>>> Yes, lets try the Luciano's suggestion and comment/workaround every SCA
>>> code line that tries to use the Reflect API (please, check my last emails
>>> about that on this thread). I think it will not take too much time, run the
>>> app on the Android platform and when you get an error, just look at that
>>> Android console for exception stack trace and fix it.
>>>
>>> Let us know if you have any questions
>>>
>>> Regards,
>>> Adriano Crestani
>>>
>> <snip>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Mike,
Thanks for your suggestion. I discussed it with Adriano and the problem we
find is that even if we turn off introspection, either by using a
<componentType/> side file or removing annotations, the Android SDK would
still choke when encountering any code with annotations. Fortunately,
however, Google recently released an updated version of the SDK. We have
started testing it and have made some progress. I will continue helping
Adriano in these efforts.
On Thu, Aug 14, 2008 at 6:05 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> Folks,
>
> One thing worth considering - if it is the introspection of the Java
> implementation classes that is causing the problems, one possibility is to
> turn off this introspection and instead to supply the equivalent information
> as <componentType/> side files. Then everything just reads XML, which is
> known to work. I think the main use of introspection is in the computation
> of the componentType for the implementation classes.
>
>
> Yours, Mike.
>
> Adriano Crestani wrote:
>
>> Good summary Oscar : )
>>
>> Yes, I know we haven't solved the problem yet, but now we know what it is.
>> Unfortunately we got back to the point before using retrotranslator, it
>> worked for what it was supposed to, but it messed something up :S.
>>
>> Yes, lets try the Luciano's suggestion and comment/workaround every SCA
>> code line that tries to use the Reflect API (please, check my last emails
>> about that on this thread). I think it will not take too much time, run the
>> app on the Android platform and when you get an error, just look at that
>> Android console for exception stack trace and fix it.
>>
>> Let us know if you have any questions
>>
>> Regards,
>> Adriano Crestani
>>
>> <snip>
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
One thing worth considering - if it is the introspection of the Java implementation classes that is
causing the problems, one possibility is to turn off this introspection and instead to supply the
equivalent information as <componentType/> side files. Then everything just reads XML, which is
known to work. I think the main use of introspection is in the computation of the componentType for
the implementation classes.
Yours, Mike.
Adriano Crestani wrote:
> Good summary Oscar : )
>
> Yes, I know we haven't solved the problem yet, but now we know what it
> is. Unfortunately we got back to the point before using retrotranslator,
> it worked for what it was supposed to, but it messed something up :S.
>
> Yes, lets try the Luciano's suggestion and comment/workaround every SCA
> code line that tries to use the Reflect API (please, check my last
> emails about that on this thread). I think it will not take too much
> time, run the app on the Android platform and when you get an error,
> just look at that Android console for exception stack trace and fix it.
>
> Let us know if you have any questions
>
> Regards,
> Adriano Crestani
>
<snip>
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Good summary Oscar : )
Yes, I know we haven't solved the problem yet, but now we know what it is.
Unfortunately we got back to the point before using retrotranslator, it
worked for what it was supposed to, but it messed something up :S.
Yes, lets try the Luciano's suggestion and comment/workaround every SCA code
line that tries to use the Reflect API (please, check my last emails about
that on this thread). I think it will not take too much time, run the app on
the Android platform and when you get an error, just look at that Android
console for exception stack trace and fix it.
Let us know if you have any questions
Regards,
Adriano Crestani
On Mon, Aug 11, 2008 at 10:04 AM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Thanks Luciano and Simon for your help in this thread. These past couple of
> weeks I've been ardently debugging in the hopes of getting to the root of
> the problem. While I have gained some insights, the issue is far from
> resolved as problems still remain. I'm now a bit reluctant about whether use
> of retrotranslator is a viable solution for this project. I'll explain below
> along with a summary of the most important findings.
>
> Recently, Adriano reported some errors while testing changes to the android
> sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
> look into calculator2 for coming up with a minimal set of modules necessary
> to run calculator-android. I took the list of modules from the
> tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
> calculator2, and augmented it based on dependencies from revision 643746
> until the point in which I received the same errors [2] that Adriano had
> reported.
>
> These errors included a ServiceUnavailableException that, as Simon
> explained, comes from the SCA binding when it tries to create an invoker but
> it finds there is no wire to support the connection. I thought this might be
> because of Android's use of the dex protocol but as Luciano explained, it
> shouldn't be a problem as classLoaders were only loading stuff into
> ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
> the CompositeProcessor is able to view the contents of the calculator
> composite.
>
> Further debugging showed that the calculator.composite is indeed being read
> appropriately, eliminating the possibility of a parsing related issue. I
> verified this by seeing the composite being correctly populated while
> debugging. To accomplish this I compared the reduced Android SCA to revision
> 643746 without the Android sandbox code and with the normal calculator
> sample. This was suggested by Adriano as a way to approach testing and
> debugging for Android.
>
> To further simplify the debugging runs I narrowed down the calculator
> operations to only the "add" operation. I set a breakpoint in
> RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
> where the error is ocurring. I found that the problem is that the service,
> as shown below, is being assigned a value of null.
>
> RuntimeComponentService service =
> (RuntimeComponentService)target.getContract();
>
> In order to proceed, service must have a value other than null. Instead,
> getInvoker() method returns a null invoker, which results in the
> ServiceUnavailableException shown below:
>
> if (invoker == null) {
> throw new ServiceUnavailableException("Service not found
> for component " + component.getName()
> + " reference "
> + reference.getName()
> + " (bindingURI="
> + binding.getURI()
> + " operation="
> + operation.getName()
> + "). Ensure that the composite containing the service
> is loaded and "
> + "started somewhere in the SCA domain and that if
> running in a "
> + "remote node that the interface of the target service
> marked as @Remotable");
> }
>
> Continuing the approach of testing against a baseline scenario, I decided
> to run retrotranslator on SCA revision 643746. First, I verified that the
> revision works as expected. In other words, I downloaded and bulit the
> revision and ran the non-Android calculator sample. Then, I ran
> retrotranslator with the same options as those for the Android scenario. The
> result, I found, was pretty similar to the Android scenario:
>
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/subtractService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/multiplyService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/divideService
> Exception in thread "main" java.lang.NullPointerException
> at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
> at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
> at $Proxy0.add(Unknown Source)
> at calculator.CalculatorClient.main(CalculatorClient.java:37)
>
> The warning messages are something that is also found on the Android runs,
> as shown below. And the NullPointerException confirmed that there is indeed
> no wire to support the connection, as there are also problems invoking the
> service in this scenario.
>
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:15 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:16 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: No targets for reference: setAddService
>
> The conclusion I can draw from this is that retrotranslator is the one
> causing the problem. To further verify this, I narrowed down the
> retrotranslator runs on Android and the normal scenario to only those
> modules that rely on annotations. I experienced the same issue after running
> retrotranslator on this reduced set. Then I thought it would be a good idea
> to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
> experienced the same issues. In summary, even though retrotranslator was
> supposed to be a solution to the lack of Annotations support in Android, it
> is resulting in other problems which I have yet been able to determine.
>
> Overall, unfortunately, this means that Tuscany is still not running on
> Android. Up to this point I have identified an SCA subset to port and
> attempted porting it into Android by using retrotranslator. Additionally,
> with the help of Adriano, we have also cut corners by removing references to
> the Beans API and RMI API, both of which were interfering in previous
> attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
> much as possible to the project proposal, concentrating mainly on the
> porting part. In these last few days before the GSoC 'pencils down date' I
> will concentrate on testing Luciano's suggestion of removing @Remotable
> annotations. I will also update the JIRA ticket I created, with the reduced
> set of modules and the changes to SCA code. And lastly, I will update my
> project wiki to summarize the work performed throughout the project.
>
> Both Adriano and me signed a petition to have Google release an updated
> version of the Android SDK. The general sentiment in the Android Developer
> list is negative with respect to Google's silence on the matter of the
> Android SDK. There has been mention though, of a new SDK release sometime in
> September, when the second round of the Android Developer challenge comes to
> an end. I look forward to testing Tuscany on this new version of the SDK, to
> see if finally I can see it running on Android.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>
>
> On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> I think the class should be ok, as we just ask the classLoaders to
>> load it inside ClassReferenceModelResolver. Another thing to check is
>> how the CompositeProcessor is viewing the contents of
>> dex://calculator.android/raw/calculator.composite, it should be
>> available as XML, and parsing should be happening as expected in order
>> for the assembly model to be properly populated.
>>
>> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>> > <os...@gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> Thanks for your explanation. I think it is indeed the case that there
>> is
>> >> no wire to support the connection. I have the impression that the
>> service
>> >> does exist but the runtime thinks it doesn't or something else is going
>> >> wrong.
>> >>
>> >> I looked in more detail to see whether the composite is really being
>> read.
>> >> I found that ContributionServiceImpl.contribute() calls
>> >> ContributionServiceImpl.addContribution(). After debugging I found that
>> >> there is an exception after processReadPhase where the read problems
>> are
>> >> arising. The code excerpt below shows this step:
>> >>
>> >> try {
>> >> // Allow access to read system properties. Requires
>> >> PropertyPermission in security policy.
>> >> // Any security exceptions are caught and wrapped as
>> >> ContributionException.
>> >> processReadPhase(contribution, contributionArtifacts);
>> >> } catch ( Exception e ) {
>> >> throw new ContributionException(e);
>> >> }
>> >>
>> >> contribution is null and contributionArtifacts has the following
>> contents:
>> >>
>> >> [dex://calculator/CalculatorServiceImpl.class,
>> >> dex://calculator/AddServiceImpl.class,
>> >> dex://calculator/SubtractServiceImpl.class,
>> >> dex://calculator/MultiplyServiceImpl.class,
>> >> dex://calculator/DivideServiceImpl.class,
>> >> dex://calculator.android/raw/calculator.composite]
>> >>
>> >> In summary ContributionServiceImpl.contribute() is not returning
>> anything
>> >> but instead resulting in an exception. I will ask Adriano if the dex
>> >> protocol can read .class files, as Android doesn't use .class but .dex
>> >> instead. Maybe, dex protocol should access .dex files.
>> >>
>> >> Let me know if you have any pointers or ideas. I'll keep you posted if
>> I
>> >> find something new.
>> >>
>> >> Thanks for your help.
>> >>
>> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <
>> simonslaws@googlemail.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>> >>> <ad...@apache.org> wrote:
>> >>>>
>> >>>> Good summary Oscar : )
>> >>>>
>> >>>> I would like to reproduce your workspace and get this exception with
>> >>>> only the modules set your are using. I tried it, but I'm getting some
>> errors
>> >>>> related to missing classes from the modules I removed. Could you make
>> a new
>> >>>> step by step tutorial of how to reproduce a workspace like yours?
>> >>>>
>> >>>> Thanks,
>> >>>> Adriano Crestani
>> >>>>
>> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>> >>>> <os...@gmail.com> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I've been mostly using another thread for issues and questions
>> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
>> made and a
>> >>>>> new thread was needed.
>> >>>>>
>> >>>>> Recently, Adriano reported some errors while testing changes to the
>> >>>>> android sandbox and revision 674723 [1]. There was also a suggestion
>> from
>> >>>>> Luciano to look into calculator2 for coming up with a minimal set of
>> modules
>> >>>>> necessary to run calculator-android. I took the list of modules from
>> the
>> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> >>>>> calculator2, and augmented it based on dependencies from revision
>> 643746,
>> >>>>> which was a previous revision, until the point in which I received
>> the same
>> >>>>> errors [2] that Adriano had reported. These errors result in the
>> >>>>> RuntimeException shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
>> component
>> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>> >>>>> operation=add). Ensure that the composite containing the service is
>> loaded
>> >>>>> and started somewhere in the SCA domain and that if running in a
>> remote node
>> >>>>> that the interface of the target service marked as @Remotable
>> >>>>>
>> >>>>> Seeing this error the first question that came to mind was: how do I
>> >>>>> verify whether the composite containing the service is being loaded?
>> and,
>> >>>>> does it actually exist? I was thinking that maybe the composite was
>> not
>> >>>>> being created and thus was resulting in the errors in [3]. To test
>> this I
>> >>>>> changed the first line of "calculator_composite" to read as follows:
>> >>>>>
>> >>>>> <composite name="Calculator" autowire="true">
>> >>>>>
>> >>>>> Setting the autowire attribute to true would make the runtime
>> >>>>> automatically connect services and references in the composite,
>> granted
>> >>>>> there actually was one. This resulted in the error shown in [4] and
>> included
>> >>>>> in more detail in [5]. The fact that the runtime wires are being
>> created
>> >>>>> makes me think that a composite does exist, as documented in [6].
>> However,
>> >>>>> the error messages confuse me and make me think otherwise,
>> especially the
>> >>>>> one shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceRuntimeException:
>> org.osoa.sca.ServiceRuntimeException:
>> >>>>> Composite not found:
>> dex://calculator.android/raw/calculator.composite
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
>> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
>> previous
>> >>>>> thread, we have a feeling we're getting closer to successfully
>> embedding
>> >>>>> Tuscany/SCA in Android.
>> >>>>>
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> >>>>> [3]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> >>>>> [5]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> >>>>> [6]
>> >>>>>
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>> >>>>>
>> >>>>> --
>> >>>>> best,
>> >>>>> -oscar
>> >>>>>
>> >>>>> Oscar Castañeda
>> >>>
>> >>> Hi Oscar
>> >>>
>> >>> The ServiceUnavailableException you are seeing comes from the SCA
>> binding
>> >>> when it tries to create an invoker but it finds there is no wire to
>> support
>> >>> the connection. This can be the case if your reference targets a
>> service
>> >>> that doesn't exist or at least which the runtime doesn't think exists.
>> As an
>> >>> aside I guess you are working on oldish code in the sandbox as this
>> error
>> >>> message has changed now.
>> >>>
>> >>> First you need to look in some detail at whether the composite is
>> really
>> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
>> >>> returning anything?
>> >>>
>> >>> Simon
>> >>
>> >>
>> >>
>> >> --
>> >> best,
>> >> -oscar
>> >>
>> >> Oscar Castañeda
>> >
>> > Hi Oscar
>> >
>> > They look like the sort of artifacts that I would expect in a calculator
>> > sample contribution but you may be right that these would need
>> converting to
>> > dex files before they would run. Do you know what the exception is that
>> you
>> > are getting?
>> >
>> > Simon
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Aug 11, 2008 at 10:39 PM, Adriano Crestani <
adrianocrestani@apache.org> wrote:
> Good summary Oscar : )
>
> Yes, I know we haven't solved the problem yet, but now we know what it is.
> Unfortunately we got back to the point before using retrotranslator, it
> worked for what it was supposed to, but it messed something up :S.
>
> Yes, lets try the Luciano's suggestion and comment/workaround every SCA
> code line that tries to use the Reflect API (please, check my last emails
> about that on this thread). I think it will not take too much time, run the
> app on the Android platform and when you get an error, just look at that
> Android console for exception stack trace and fix it.
>
> Let us know if you have any questions
>
> Regards,
> Adriano Crestani
>
>
>
> On Mon, Aug 11, 2008 at 10:04 AM, Oscar Castaneda <
> oscar.castaneda.gsoc@gmail.com> wrote:
>
>> Thanks Luciano and Simon for your help in this thread. These past couple
>> of weeks I've been ardently debugging in the hopes of getting to the root of
>> the problem. While I have gained some insights, the issue is far from
>> resolved as problems still remain. I'm now a bit reluctant about whether use
>> of retrotranslator is a viable solution for this project. I'll explain below
>> along with a summary of the most important findings.
>>
>> Recently, Adriano reported some errors while testing changes to the
>> android sandbox and revision 674723 [1]. There was also a suggestion from
>> Luciano to look into calculator2 for coming up with a minimal set of modules
>> necessary to run calculator-android. I took the list of modules from the
>> tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
>> calculator2, and augmented it based on dependencies from revision 643746
>> until the point in which I received the same errors [2] that Adriano had
>> reported.
>>
>> These errors included a ServiceUnavailableException that, as Simon
>> explained, comes from the SCA binding when it tries to create an invoker but
>> it finds there is no wire to support the connection. I thought this might be
>> because of Android's use of the dex protocol but as Luciano explained, it
>> shouldn't be a problem as classLoaders were only loading stuff into
>> ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
>> the CompositeProcessor is able to view the contents of the calculator
>> composite.
>>
>> Further debugging showed that the calculator.composite is indeed being
>> read appropriately, eliminating the possibility of a parsing related issue.
>> I verified this by seeing the composite being correctly populated while
>> debugging. To accomplish this I compared the reduced Android SCA to revision
>> 643746 without the Android sandbox code and with the normal calculator
>> sample. This was suggested by Adriano as a way to approach testing and
>> debugging for Android.
>>
>> To further simplify the debugging runs I narrowed down the calculator
>> operations to only the "add" operation. I set a breakpoint in
>> RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
>> where the error is ocurring. I found that the problem is that the service,
>> as shown below, is being assigned a value of null.
>>
>> RuntimeComponentService service =
>> (RuntimeComponentService)target.getContract();
>>
>> In order to proceed, service must have a value other than null. Instead,
>> getInvoker() method returns a null invoker, which results in the
>> ServiceUnavailableException shown below:
>>
>> if (invoker == null) {
>> throw new ServiceUnavailableException("Service not found
>> for component " + component.getName()
>> + " reference "
>> + reference.getName()
>> + " (bindingURI="
>> + binding.getURI()
>> + " operation="
>> + operation.getName()
>> + "). Ensure that the composite containing the service
>> is loaded and "
>> + "started somewhere in the SCA domain and that if
>> running in a "
>> + "remote node that the interface of the target
>> service marked as @Remotable");
>> }
>>
>> Continuing the approach of testing against a baseline scenario, I decided
>> to run retrotranslator on SCA revision 643746. First, I verified that the
>> revision works as expected. In other words, I downloaded and bulit the
>> revision and ran the non-Android calculator sample. Then, I ran
>> retrotranslator with the same options as those for the Android scenario. The
>> result, I found, was pretty similar to the Android scenario:
>>
>> Aug 10, 2008 10:55:02 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARNING: Reference not found for component reference:
>> CalculatorServiceComponent/addService
>> Aug 10, 2008 10:55:02 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARNING: Reference not found for component reference:
>> CalculatorServiceComponent/subtractService
>> Aug 10, 2008 10:55:02 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARNING: Reference not found for component reference:
>> CalculatorServiceComponent/multiplyService
>> Aug 10, 2008 10:55:02 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARNING: Reference not found for component reference:
>> CalculatorServiceComponent/divideService
>> Exception in thread "main" java.lang.NullPointerException
>> at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:585)
>> at
>> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>> at
>> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>> at
>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>> at
>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>> at $Proxy0.add(Unknown Source)
>> at calculator.CalculatorClient.main(CalculatorClient.java:37)
>>
>> The warning messages are something that is also found on the Android runs,
>> as shown below. And the NullPointerException confirmed that there is indeed
>> no wire to support the connection, as there are also problems invoking the
>> service in this scenario.
>>
>> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
>> Aug 8, 2008 5:59:15 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
>> WARNING: Reference not found for component reference:
>> CalculatorServiceComponent/addService
>> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
>> Aug 8, 2008 5:59:16 PM
>> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
>> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
>> WARNING: No targets for reference: setAddService
>>
>> The conclusion I can draw from this is that retrotranslator is the one
>> causing the problem. To further verify this, I narrowed down the
>> retrotranslator runs on Android and the normal scenario to only those
>> modules that rely on annotations. I experienced the same issue after running
>> retrotranslator on this reduced set. Then I thought it would be a good idea
>> to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
>> experienced the same issues. In summary, even though retrotranslator was
>> supposed to be a solution to the lack of Annotations support in Android, it
>> is resulting in other problems which I have yet been able to determine.
>>
>> Overall, unfortunately, this means that Tuscany is still not running on
>> Android. Up to this point I have identified an SCA subset to port and
>> attempted porting it into Android by using retrotranslator. Additionally,
>> with the help of Adriano, we have also cut corners by removing references to
>> the Beans API and RMI API, both of which were interfering in previous
>> attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
>> much as possible to the project proposal, concentrating mainly on the
>> porting part. In these last few days before the GSoC 'pencils down date' I
>> will concentrate on testing Luciano's suggestion of removing @Remotable
>> annotations. I will also update the JIRA ticket I created, with the reduced
>> set of modules and the changes to SCA code. And lastly, I will update my
>> project wiki to summarize the work performed throughout the project.
>>
>> Both Adriano and me signed a petition to have Google release an updated
>> version of the Android SDK. The general sentiment in the Android Developer
>> list is negative with respect to Google's silence on the matter of the
>> Android SDK. There has been mention though, of a new SDK release sometime in
>> September, when the second round of the Android Developer challenge comes to
>> an end. I look forward to testing Tuscany on this new version of the SDK, to
>> see if finally I can see it running on Android.
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>>
>>
>> On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
>>
>>> I think the class should be ok, as we just ask the classLoaders to
>>> load it inside ClassReferenceModelResolver. Another thing to check is
>>> how the CompositeProcessor is viewing the contents of
>>> dex://calculator.android/raw/calculator.composite, it should be
>>> available as XML, and parsing should be happening as expected in order
>>> for the assembly model to be properly populated.
>>>
>>> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
>>> wrote:
>>> >
>>> >
>>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>>> > <os...@gmail.com> wrote:
>>> >>
>>> >> Hi Simon,
>>> >>
>>> >> Thanks for your explanation. I think it is indeed the case that there
>>> is
>>> >> no wire to support the connection. I have the impression that the
>>> service
>>> >> does exist but the runtime thinks it doesn't or something else is
>>> going
>>> >> wrong.
>>> >>
>>> >> I looked in more detail to see whether the composite is really being
>>> read.
>>> >> I found that ContributionServiceImpl.contribute() calls
>>> >> ContributionServiceImpl.addContribution(). After debugging I found
>>> that
>>> >> there is an exception after processReadPhase where the read problems
>>> are
>>> >> arising. The code excerpt below shows this step:
>>> >>
>>> >> try {
>>> >> // Allow access to read system properties. Requires
>>> >> PropertyPermission in security policy.
>>> >> // Any security exceptions are caught and wrapped as
>>> >> ContributionException.
>>> >> processReadPhase(contribution, contributionArtifacts);
>>> >> } catch ( Exception e ) {
>>> >> throw new ContributionException(e);
>>> >> }
>>> >>
>>> >> contribution is null and contributionArtifacts has the following
>>> contents:
>>> >>
>>> >> [dex://calculator/CalculatorServiceImpl.class,
>>> >> dex://calculator/AddServiceImpl.class,
>>> >> dex://calculator/SubtractServiceImpl.class,
>>> >> dex://calculator/MultiplyServiceImpl.class,
>>> >> dex://calculator/DivideServiceImpl.class,
>>> >> dex://calculator.android/raw/calculator.composite]
>>> >>
>>> >> In summary ContributionServiceImpl.contribute() is not returning
>>> anything
>>> >> but instead resulting in an exception. I will ask Adriano if the dex
>>> >> protocol can read .class files, as Android doesn't use .class but .dex
>>> >> instead. Maybe, dex protocol should access .dex files.
>>> >>
>>> >> Let me know if you have any pointers or ideas. I'll keep you posted if
>>> I
>>> >> find something new.
>>> >>
>>> >> Thanks for your help.
>>> >>
>>> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <
>>> simonslaws@googlemail.com>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>>> >>> <ad...@apache.org> wrote:
>>> >>>>
>>> >>>> Good summary Oscar : )
>>> >>>>
>>> >>>> I would like to reproduce your workspace and get this exception with
>>> >>>> only the modules set your are using. I tried it, but I'm getting
>>> some errors
>>> >>>> related to missing classes from the modules I removed. Could you
>>> make a new
>>> >>>> step by step tutorial of how to reproduce a workspace like yours?
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Adriano Crestani
>>> >>>>
>>> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>>> >>>> <os...@gmail.com> wrote:
>>> >>>>>
>>> >>>>> Hi,
>>> >>>>>
>>> >>>>> I've been mostly using another thread for issues and questions
>>> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
>>> made and a
>>> >>>>> new thread was needed.
>>> >>>>>
>>> >>>>> Recently, Adriano reported some errors while testing changes to the
>>> >>>>> android sandbox and revision 674723 [1]. There was also a
>>> suggestion from
>>> >>>>> Luciano to look into calculator2 for coming up with a minimal set
>>> of modules
>>> >>>>> necessary to run calculator-android. I took the list of modules
>>> from the
>>> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>>> >>>>> calculator2, and augmented it based on dependencies from revision
>>> 643746,
>>> >>>>> which was a previous revision, until the point in which I received
>>> the same
>>> >>>>> errors [2] that Adriano had reported. These errors result in the
>>> >>>>> RuntimeException shown below:
>>> >>>>>
>>> >>>>> java.lang.RuntimeException: Unable to start activity
>>> >>>>>
>>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>>> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
>>> component
>>> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>>> >>>>> operation=add). Ensure that the composite containing the service is
>>> loaded
>>> >>>>> and started somewhere in the SCA domain and that if running in a
>>> remote node
>>> >>>>> that the interface of the target service marked as @Remotable
>>> >>>>>
>>> >>>>> Seeing this error the first question that came to mind was: how do
>>> I
>>> >>>>> verify whether the composite containing the service is being
>>> loaded? and,
>>> >>>>> does it actually exist? I was thinking that maybe the composite was
>>> not
>>> >>>>> being created and thus was resulting in the errors in [3]. To test
>>> this I
>>> >>>>> changed the first line of "calculator_composite" to read as
>>> follows:
>>> >>>>>
>>> >>>>> <composite name="Calculator" autowire="true">
>>> >>>>>
>>> >>>>> Setting the autowire attribute to true would make the runtime
>>> >>>>> automatically connect services and references in the composite,
>>> granted
>>> >>>>> there actually was one. This resulted in the error shown in [4] and
>>> included
>>> >>>>> in more detail in [5]. The fact that the runtime wires are being
>>> created
>>> >>>>> makes me think that a composite does exist, as documented in [6].
>>> However,
>>> >>>>> the error messages confuse me and make me think otherwise,
>>> especially the
>>> >>>>> one shown below:
>>> >>>>>
>>> >>>>> java.lang.RuntimeException: Unable to start activity
>>> >>>>>
>>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>>> >>>>> org.osoa.sca.ServiceRuntimeException:
>>> org.osoa.sca.ServiceRuntimeException:
>>> >>>>> Composite not found:
>>> dex://calculator.android/raw/calculator.composite
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
>>> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
>>> previous
>>> >>>>> thread, we have a feeling we're getting closer to successfully
>>> embedding
>>> >>>>> Tuscany/SCA in Android.
>>> >>>>>
>>> >>>>>
>>> >>>>> [1]
>>> >>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>>> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>>> >>>>> [3]
>>> >>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>>> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>>> >>>>> [5]
>>> >>>>>
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>>> >>>>> [6]
>>> >>>>>
>>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>> >>>>>
>>> >>>>> --
>>> >>>>> best,
>>> >>>>> -oscar
>>> >>>>>
>>> >>>>> Oscar Castañeda
>>> >>>
>>> >>> Hi Oscar
>>> >>>
>>> >>> The ServiceUnavailableException you are seeing comes from the SCA
>>> binding
>>> >>> when it tries to create an invoker but it finds there is no wire to
>>> support
>>> >>> the connection. This can be the case if your reference targets a
>>> service
>>> >>> that doesn't exist or at least which the runtime doesn't think
>>> exists. As an
>>> >>> aside I guess you are working on oldish code in the sandbox as this
>>> error
>>> >>> message has changed now.
>>> >>>
>>> >>> First you need to look in some detail at whether the composite is
>>> really
>>> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
>>> >>> returning anything?
>>> >>>
>>> >>> Simon
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> best,
>>> >> -oscar
>>> >>
>>> >> Oscar Castañeda
>>> >
>>> > Hi Oscar
>>> >
>>> > They look like the sort of artifacts that I would expect in a
>>> calculator
>>> > sample contribution but you may be right that these would need
>>> converting to
>>> > dex files before they would run. Do you know what the exception is that
>>> you
>>> > are getting?
>>> >
>>> > Simon
>>> >
>>>
>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany Committer
>>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
>>> http://lresende.blogspot.com/
>>>
>>
>>
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>>
>
>
Hi
You shouldn't be forced to use annotation in SCA applications. Particularly
in this simple scenario. The Java introspection code should be able to
handle the case where there are no annotations in the component
implementation. When injecting references the runtime will look in the
component implementation for public fields or fields with setters and
getters that match the reference names that appear in the composite file.
There is also the option of specifying compoment type information in a side
file so if you need to do without annotations you should be able to do
that.
Regards
Simon
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Good summary Oscar : )
Yes, I know we haven't solved the problem yet, but now we know what it is.
Unfortunately we got back to the point before using retrotranslator, it
worked for what it was supposed to, but it messed something up :S.
Yes, lets try the Luciano's suggestion and comment/workaround every SCA code
line that tries to use the Reflect API (please, check my last emails about
that on this thread). I think it will not take too much time, run the app on
the Android platform and when you get an error, just look at that Android
console for exception stack trace and fix it.
Let us know if you have any questions
Regards,
Adriano Crestani
On Mon, Aug 11, 2008 at 10:04 AM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Thanks Luciano and Simon for your help in this thread. These past couple of
> weeks I've been ardently debugging in the hopes of getting to the root of
> the problem. While I have gained some insights, the issue is far from
> resolved as problems still remain. I'm now a bit reluctant about whether use
> of retrotranslator is a viable solution for this project. I'll explain below
> along with a summary of the most important findings.
>
> Recently, Adriano reported some errors while testing changes to the android
> sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
> look into calculator2 for coming up with a minimal set of modules necessary
> to run calculator-android. I took the list of modules from the
> tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
> calculator2, and augmented it based on dependencies from revision 643746
> until the point in which I received the same errors [2] that Adriano had
> reported.
>
> These errors included a ServiceUnavailableException that, as Simon
> explained, comes from the SCA binding when it tries to create an invoker but
> it finds there is no wire to support the connection. I thought this might be
> because of Android's use of the dex protocol but as Luciano explained, it
> shouldn't be a problem as classLoaders were only loading stuff into
> ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
> the CompositeProcessor is able to view the contents of the calculator
> composite.
>
> Further debugging showed that the calculator.composite is indeed being read
> appropriately, eliminating the possibility of a parsing related issue. I
> verified this by seeing the composite being correctly populated while
> debugging. To accomplish this I compared the reduced Android SCA to revision
> 643746 without the Android sandbox code and with the normal calculator
> sample. This was suggested by Adriano as a way to approach testing and
> debugging for Android.
>
> To further simplify the debugging runs I narrowed down the calculator
> operations to only the "add" operation. I set a breakpoint in
> RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
> where the error is ocurring. I found that the problem is that the service,
> as shown below, is being assigned a value of null.
>
> RuntimeComponentService service =
> (RuntimeComponentService)target.getContract();
>
> In order to proceed, service must have a value other than null. Instead,
> getInvoker() method returns a null invoker, which results in the
> ServiceUnavailableException shown below:
>
> if (invoker == null) {
> throw new ServiceUnavailableException("Service not found
> for component " + component.getName()
> + " reference "
> + reference.getName()
> + " (bindingURI="
> + binding.getURI()
> + " operation="
> + operation.getName()
> + "). Ensure that the composite containing the service
> is loaded and "
> + "started somewhere in the SCA domain and that if
> running in a "
> + "remote node that the interface of the target service
> marked as @Remotable");
> }
>
> Continuing the approach of testing against a baseline scenario, I decided
> to run retrotranslator on SCA revision 643746. First, I verified that the
> revision works as expected. In other words, I downloaded and bulit the
> revision and ran the non-Android calculator sample. Then, I ran
> retrotranslator with the same options as those for the Android scenario. The
> result, I found, was pretty similar to the Android scenario:
>
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/subtractService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/multiplyService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/divideService
> Exception in thread "main" java.lang.NullPointerException
> at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
> at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
> at $Proxy0.add(Unknown Source)
> at calculator.CalculatorClient.main(CalculatorClient.java:37)
>
> The warning messages are something that is also found on the Android runs,
> as shown below. And the NullPointerException confirmed that there is indeed
> no wire to support the connection, as there are also problems invoking the
> service in this scenario.
>
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:15 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:16 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: No targets for reference: setAddService
>
> The conclusion I can draw from this is that retrotranslator is the one
> causing the problem. To further verify this, I narrowed down the
> retrotranslator runs on Android and the normal scenario to only those
> modules that rely on annotations. I experienced the same issue after running
> retrotranslator on this reduced set. Then I thought it would be a good idea
> to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
> experienced the same issues. In summary, even though retrotranslator was
> supposed to be a solution to the lack of Annotations support in Android, it
> is resulting in other problems which I have yet been able to determine.
>
> Overall, unfortunately, this means that Tuscany is still not running on
> Android. Up to this point I have identified an SCA subset to port and
> attempted porting it into Android by using retrotranslator. Additionally,
> with the help of Adriano, we have also cut corners by removing references to
> the Beans API and RMI API, both of which were interfering in previous
> attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
> much as possible to the project proposal, concentrating mainly on the
> porting part. In these last few days before the GSoC 'pencils down date' I
> will concentrate on testing Luciano's suggestion of removing @Remotable
> annotations. I will also update the JIRA ticket I created, with the reduced
> set of modules and the changes to SCA code. And lastly, I will update my
> project wiki to summarize the work performed throughout the project.
>
> Both Adriano and me signed a petition to have Google release an updated
> version of the Android SDK. The general sentiment in the Android Developer
> list is negative with respect to Google's silence on the matter of the
> Android SDK. There has been mention though, of a new SDK release sometime in
> September, when the second round of the Android Developer challenge comes to
> an end. I look forward to testing Tuscany on this new version of the SDK, to
> see if finally I can see it running on Android.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>
>
> On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> I think the class should be ok, as we just ask the classLoaders to
>> load it inside ClassReferenceModelResolver. Another thing to check is
>> how the CompositeProcessor is viewing the contents of
>> dex://calculator.android/raw/calculator.composite, it should be
>> available as XML, and parsing should be happening as expected in order
>> for the assembly model to be properly populated.
>>
>> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>> > <os...@gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> Thanks for your explanation. I think it is indeed the case that there
>> is
>> >> no wire to support the connection. I have the impression that the
>> service
>> >> does exist but the runtime thinks it doesn't or something else is going
>> >> wrong.
>> >>
>> >> I looked in more detail to see whether the composite is really being
>> read.
>> >> I found that ContributionServiceImpl.contribute() calls
>> >> ContributionServiceImpl.addContribution(). After debugging I found that
>> >> there is an exception after processReadPhase where the read problems
>> are
>> >> arising. The code excerpt below shows this step:
>> >>
>> >> try {
>> >> // Allow access to read system properties. Requires
>> >> PropertyPermission in security policy.
>> >> // Any security exceptions are caught and wrapped as
>> >> ContributionException.
>> >> processReadPhase(contribution, contributionArtifacts);
>> >> } catch ( Exception e ) {
>> >> throw new ContributionException(e);
>> >> }
>> >>
>> >> contribution is null and contributionArtifacts has the following
>> contents:
>> >>
>> >> [dex://calculator/CalculatorServiceImpl.class,
>> >> dex://calculator/AddServiceImpl.class,
>> >> dex://calculator/SubtractServiceImpl.class,
>> >> dex://calculator/MultiplyServiceImpl.class,
>> >> dex://calculator/DivideServiceImpl.class,
>> >> dex://calculator.android/raw/calculator.composite]
>> >>
>> >> In summary ContributionServiceImpl.contribute() is not returning
>> anything
>> >> but instead resulting in an exception. I will ask Adriano if the dex
>> >> protocol can read .class files, as Android doesn't use .class but .dex
>> >> instead. Maybe, dex protocol should access .dex files.
>> >>
>> >> Let me know if you have any pointers or ideas. I'll keep you posted if
>> I
>> >> find something new.
>> >>
>> >> Thanks for your help.
>> >>
>> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <
>> simonslaws@googlemail.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>> >>> <ad...@apache.org> wrote:
>> >>>>
>> >>>> Good summary Oscar : )
>> >>>>
>> >>>> I would like to reproduce your workspace and get this exception with
>> >>>> only the modules set your are using. I tried it, but I'm getting some
>> errors
>> >>>> related to missing classes from the modules I removed. Could you make
>> a new
>> >>>> step by step tutorial of how to reproduce a workspace like yours?
>> >>>>
>> >>>> Thanks,
>> >>>> Adriano Crestani
>> >>>>
>> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>> >>>> <os...@gmail.com> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I've been mostly using another thread for issues and questions
>> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
>> made and a
>> >>>>> new thread was needed.
>> >>>>>
>> >>>>> Recently, Adriano reported some errors while testing changes to the
>> >>>>> android sandbox and revision 674723 [1]. There was also a suggestion
>> from
>> >>>>> Luciano to look into calculator2 for coming up with a minimal set of
>> modules
>> >>>>> necessary to run calculator-android. I took the list of modules from
>> the
>> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> >>>>> calculator2, and augmented it based on dependencies from revision
>> 643746,
>> >>>>> which was a previous revision, until the point in which I received
>> the same
>> >>>>> errors [2] that Adriano had reported. These errors result in the
>> >>>>> RuntimeException shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
>> component
>> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>> >>>>> operation=add). Ensure that the composite containing the service is
>> loaded
>> >>>>> and started somewhere in the SCA domain and that if running in a
>> remote node
>> >>>>> that the interface of the target service marked as @Remotable
>> >>>>>
>> >>>>> Seeing this error the first question that came to mind was: how do I
>> >>>>> verify whether the composite containing the service is being loaded?
>> and,
>> >>>>> does it actually exist? I was thinking that maybe the composite was
>> not
>> >>>>> being created and thus was resulting in the errors in [3]. To test
>> this I
>> >>>>> changed the first line of "calculator_composite" to read as follows:
>> >>>>>
>> >>>>> <composite name="Calculator" autowire="true">
>> >>>>>
>> >>>>> Setting the autowire attribute to true would make the runtime
>> >>>>> automatically connect services and references in the composite,
>> granted
>> >>>>> there actually was one. This resulted in the error shown in [4] and
>> included
>> >>>>> in more detail in [5]. The fact that the runtime wires are being
>> created
>> >>>>> makes me think that a composite does exist, as documented in [6].
>> However,
>> >>>>> the error messages confuse me and make me think otherwise,
>> especially the
>> >>>>> one shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceRuntimeException:
>> org.osoa.sca.ServiceRuntimeException:
>> >>>>> Composite not found:
>> dex://calculator.android/raw/calculator.composite
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
>> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
>> previous
>> >>>>> thread, we have a feeling we're getting closer to successfully
>> embedding
>> >>>>> Tuscany/SCA in Android.
>> >>>>>
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> >>>>> [3]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> >>>>> [5]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> >>>>> [6]
>> >>>>>
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>> >>>>>
>> >>>>> --
>> >>>>> best,
>> >>>>> -oscar
>> >>>>>
>> >>>>> Oscar Castañeda
>> >>>
>> >>> Hi Oscar
>> >>>
>> >>> The ServiceUnavailableException you are seeing comes from the SCA
>> binding
>> >>> when it tries to create an invoker but it finds there is no wire to
>> support
>> >>> the connection. This can be the case if your reference targets a
>> service
>> >>> that doesn't exist or at least which the runtime doesn't think exists.
>> As an
>> >>> aside I guess you are working on oldish code in the sandbox as this
>> error
>> >>> message has changed now.
>> >>>
>> >>> First you need to look in some detail at whether the composite is
>> really
>> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
>> >>> returning anything?
>> >>>
>> >>> Simon
>> >>
>> >>
>> >>
>> >> --
>> >> best,
>> >> -oscar
>> >>
>> >> Oscar Castañeda
>> >
>> > Hi Oscar
>> >
>> > They look like the sort of artifacts that I would expect in a calculator
>> > sample contribution but you may be right that these would need
>> converting to
>> > dex files before they would run. Do you know what the exception is that
>> you
>> > are getting?
>> >
>> > Simon
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Good summary Oscar : )
Yes, I know we haven't solved the problem yet, but now we know what it is.
Unfortunately we got back to the point before using retrotranslator, it
worked for what it was supposed to, but it messed something up :S.
Yes, lets try the Luciano's suggestion and comment/workaround every SCA code
line that tries to use the Reflect API (please, check my last emails about
that on this thread). I think it will not take too much time, run the app on
the Android platform and when you get an error, just look at that Android
console for exception stack trace and fix it.
Let us know if you have any questions
Regards,
Adriano Crestani
On Mon, Aug 11, 2008 at 10:04 AM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Thanks Luciano and Simon for your help in this thread. These past couple of
> weeks I've been ardently debugging in the hopes of getting to the root of
> the problem. While I have gained some insights, the issue is far from
> resolved as problems still remain. I'm now a bit reluctant about whether use
> of retrotranslator is a viable solution for this project. I'll explain below
> along with a summary of the most important findings.
>
> Recently, Adriano reported some errors while testing changes to the android
> sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
> look into calculator2 for coming up with a minimal set of modules necessary
> to run calculator-android. I took the list of modules from the
> tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
> calculator2, and augmented it based on dependencies from revision 643746
> until the point in which I received the same errors [2] that Adriano had
> reported.
>
> These errors included a ServiceUnavailableException that, as Simon
> explained, comes from the SCA binding when it tries to create an invoker but
> it finds there is no wire to support the connection. I thought this might be
> because of Android's use of the dex protocol but as Luciano explained, it
> shouldn't be a problem as classLoaders were only loading stuff into
> ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
> the CompositeProcessor is able to view the contents of the calculator
> composite.
>
> Further debugging showed that the calculator.composite is indeed being read
> appropriately, eliminating the possibility of a parsing related issue. I
> verified this by seeing the composite being correctly populated while
> debugging. To accomplish this I compared the reduced Android SCA to revision
> 643746 without the Android sandbox code and with the normal calculator
> sample. This was suggested by Adriano as a way to approach testing and
> debugging for Android.
>
> To further simplify the debugging runs I narrowed down the calculator
> operations to only the "add" operation. I set a breakpoint in
> RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
> where the error is ocurring. I found that the problem is that the service,
> as shown below, is being assigned a value of null.
>
> RuntimeComponentService service =
> (RuntimeComponentService)target.getContract();
>
> In order to proceed, service must have a value other than null. Instead,
> getInvoker() method returns a null invoker, which results in the
> ServiceUnavailableException shown below:
>
> if (invoker == null) {
> throw new ServiceUnavailableException("Service not found
> for component " + component.getName()
> + " reference "
> + reference.getName()
> + " (bindingURI="
> + binding.getURI()
> + " operation="
> + operation.getName()
> + "). Ensure that the composite containing the service
> is loaded and "
> + "started somewhere in the SCA domain and that if
> running in a "
> + "remote node that the interface of the target service
> marked as @Remotable");
> }
>
> Continuing the approach of testing against a baseline scenario, I decided
> to run retrotranslator on SCA revision 643746. First, I verified that the
> revision works as expected. In other words, I downloaded and bulit the
> revision and ran the non-Android calculator sample. Then, I ran
> retrotranslator with the same options as those for the Android scenario. The
> result, I found, was pretty similar to the Android scenario:
>
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/subtractService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/multiplyService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/divideService
> Exception in thread "main" java.lang.NullPointerException
> at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
> at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
> at $Proxy0.add(Unknown Source)
> at calculator.CalculatorClient.main(CalculatorClient.java:37)
>
> The warning messages are something that is also found on the Android runs,
> as shown below. And the NullPointerException confirmed that there is indeed
> no wire to support the connection, as there are also problems invoking the
> service in this scenario.
>
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:15 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:16 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: No targets for reference: setAddService
>
> The conclusion I can draw from this is that retrotranslator is the one
> causing the problem. To further verify this, I narrowed down the
> retrotranslator runs on Android and the normal scenario to only those
> modules that rely on annotations. I experienced the same issue after running
> retrotranslator on this reduced set. Then I thought it would be a good idea
> to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
> experienced the same issues. In summary, even though retrotranslator was
> supposed to be a solution to the lack of Annotations support in Android, it
> is resulting in other problems which I have yet been able to determine.
>
> Overall, unfortunately, this means that Tuscany is still not running on
> Android. Up to this point I have identified an SCA subset to port and
> attempted porting it into Android by using retrotranslator. Additionally,
> with the help of Adriano, we have also cut corners by removing references to
> the Beans API and RMI API, both of which were interfering in previous
> attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
> much as possible to the project proposal, concentrating mainly on the
> porting part. In these last few days before the GSoC 'pencils down date' I
> will concentrate on testing Luciano's suggestion of removing @Remotable
> annotations. I will also update the JIRA ticket I created, with the reduced
> set of modules and the changes to SCA code. And lastly, I will update my
> project wiki to summarize the work performed throughout the project.
>
> Both Adriano and me signed a petition to have Google release an updated
> version of the Android SDK. The general sentiment in the Android Developer
> list is negative with respect to Google's silence on the matter of the
> Android SDK. There has been mention though, of a new SDK release sometime in
> September, when the second round of the Android Developer challenge comes to
> an end. I look forward to testing Tuscany on this new version of the SDK, to
> see if finally I can see it running on Android.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>
>
> On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> I think the class should be ok, as we just ask the classLoaders to
>> load it inside ClassReferenceModelResolver. Another thing to check is
>> how the CompositeProcessor is viewing the contents of
>> dex://calculator.android/raw/calculator.composite, it should be
>> available as XML, and parsing should be happening as expected in order
>> for the assembly model to be properly populated.
>>
>> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>> > <os...@gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> Thanks for your explanation. I think it is indeed the case that there
>> is
>> >> no wire to support the connection. I have the impression that the
>> service
>> >> does exist but the runtime thinks it doesn't or something else is going
>> >> wrong.
>> >>
>> >> I looked in more detail to see whether the composite is really being
>> read.
>> >> I found that ContributionServiceImpl.contribute() calls
>> >> ContributionServiceImpl.addContribution(). After debugging I found that
>> >> there is an exception after processReadPhase where the read problems
>> are
>> >> arising. The code excerpt below shows this step:
>> >>
>> >> try {
>> >> // Allow access to read system properties. Requires
>> >> PropertyPermission in security policy.
>> >> // Any security exceptions are caught and wrapped as
>> >> ContributionException.
>> >> processReadPhase(contribution, contributionArtifacts);
>> >> } catch ( Exception e ) {
>> >> throw new ContributionException(e);
>> >> }
>> >>
>> >> contribution is null and contributionArtifacts has the following
>> contents:
>> >>
>> >> [dex://calculator/CalculatorServiceImpl.class,
>> >> dex://calculator/AddServiceImpl.class,
>> >> dex://calculator/SubtractServiceImpl.class,
>> >> dex://calculator/MultiplyServiceImpl.class,
>> >> dex://calculator/DivideServiceImpl.class,
>> >> dex://calculator.android/raw/calculator.composite]
>> >>
>> >> In summary ContributionServiceImpl.contribute() is not returning
>> anything
>> >> but instead resulting in an exception. I will ask Adriano if the dex
>> >> protocol can read .class files, as Android doesn't use .class but .dex
>> >> instead. Maybe, dex protocol should access .dex files.
>> >>
>> >> Let me know if you have any pointers or ideas. I'll keep you posted if
>> I
>> >> find something new.
>> >>
>> >> Thanks for your help.
>> >>
>> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <
>> simonslaws@googlemail.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>> >>> <ad...@apache.org> wrote:
>> >>>>
>> >>>> Good summary Oscar : )
>> >>>>
>> >>>> I would like to reproduce your workspace and get this exception with
>> >>>> only the modules set your are using. I tried it, but I'm getting some
>> errors
>> >>>> related to missing classes from the modules I removed. Could you make
>> a new
>> >>>> step by step tutorial of how to reproduce a workspace like yours?
>> >>>>
>> >>>> Thanks,
>> >>>> Adriano Crestani
>> >>>>
>> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>> >>>> <os...@gmail.com> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I've been mostly using another thread for issues and questions
>> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
>> made and a
>> >>>>> new thread was needed.
>> >>>>>
>> >>>>> Recently, Adriano reported some errors while testing changes to the
>> >>>>> android sandbox and revision 674723 [1]. There was also a suggestion
>> from
>> >>>>> Luciano to look into calculator2 for coming up with a minimal set of
>> modules
>> >>>>> necessary to run calculator-android. I took the list of modules from
>> the
>> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> >>>>> calculator2, and augmented it based on dependencies from revision
>> 643746,
>> >>>>> which was a previous revision, until the point in which I received
>> the same
>> >>>>> errors [2] that Adriano had reported. These errors result in the
>> >>>>> RuntimeException shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
>> component
>> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>> >>>>> operation=add). Ensure that the composite containing the service is
>> loaded
>> >>>>> and started somewhere in the SCA domain and that if running in a
>> remote node
>> >>>>> that the interface of the target service marked as @Remotable
>> >>>>>
>> >>>>> Seeing this error the first question that came to mind was: how do I
>> >>>>> verify whether the composite containing the service is being loaded?
>> and,
>> >>>>> does it actually exist? I was thinking that maybe the composite was
>> not
>> >>>>> being created and thus was resulting in the errors in [3]. To test
>> this I
>> >>>>> changed the first line of "calculator_composite" to read as follows:
>> >>>>>
>> >>>>> <composite name="Calculator" autowire="true">
>> >>>>>
>> >>>>> Setting the autowire attribute to true would make the runtime
>> >>>>> automatically connect services and references in the composite,
>> granted
>> >>>>> there actually was one. This resulted in the error shown in [4] and
>> included
>> >>>>> in more detail in [5]. The fact that the runtime wires are being
>> created
>> >>>>> makes me think that a composite does exist, as documented in [6].
>> However,
>> >>>>> the error messages confuse me and make me think otherwise,
>> especially the
>> >>>>> one shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceRuntimeException:
>> org.osoa.sca.ServiceRuntimeException:
>> >>>>> Composite not found:
>> dex://calculator.android/raw/calculator.composite
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
>> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
>> previous
>> >>>>> thread, we have a feeling we're getting closer to successfully
>> embedding
>> >>>>> Tuscany/SCA in Android.
>> >>>>>
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> >>>>> [3]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> >>>>> [5]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> >>>>> [6]
>> >>>>>
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>> >>>>>
>> >>>>> --
>> >>>>> best,
>> >>>>> -oscar
>> >>>>>
>> >>>>> Oscar Castañeda
>> >>>
>> >>> Hi Oscar
>> >>>
>> >>> The ServiceUnavailableException you are seeing comes from the SCA
>> binding
>> >>> when it tries to create an invoker but it finds there is no wire to
>> support
>> >>> the connection. This can be the case if your reference targets a
>> service
>> >>> that doesn't exist or at least which the runtime doesn't think exists.
>> As an
>> >>> aside I guess you are working on oldish code in the sandbox as this
>> error
>> >>> message has changed now.
>> >>>
>> >>> First you need to look in some detail at whether the composite is
>> really
>> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
>> >>> returning anything?
>> >>>
>> >>> Simon
>> >>
>> >>
>> >>
>> >> --
>> >> best,
>> >> -oscar
>> >>
>> >> Oscar Castañeda
>> >
>> > Hi Oscar
>> >
>> > They look like the sort of artifacts that I would expect in a calculator
>> > sample contribution but you may be right that these would need
>> converting to
>> > dex files before they would run. Do you know what the exception is that
>> you
>> > are getting?
>> >
>> > Simon
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Good summary Oscar : )
Yes, I know we haven't solved the problem yet, but now we know what it is.
Unfortunately we got back to the point before using retrotranslator, it
worked for what it was supposed to, but it messed something up :S.
Yes, lets try the Luciano's suggestion and comment/workaround every SCA code
line that tries to use the Reflect API (please, check my last emails about
that on this thread). I think it will not take too much time, run the app on
the Android platform and when you get an error, just look at that Android
console for exception stack trace and fix it.
Let us know if you have any questions
Regards,
Adriano Crestani
On Mon, Aug 11, 2008 at 10:04 AM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Thanks Luciano and Simon for your help in this thread. These past couple of
> weeks I've been ardently debugging in the hopes of getting to the root of
> the problem. While I have gained some insights, the issue is far from
> resolved as problems still remain. I'm now a bit reluctant about whether use
> of retrotranslator is a viable solution for this project. I'll explain below
> along with a summary of the most important findings.
>
> Recently, Adriano reported some errors while testing changes to the android
> sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
> look into calculator2 for coming up with a minimal set of modules necessary
> to run calculator-android. I took the list of modules from the
> tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
> calculator2, and augmented it based on dependencies from revision 643746
> until the point in which I received the same errors [2] that Adriano had
> reported.
>
> These errors included a ServiceUnavailableException that, as Simon
> explained, comes from the SCA binding when it tries to create an invoker but
> it finds there is no wire to support the connection. I thought this might be
> because of Android's use of the dex protocol but as Luciano explained, it
> shouldn't be a problem as classLoaders were only loading stuff into
> ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
> the CompositeProcessor is able to view the contents of the calculator
> composite.
>
> Further debugging showed that the calculator.composite is indeed being read
> appropriately, eliminating the possibility of a parsing related issue. I
> verified this by seeing the composite being correctly populated while
> debugging. To accomplish this I compared the reduced Android SCA to revision
> 643746 without the Android sandbox code and with the normal calculator
> sample. This was suggested by Adriano as a way to approach testing and
> debugging for Android.
>
> To further simplify the debugging runs I narrowed down the calculator
> operations to only the "add" operation. I set a breakpoint in
> RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
> where the error is ocurring. I found that the problem is that the service,
> as shown below, is being assigned a value of null.
>
> RuntimeComponentService service =
> (RuntimeComponentService)target.getContract();
>
> In order to proceed, service must have a value other than null. Instead,
> getInvoker() method returns a null invoker, which results in the
> ServiceUnavailableException shown below:
>
> if (invoker == null) {
> throw new ServiceUnavailableException("Service not found
> for component " + component.getName()
> + " reference "
> + reference.getName()
> + " (bindingURI="
> + binding.getURI()
> + " operation="
> + operation.getName()
> + "). Ensure that the composite containing the service
> is loaded and "
> + "started somewhere in the SCA domain and that if
> running in a "
> + "remote node that the interface of the target service
> marked as @Remotable");
> }
>
> Continuing the approach of testing against a baseline scenario, I decided
> to run retrotranslator on SCA revision 643746. First, I verified that the
> revision works as expected. In other words, I downloaded and bulit the
> revision and ran the non-Android calculator sample. Then, I ran
> retrotranslator with the same options as those for the Android scenario. The
> result, I found, was pretty similar to the Android scenario:
>
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/subtractService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/multiplyService
> Aug 10, 2008 10:55:02 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/divideService
> Exception in thread "main" java.lang.NullPointerException
> at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
> at
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
> at
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
> at $Proxy0.add(Unknown Source)
> at calculator.CalculatorClient.main(CalculatorClient.java:37)
>
> The warning messages are something that is also found on the Android runs,
> as shown below. And the NullPointerException confirmed that there is indeed
> no wire to support the connection, as there are also problems invoking the
> service in this scenario.
>
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:15 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: Reference not found for component reference:
> CalculatorServiceComponent/addService
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> Aug 8, 2008 5:59:16 PM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
> WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
> WARNING: No targets for reference: setAddService
>
> The conclusion I can draw from this is that retrotranslator is the one
> causing the problem. To further verify this, I narrowed down the
> retrotranslator runs on Android and the normal scenario to only those
> modules that rely on annotations. I experienced the same issue after running
> retrotranslator on this reduced set. Then I thought it would be a good idea
> to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
> experienced the same issues. In summary, even though retrotranslator was
> supposed to be a solution to the lack of Annotations support in Android, it
> is resulting in other problems which I have yet been able to determine.
>
> Overall, unfortunately, this means that Tuscany is still not running on
> Android. Up to this point I have identified an SCA subset to port and
> attempted porting it into Android by using retrotranslator. Additionally,
> with the help of Adriano, we have also cut corners by removing references to
> the Beans API and RMI API, both of which were interfering in previous
> attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
> much as possible to the project proposal, concentrating mainly on the
> porting part. In these last few days before the GSoC 'pencils down date' I
> will concentrate on testing Luciano's suggestion of removing @Remotable
> annotations. I will also update the JIRA ticket I created, with the reduced
> set of modules and the changes to SCA code. And lastly, I will update my
> project wiki to summarize the work performed throughout the project.
>
> Both Adriano and me signed a petition to have Google release an updated
> version of the Android SDK. The general sentiment in the Android Developer
> list is negative with respect to Google's silence on the matter of the
> Android SDK. There has been mention though, of a new SDK release sometime in
> September, when the second round of the Android Developer challenge comes to
> an end. I look forward to testing Tuscany on this new version of the SDK, to
> see if finally I can see it running on Android.
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>
>
> On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> I think the class should be ok, as we just ask the classLoaders to
>> load it inside ClassReferenceModelResolver. Another thing to check is
>> how the CompositeProcessor is viewing the contents of
>> dex://calculator.android/raw/calculator.composite, it should be
>> available as XML, and parsing should be happening as expected in order
>> for the assembly model to be properly populated.
>>
>> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
>> wrote:
>> >
>> >
>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>> > <os...@gmail.com> wrote:
>> >>
>> >> Hi Simon,
>> >>
>> >> Thanks for your explanation. I think it is indeed the case that there
>> is
>> >> no wire to support the connection. I have the impression that the
>> service
>> >> does exist but the runtime thinks it doesn't or something else is going
>> >> wrong.
>> >>
>> >> I looked in more detail to see whether the composite is really being
>> read.
>> >> I found that ContributionServiceImpl.contribute() calls
>> >> ContributionServiceImpl.addContribution(). After debugging I found that
>> >> there is an exception after processReadPhase where the read problems
>> are
>> >> arising. The code excerpt below shows this step:
>> >>
>> >> try {
>> >> // Allow access to read system properties. Requires
>> >> PropertyPermission in security policy.
>> >> // Any security exceptions are caught and wrapped as
>> >> ContributionException.
>> >> processReadPhase(contribution, contributionArtifacts);
>> >> } catch ( Exception e ) {
>> >> throw new ContributionException(e);
>> >> }
>> >>
>> >> contribution is null and contributionArtifacts has the following
>> contents:
>> >>
>> >> [dex://calculator/CalculatorServiceImpl.class,
>> >> dex://calculator/AddServiceImpl.class,
>> >> dex://calculator/SubtractServiceImpl.class,
>> >> dex://calculator/MultiplyServiceImpl.class,
>> >> dex://calculator/DivideServiceImpl.class,
>> >> dex://calculator.android/raw/calculator.composite]
>> >>
>> >> In summary ContributionServiceImpl.contribute() is not returning
>> anything
>> >> but instead resulting in an exception. I will ask Adriano if the dex
>> >> protocol can read .class files, as Android doesn't use .class but .dex
>> >> instead. Maybe, dex protocol should access .dex files.
>> >>
>> >> Let me know if you have any pointers or ideas. I'll keep you posted if
>> I
>> >> find something new.
>> >>
>> >> Thanks for your help.
>> >>
>> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <
>> simonslaws@googlemail.com>
>> >> wrote:
>> >>>
>> >>>
>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>> >>> <ad...@apache.org> wrote:
>> >>>>
>> >>>> Good summary Oscar : )
>> >>>>
>> >>>> I would like to reproduce your workspace and get this exception with
>> >>>> only the modules set your are using. I tried it, but I'm getting some
>> errors
>> >>>> related to missing classes from the modules I removed. Could you make
>> a new
>> >>>> step by step tutorial of how to reproduce a workspace like yours?
>> >>>>
>> >>>> Thanks,
>> >>>> Adriano Crestani
>> >>>>
>> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>> >>>> <os...@gmail.com> wrote:
>> >>>>>
>> >>>>> Hi,
>> >>>>>
>> >>>>> I've been mostly using another thread for issues and questions
>> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
>> made and a
>> >>>>> new thread was needed.
>> >>>>>
>> >>>>> Recently, Adriano reported some errors while testing changes to the
>> >>>>> android sandbox and revision 674723 [1]. There was also a suggestion
>> from
>> >>>>> Luciano to look into calculator2 for coming up with a minimal set of
>> modules
>> >>>>> necessary to run calculator-android. I took the list of modules from
>> the
>> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> >>>>> calculator2, and augmented it based on dependencies from revision
>> 643746,
>> >>>>> which was a previous revision, until the point in which I received
>> the same
>> >>>>> errors [2] that Adriano had reported. These errors result in the
>> >>>>> RuntimeException shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
>> component
>> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>> >>>>> operation=add). Ensure that the composite containing the service is
>> loaded
>> >>>>> and started somewhere in the SCA domain and that if running in a
>> remote node
>> >>>>> that the interface of the target service marked as @Remotable
>> >>>>>
>> >>>>> Seeing this error the first question that came to mind was: how do I
>> >>>>> verify whether the composite containing the service is being loaded?
>> and,
>> >>>>> does it actually exist? I was thinking that maybe the composite was
>> not
>> >>>>> being created and thus was resulting in the errors in [3]. To test
>> this I
>> >>>>> changed the first line of "calculator_composite" to read as follows:
>> >>>>>
>> >>>>> <composite name="Calculator" autowire="true">
>> >>>>>
>> >>>>> Setting the autowire attribute to true would make the runtime
>> >>>>> automatically connect services and references in the composite,
>> granted
>> >>>>> there actually was one. This resulted in the error shown in [4] and
>> included
>> >>>>> in more detail in [5]. The fact that the runtime wires are being
>> created
>> >>>>> makes me think that a composite does exist, as documented in [6].
>> However,
>> >>>>> the error messages confuse me and make me think otherwise,
>> especially the
>> >>>>> one shown below:
>> >>>>>
>> >>>>> java.lang.RuntimeException: Unable to start activity
>> >>>>>
>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>> >>>>> org.osoa.sca.ServiceRuntimeException:
>> org.osoa.sca.ServiceRuntimeException:
>> >>>>> Composite not found:
>> dex://calculator.android/raw/calculator.composite
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
>> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
>> previous
>> >>>>> thread, we have a feeling we're getting closer to successfully
>> embedding
>> >>>>> Tuscany/SCA in Android.
>> >>>>>
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> >>>>> [3]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> >>>>> [5]
>> >>>>>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> >>>>> [6]
>> >>>>>
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>> >>>>>
>> >>>>> --
>> >>>>> best,
>> >>>>> -oscar
>> >>>>>
>> >>>>> Oscar Castañeda
>> >>>
>> >>> Hi Oscar
>> >>>
>> >>> The ServiceUnavailableException you are seeing comes from the SCA
>> binding
>> >>> when it tries to create an invoker but it finds there is no wire to
>> support
>> >>> the connection. This can be the case if your reference targets a
>> service
>> >>> that doesn't exist or at least which the runtime doesn't think exists.
>> As an
>> >>> aside I guess you are working on oldish code in the sandbox as this
>> error
>> >>> message has changed now.
>> >>>
>> >>> First you need to look in some detail at whether the composite is
>> really
>> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
>> >>> returning anything?
>> >>>
>> >>> Simon
>> >>
>> >>
>> >>
>> >> --
>> >> best,
>> >> -oscar
>> >>
>> >> Oscar Castañeda
>> >
>> > Hi Oscar
>> >
>> > They look like the sort of artifacts that I would expect in a calculator
>> > sample contribution but you may be right that these would need
>> converting to
>> > dex files before they would run. Do you know what the exception is that
>> you
>> > are getting?
>> >
>> > Simon
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
>> http://lresende.blogspot.com/
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Thanks Luciano and Simon for your help in this thread. These past couple of
weeks I've been ardently debugging in the hopes of getting to the root of
the problem. While I have gained some insights, the issue is far from
resolved as problems still remain. I'm now a bit reluctant about whether use
of retrotranslator is a viable solution for this project. I'll explain below
along with a summary of the most important findings.
Recently, Adriano reported some errors while testing changes to the android
sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
look into calculator2 for coming up with a minimal set of modules necessary
to run calculator-android. I took the list of modules from the
tuscany-runtime2 and tuscany-api JARs of the SCA revision that includes
calculator2, and augmented it based on dependencies from revision 643746
until the point in which I received the same errors [2] that Adriano had
reported.
These errors included a ServiceUnavailableException that, as Simon
explained, comes from the SCA binding when it tries to create an invoker but
it finds there is no wire to support the connection. I thought this might be
because of Android's use of the dex protocol but as Luciano explained, it
shouldn't be a problem as classLoaders were only loading stuff into
ClassReferenceModelResolver. Furthermore, Luciano suggested to check whether
the CompositeProcessor is able to view the contents of the calculator
composite.
Further debugging showed that the calculator.composite is indeed being read
appropriately, eliminating the possibility of a parsing related issue. I
verified this by seeing the composite being correctly populated while
debugging. To accomplish this I compared the reduced Android SCA to revision
643746 without the Android sandbox code and with the normal calculator
sample. This was suggested by Adriano as a way to approach testing and
debugging for Android.
To further simplify the debugging runs I narrowed down the calculator
operations to only the "add" operation. I set a breakpoint in
RuntimeSCAReferenceBindingProvider on the getInvoker() method, which is
where the error is ocurring. I found that the problem is that the service,
as shown below, is being assigned a value of null.
RuntimeComponentService service =
(RuntimeComponentService)target.getContract();
In order to proceed, service must have a value other than null. Instead,
getInvoker() method returns a null invoker, which results in the
ServiceUnavailableException shown below:
if (invoker == null) {
throw new ServiceUnavailableException("Service not found for
component " + component.getName()
+ " reference "
+ reference.getName()
+ " (bindingURI="
+ binding.getURI()
+ " operation="
+ operation.getName()
+ "). Ensure that the composite containing the service
is loaded and "
+ "started somewhere in the SCA domain and that if
running in a "
+ "remote node that the interface of the target service
marked as @Remotable");
}
Continuing the approach of testing against a baseline scenario, I decided to
run retrotranslator on SCA revision 643746. First, I verified that the
revision works as expected. In other words, I downloaded and bulit the
revision and ran the non-Android calculator sample. Then, I ran
retrotranslator with the same options as those for the Android scenario. The
result, I found, was pretty similar to the Android scenario:
Aug 10, 2008 10:55:02 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Reference not found for component reference:
CalculatorServiceComponent/addService
Aug 10, 2008 10:55:02 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Reference not found for component reference:
CalculatorServiceComponent/subtractService
Aug 10, 2008 10:55:02 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Reference not found for component reference:
CalculatorServiceComponent/multiplyService
Aug 10, 2008 10:55:02 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARNING: Reference not found for component reference:
CalculatorServiceComponent/divideService
Exception in thread "main" java.lang.NullPointerException
at calculator.CalculatorServiceImpl.add(CalculatorServiceImpl.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy0.add(Unknown Source)
at calculator.CalculatorClient.main(CalculatorClient.java:37)
The warning messages are something that is also found on the Android runs,
as shown below. And the NullPointerException confirmed that there is indeed
no wire to support the connection, as there are also problems invoking the
service in this scenario.
WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
Aug 8, 2008 5:59:15 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
WARNING: Reference not found for component reference:
CalculatorServiceComponent/addService
WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
Aug 8, 2008 5:59:16 PM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1 problem
WARN/org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl(1957):
WARNING: No targets for reference: setAddService
The conclusion I can draw from this is that retrotranslator is the one
causing the problem. To further verify this, I narrowed down the
retrotranslator runs on Android and the normal scenario to only those
modules that rely on annotations. I experienced the same issue after running
retrotranslator on this reduced set. Then I thought it would be a good idea
to try retrotranslating to target java 1.4 instead of to 1.5. Still, I
experienced the same issues. In summary, even though retrotranslator was
supposed to be a solution to the lack of Annotations support in Android, it
is resulting in other problems which I have yet been able to determine.
Overall, unfortunately, this means that Tuscany is still not running on
Android. Up to this point I have identified an SCA subset to port and
attempted porting it into Android by using retrotranslator. Additionally,
with the help of Adriano, we have also cut corners by removing references to
the Beans API and RMI API, both of which were interfering in previous
attempts at embedding Tuscany/SCA in Google Android. I've tried to stick as
much as possible to the project proposal, concentrating mainly on the
porting part. In these last few days before the GSoC 'pencils down date' I
will concentrate on testing Luciano's suggestion of removing @Remotable
annotations. I will also update the JIRA ticket I created, with the reduced
set of modules and the changes to SCA code. And lastly, I will update my
project wiki to summarize the work performed throughout the project.
Both Adriano and me signed a petition to have Google release an updated
version of the Android SDK. The general sentiment in the Android Developer
list is negative with respect to Google's silence on the matter of the
Android SDK. There has been mention though, of a new SDK release sometime in
September, when the second round of the Android Developer challenge comes to
an end. I look forward to testing Tuscany on this new version of the SDK, to
see if finally I can see it running on Android.
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
[2] http://androidindelft.googlepages.com/21Jul2.jpg
On Fri, Jul 25, 2008 at 7:52 PM, Luciano Resende <lu...@gmail.com>wrote:
> I think the class should be ok, as we just ask the classLoaders to
> load it inside ClassReferenceModelResolver. Another thing to check is
> how the CompositeProcessor is viewing the contents of
> dex://calculator.android/raw/calculator.composite, it should be
> available as XML, and parsing should be happening as expected in order
> for the assembly model to be properly populated.
>
> On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com>
> wrote:
> >
> >
> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
> > <os...@gmail.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> Thanks for your explanation. I think it is indeed the case that there is
> >> no wire to support the connection. I have the impression that the
> service
> >> does exist but the runtime thinks it doesn't or something else is going
> >> wrong.
> >>
> >> I looked in more detail to see whether the composite is really being
> read.
> >> I found that ContributionServiceImpl.contribute() calls
> >> ContributionServiceImpl.addContribution(). After debugging I found that
> >> there is an exception after processReadPhase where the read problems are
> >> arising. The code excerpt below shows this step:
> >>
> >> try {
> >> // Allow access to read system properties. Requires
> >> PropertyPermission in security policy.
> >> // Any security exceptions are caught and wrapped as
> >> ContributionException.
> >> processReadPhase(contribution, contributionArtifacts);
> >> } catch ( Exception e ) {
> >> throw new ContributionException(e);
> >> }
> >>
> >> contribution is null and contributionArtifacts has the following
> contents:
> >>
> >> [dex://calculator/CalculatorServiceImpl.class,
> >> dex://calculator/AddServiceImpl.class,
> >> dex://calculator/SubtractServiceImpl.class,
> >> dex://calculator/MultiplyServiceImpl.class,
> >> dex://calculator/DivideServiceImpl.class,
> >> dex://calculator.android/raw/calculator.composite]
> >>
> >> In summary ContributionServiceImpl.contribute() is not returning
> anything
> >> but instead resulting in an exception. I will ask Adriano if the dex
> >> protocol can read .class files, as Android doesn't use .class but .dex
> >> instead. Maybe, dex protocol should access .dex files.
> >>
> >> Let me know if you have any pointers or ideas. I'll keep you posted if I
> >> find something new.
> >>
> >> Thanks for your help.
> >>
> >> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <simonslaws@googlemail.com
> >
> >> wrote:
> >>>
> >>>
> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
> >>> <ad...@apache.org> wrote:
> >>>>
> >>>> Good summary Oscar : )
> >>>>
> >>>> I would like to reproduce your workspace and get this exception with
> >>>> only the modules set your are using. I tried it, but I'm getting some
> errors
> >>>> related to missing classes from the modules I removed. Could you make
> a new
> >>>> step by step tutorial of how to reproduce a workspace like yours?
> >>>>
> >>>> Thanks,
> >>>> Adriano Crestani
> >>>>
> >>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
> >>>> <os...@gmail.com> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I've been mostly using another thread for issues and questions
> >>>>> concerning running Tuscany/SCA on Android. Some progress has been
> made and a
> >>>>> new thread was needed.
> >>>>>
> >>>>> Recently, Adriano reported some errors while testing changes to the
> >>>>> android sandbox and revision 674723 [1]. There was also a suggestion
> from
> >>>>> Luciano to look into calculator2 for coming up with a minimal set of
> modules
> >>>>> necessary to run calculator-android. I took the list of modules from
> the
> >>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
> >>>>> calculator2, and augmented it based on dependencies from revision
> 643746,
> >>>>> which was a previous revision, until the point in which I received
> the same
> >>>>> errors [2] that Adriano had reported. These errors result in the
> >>>>> RuntimeException shown below:
> >>>>>
> >>>>> java.lang.RuntimeException: Unable to start activity
> >>>>>
> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
> >>>>> org.osoa.sca.ServiceUnavailableException: Service not found for
> component
> >>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
> >>>>> operation=add). Ensure that the composite containing the service is
> loaded
> >>>>> and started somewhere in the SCA domain and that if running in a
> remote node
> >>>>> that the interface of the target service marked as @Remotable
> >>>>>
> >>>>> Seeing this error the first question that came to mind was: how do I
> >>>>> verify whether the composite containing the service is being loaded?
> and,
> >>>>> does it actually exist? I was thinking that maybe the composite was
> not
> >>>>> being created and thus was resulting in the errors in [3]. To test
> this I
> >>>>> changed the first line of "calculator_composite" to read as follows:
> >>>>>
> >>>>> <composite name="Calculator" autowire="true">
> >>>>>
> >>>>> Setting the autowire attribute to true would make the runtime
> >>>>> automatically connect services and references in the composite,
> granted
> >>>>> there actually was one. This resulted in the error shown in [4] and
> included
> >>>>> in more detail in [5]. The fact that the runtime wires are being
> created
> >>>>> makes me think that a composite does exist, as documented in [6].
> However,
> >>>>> the error messages confuse me and make me think otherwise, especially
> the
> >>>>> one shown below:
> >>>>>
> >>>>> java.lang.RuntimeException: Unable to start activity
> >>>>>
> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
> >>>>> org.osoa.sca.ServiceRuntimeException:
> org.osoa.sca.ServiceRuntimeException:
> >>>>> Composite not found:
> dex://calculator.android/raw/calculator.composite
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> Any suggestions or ideas from the Tuscany community to resolve this
> >>>>> problem will be greatly appreciated. As Adriano mentioned in the
> previous
> >>>>> thread, we have a feeling we're getting closer to successfully
> embedding
> >>>>> Tuscany/SCA in Android.
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> >>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
> >>>>> [3]
> >>>>>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
> >>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
> >>>>> [5]
> >>>>>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
> >>>>> [6]
> >>>>>
> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
> >>>>>
> >>>>> --
> >>>>> best,
> >>>>> -oscar
> >>>>>
> >>>>> Oscar Castañeda
> >>>
> >>> Hi Oscar
> >>>
> >>> The ServiceUnavailableException you are seeing comes from the SCA
> binding
> >>> when it tries to create an invoker but it finds there is no wire to
> support
> >>> the connection. This can be the case if your reference targets a
> service
> >>> that doesn't exist or at least which the runtime doesn't think exists.
> As an
> >>> aside I guess you are working on oldish code in the sandbox as this
> error
> >>> message has changed now.
> >>>
> >>> First you need to look in some detail at whether the composite is
> really
> >>> being read. Can you tell if ContributionServiceImpl.contribute() is
> >>> returning anything?
> >>>
> >>> Simon
> >>
> >>
> >>
> >> --
> >> best,
> >> -oscar
> >>
> >> Oscar Castañeda
> >
> > Hi Oscar
> >
> > They look like the sort of artifacts that I would expect in a calculator
> > sample contribution but you may be right that these would need converting
> to
> > dex files before they would run. Do you know what the exception is that
> you
> > are getting?
> >
> > Simon
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Luciano Resende <lu...@gmail.com>.
I think the class should be ok, as we just ask the classLoaders to
load it inside ClassReferenceModelResolver. Another thing to check is
how the CompositeProcessor is viewing the contents of
dex://calculator.android/raw/calculator.composite, it should be
available as XML, and parsing should be happening as expected in order
for the assembly model to be properly populated.
On Fri, Jul 25, 2008 at 10:02 AM, Simon Laws <si...@googlemail.com> wrote:
>
>
> On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
> <os...@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> Thanks for your explanation. I think it is indeed the case that there is
>> no wire to support the connection. I have the impression that the service
>> does exist but the runtime thinks it doesn't or something else is going
>> wrong.
>>
>> I looked in more detail to see whether the composite is really being read.
>> I found that ContributionServiceImpl.contribute() calls
>> ContributionServiceImpl.addContribution(). After debugging I found that
>> there is an exception after processReadPhase where the read problems are
>> arising. The code excerpt below shows this step:
>>
>> try {
>> // Allow access to read system properties. Requires
>> PropertyPermission in security policy.
>> // Any security exceptions are caught and wrapped as
>> ContributionException.
>> processReadPhase(contribution, contributionArtifacts);
>> } catch ( Exception e ) {
>> throw new ContributionException(e);
>> }
>>
>> contribution is null and contributionArtifacts has the following contents:
>>
>> [dex://calculator/CalculatorServiceImpl.class,
>> dex://calculator/AddServiceImpl.class,
>> dex://calculator/SubtractServiceImpl.class,
>> dex://calculator/MultiplyServiceImpl.class,
>> dex://calculator/DivideServiceImpl.class,
>> dex://calculator.android/raw/calculator.composite]
>>
>> In summary ContributionServiceImpl.contribute() is not returning anything
>> but instead resulting in an exception. I will ask Adriano if the dex
>> protocol can read .class files, as Android doesn't use .class but .dex
>> instead. Maybe, dex protocol should access .dex files.
>>
>> Let me know if you have any pointers or ideas. I'll keep you posted if I
>> find something new.
>>
>> Thanks for your help.
>>
>> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>>
>>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>>> <ad...@apache.org> wrote:
>>>>
>>>> Good summary Oscar : )
>>>>
>>>> I would like to reproduce your workspace and get this exception with
>>>> only the modules set your are using. I tried it, but I'm getting some errors
>>>> related to missing classes from the modules I removed. Could you make a new
>>>> step by step tutorial of how to reproduce a workspace like yours?
>>>>
>>>> Thanks,
>>>> Adriano Crestani
>>>>
>>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda
>>>> <os...@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I've been mostly using another thread for issues and questions
>>>>> concerning running Tuscany/SCA on Android. Some progress has been made and a
>>>>> new thread was needed.
>>>>>
>>>>> Recently, Adriano reported some errors while testing changes to the
>>>>> android sandbox and revision 674723 [1]. There was also a suggestion from
>>>>> Luciano to look into calculator2 for coming up with a minimal set of modules
>>>>> necessary to run calculator-android. I took the list of modules from the
>>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>>>>> calculator2, and augmented it based on dependencies from revision 643746,
>>>>> which was a previous revision, until the point in which I received the same
>>>>> errors [2] that Adriano had reported. These errors result in the
>>>>> RuntimeException shown below:
>>>>>
>>>>> java.lang.RuntimeException: Unable to start activity
>>>>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>>>>> org.osoa.sca.ServiceUnavailableException: Service not found for component
>>>>> CalculatorServiceComponent reference setAddService (bindingURI=null
>>>>> operation=add). Ensure that the composite containing the service is loaded
>>>>> and started somewhere in the SCA domain and that if running in a remote node
>>>>> that the interface of the target service marked as @Remotable
>>>>>
>>>>> Seeing this error the first question that came to mind was: how do I
>>>>> verify whether the composite containing the service is being loaded? and,
>>>>> does it actually exist? I was thinking that maybe the composite was not
>>>>> being created and thus was resulting in the errors in [3]. To test this I
>>>>> changed the first line of "calculator_composite" to read as follows:
>>>>>
>>>>> <composite name="Calculator" autowire="true">
>>>>>
>>>>> Setting the autowire attribute to true would make the runtime
>>>>> automatically connect services and references in the composite, granted
>>>>> there actually was one. This resulted in the error shown in [4] and included
>>>>> in more detail in [5]. The fact that the runtime wires are being created
>>>>> makes me think that a composite does exist, as documented in [6]. However,
>>>>> the error messages confuse me and make me think otherwise, especially the
>>>>> one shown below:
>>>>>
>>>>> java.lang.RuntimeException: Unable to start activity
>>>>> ComponentInfo{calculator.android/calculator.android.CalculatorClient}:
>>>>> org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
>>>>> Composite not found: dex://calculator.android/raw/calculator.composite
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Any suggestions or ideas from the Tuscany community to resolve this
>>>>> problem will be greatly appreciated. As Adriano mentioned in the previous
>>>>> thread, we have a feeling we're getting closer to successfully embedding
>>>>> Tuscany/SCA in Android.
>>>>>
>>>>>
>>>>> [1]
>>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>>>>> [3]
>>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>>>>> [5]
>>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>>>>> [6]
>>>>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>>>>
>>>>> --
>>>>> best,
>>>>> -oscar
>>>>>
>>>>> Oscar Castañeda
>>>
>>> Hi Oscar
>>>
>>> The ServiceUnavailableException you are seeing comes from the SCA binding
>>> when it tries to create an invoker but it finds there is no wire to support
>>> the connection. This can be the case if your reference targets a service
>>> that doesn't exist or at least which the runtime doesn't think exists. As an
>>> aside I guess you are working on oldish code in the sandbox as this error
>>> message has changed now.
>>>
>>> First you need to look in some detail at whether the composite is really
>>> being read. Can you tell if ContributionServiceImpl.contribute() is
>>> returning anything?
>>>
>>> Simon
>>
>>
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>
> Hi Oscar
>
> They look like the sort of artifacts that I would expect in a calculator
> sample contribution but you may be right that these would need converting to
> dex files before they would run. Do you know what the exception is that you
> are getting?
>
> Simon
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: Embedding Tuscany/SCA in Google Android
Posted by Simon Laws <si...@googlemail.com>.
On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Hi Simon,
>
> Thanks for your explanation. I think it is indeed the case that there is no
> wire to support the connection. I have the impression that the service does
> exist but the runtime thinks it doesn't or something else is going wrong.
>
> I looked in more detail to see whether the composite is really being read.
> I found that ContributionServiceImpl.contribute() calls
> ContributionServiceImpl.addContribution(). After debugging I found that
> there is an exception after processReadPhase where the read problems are
> arising. The code excerpt below shows this step:
>
> try {
> // Allow access to read system properties. Requires
> PropertyPermission in security policy.
> // Any security exceptions are caught and wrapped as
> ContributionException.
> processReadPhase(contribution, contributionArtifacts);
> } catch ( Exception e ) {
> throw new ContributionException(e);
> }
>
> contribution is null and contributionArtifacts has the following contents:
>
> [dex://calculator/CalculatorServiceImpl.class,
> dex://calculator/AddServiceImpl.class,
> dex://calculator/SubtractServiceImpl.class,
> dex://calculator/MultiplyServiceImpl.class,
> dex://calculator/DivideServiceImpl.class,
> dex://calculator.android/raw/calculator.composite]
>
> In summary ContributionServiceImpl.contribute() is not returning anything
> but instead resulting in an exception. I will ask Adriano if the dex
> protocol can read .class files, as Android doesn't use .class but .dex
> instead. Maybe, dex protocol should access .dex files.
>
> Let me know if you have any pointers or ideas. I'll keep you posted if I
> find something new.
>
> Thanks for your help.
>
>
> On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
>>
>>
>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani <
>> adrianocrestani@apache.org> wrote:
>>
>>> Good summary Oscar : )
>>>
>>> I would like to reproduce your workspace and get this exception with only
>>> the modules set your are using. I tried it, but I'm getting some errors
>>> related to missing classes from the modules I removed. Could you make a new
>>> step by step tutorial of how to reproduce a workspace like yours?
>>>
>>> Thanks,
>>> Adriano Crestani
>>>
>>>
>>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda <
>>> oscar.castaneda.gsoc@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've been mostly using another thread for issues and questions
>>>> concerning running Tuscany/SCA on Android. Some progress has been made and a
>>>> new thread was needed.
>>>>
>>>> Recently, Adriano reported some errors while testing changes to the
>>>> android sandbox and revision 674723 [1]. There was also a suggestion from
>>>> Luciano to look into calculator2 for coming up with a minimal set of modules
>>>> necessary to run calculator-android. I took the list of modules from the
>>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>>>> calculator2, and augmented it based on dependencies from revision 643746,
>>>> which was a previous revision, until the point in which I received the same
>>>> errors [2] that Adriano had reported. These errors result in the
>>>> RuntimeException shown below:
>>>>
>>>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceUnavailableException: Service not found for component CalculatorServiceComponent reference setAddService (bindingURI=null operation=add). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable
>>>>
>>>>
>>>> Seeing this error the first question that came to mind was: how do I
>>>> verify whether the composite containing the service is being loaded? and,
>>>> does it actually exist? I was thinking that maybe the composite was not
>>>> being created and thus was resulting in the errors in [3]. To test this I
>>>> changed the first line of "calculator_composite" to read as follows:
>>>>
>>>> <composite name="Calculator" autowire="true">
>>>>
>>>> Setting the autowire attribute to true would make the runtime
>>>> automatically connect services and references in the composite, granted
>>>> there actually was one. This resulted in the error shown in [4] and included
>>>> in more detail in [5]. The fact that the runtime wires are being created
>>>> makes me think that a composite does exist, as documented in [6]. However,
>>>> the error messages confuse me and make me think otherwise, especially the
>>>> one shown below:
>>>>
>>>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: Composite not found: dex://calculator.android/raw/calculator.composite
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Any suggestions or ideas from the Tuscany community to resolve this
>>>> problem will be greatly appreciated. As Adriano mentioned in the previous
>>>> thread, we have a feeling we're getting closer to successfully embedding
>>>> Tuscany/SCA in Android.
>>>>
>>>>
>>>> [1]
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>>>> [3]
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>>>> [5]
>>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>>>> [6]
>>>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>>>
>>>> --
>>>> best,
>>>> -oscar
>>>>
>>>> Oscar Castañeda
>>>>
>>>
>>>
>> Hi Oscar
>>
>> The ServiceUnavailableException you are seeing comes from the SCA binding
>> when it tries to create an invoker but it finds there is no wire to support
>> the connection. This can be the case if your reference targets a service
>> that doesn't exist or at least which the runtime doesn't think exists. As an
>> aside I guess you are working on oldish code in the sandbox as this error
>> message has changed now.
>>
>> First you need to look in some detail at whether the composite is really
>> being read. Can you tell if ContributionServiceImpl.contribute() is
>> returning anything?
>>
>> Simon
>>
>
>
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>
Hi Oscar
They look like the sort of artifacts that I would expect in a calculator
sample contribution but you may be right that these would need converting to
dex files before they would run. Do you know what the exception is that you
are getting?
Simon
Re: Embedding Tuscany/SCA in Google Android
Posted by Oscar Castaneda <os...@gmail.com>.
Hi Simon,
Thanks for your explanation. I think it is indeed the case that there is no
wire to support the connection. I have the impression that the service does
exist but the runtime thinks it doesn't or something else is going wrong.
I looked in more detail to see whether the composite is really being read. I
found that ContributionServiceImpl.contribute() calls
ContributionServiceImpl.addContribution(). After debugging I found that
there is an exception after processReadPhase where the read problems are
arising. The code excerpt below shows this step:
try {
// Allow access to read system properties. Requires
PropertyPermission in security policy.
// Any security exceptions are caught and wrapped as
ContributionException.
processReadPhase(contribution, contributionArtifacts);
} catch ( Exception e ) {
throw new ContributionException(e);
}
contribution is null and contributionArtifacts has the following contents:
[dex://calculator/CalculatorServiceImpl.class,
dex://calculator/AddServiceImpl.class,
dex://calculator/SubtractServiceImpl.class,
dex://calculator/MultiplyServiceImpl.class,
dex://calculator/DivideServiceImpl.class,
dex://calculator.android/raw/calculator.composite]
In summary ContributionServiceImpl.contribute() is not returning anything
but instead resulting in an exception. I will ask Adriano if the dex
protocol can read .class files, as Android doesn't use .class but .dex
instead. Maybe, dex protocol should access .dex files.
Let me know if you have any pointers or ideas. I'll keep you posted if I
find something new.
Thanks for your help.
On Wed, Jul 23, 2008 at 12:00 PM, Simon Laws <si...@googlemail.com>
wrote:
>
>
> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani <
> adrianocrestani@apache.org> wrote:
>
>> Good summary Oscar : )
>>
>> I would like to reproduce your workspace and get this exception with only
>> the modules set your are using. I tried it, but I'm getting some errors
>> related to missing classes from the modules I removed. Could you make a new
>> step by step tutorial of how to reproduce a workspace like yours?
>>
>> Thanks,
>> Adriano Crestani
>>
>>
>> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda <
>> oscar.castaneda.gsoc@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I've been mostly using another thread for issues and questions concerning
>>> running Tuscany/SCA on Android. Some progress has been made and a new thread
>>> was needed.
>>>
>>> Recently, Adriano reported some errors while testing changes to the
>>> android sandbox and revision 674723 [1]. There was also a suggestion from
>>> Luciano to look into calculator2 for coming up with a minimal set of modules
>>> necessary to run calculator-android. I took the list of modules from the
>>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>>> calculator2, and augmented it based on dependencies from revision 643746,
>>> which was a previous revision, until the point in which I received the same
>>> errors [2] that Adriano had reported. These errors result in the
>>> RuntimeException shown below:
>>>
>>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceUnavailableException: Service not found for component CalculatorServiceComponent reference setAddService (bindingURI=null operation=add). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable
>>>
>>>
>>> Seeing this error the first question that came to mind was: how do I
>>> verify whether the composite containing the service is being loaded? and,
>>> does it actually exist? I was thinking that maybe the composite was not
>>> being created and thus was resulting in the errors in [3]. To test this I
>>> changed the first line of "calculator_composite" to read as follows:
>>>
>>> <composite name="Calculator" autowire="true">
>>>
>>> Setting the autowire attribute to true would make the runtime
>>> automatically connect services and references in the composite, granted
>>> there actually was one. This resulted in the error shown in [4] and included
>>> in more detail in [5]. The fact that the runtime wires are being created
>>> makes me think that a composite does exist, as documented in [6]. However,
>>> the error messages confuse me and make me think otherwise, especially the
>>> one shown below:
>>>
>>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: Composite not found: dex://calculator.android/raw/calculator.composite
>>>
>>>
>>>
>>>
>>>
>>> Any suggestions or ideas from the Tuscany community to resolve this
>>> problem will be greatly appreciated. As Adriano mentioned in the previous
>>> thread, we have a feeling we're getting closer to successfully embedding
>>> Tuscany/SCA in Android.
>>>
>>>
>>> [1]
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>>> [3]
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>>> [5]
>>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>>> [6]
>>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>>
>>> --
>>> best,
>>> -oscar
>>>
>>> Oscar Castañeda
>>>
>>
>>
> Hi Oscar
>
> The ServiceUnavailableException you are seeing comes from the SCA binding
> when it tries to create an invoker but it finds there is no wire to support
> the connection. This can be the case if your reference targets a service
> that doesn't exist or at least which the runtime doesn't think exists. As an
> aside I guess you are working on oldish code in the sandbox as this error
> message has changed now.
>
> First you need to look in some detail at whether the composite is really
> being read. Can you tell if ContributionServiceImpl.contribute() is
> returning anything?
>
> Simon
>
--
best,
-oscar
Oscar Castañeda
Re: Embedding Tuscany/SCA in Google Android
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani <
adrianocrestani@apache.org> wrote:
> Good summary Oscar : )
>
> I would like to reproduce your workspace and get this exception with only
> the modules set your are using. I tried it, but I'm getting some errors
> related to missing classes from the modules I removed. Could you make a new
> step by step tutorial of how to reproduce a workspace like yours?
>
> Thanks,
> Adriano Crestani
>
>
> On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda <
> oscar.castaneda.gsoc@gmail.com> wrote:
>
>> Hi,
>>
>> I've been mostly using another thread for issues and questions concerning
>> running Tuscany/SCA on Android. Some progress has been made and a new thread
>> was needed.
>>
>> Recently, Adriano reported some errors while testing changes to the
>> android sandbox and revision 674723 [1]. There was also a suggestion from
>> Luciano to look into calculator2 for coming up with a minimal set of modules
>> necessary to run calculator-android. I took the list of modules from the
>> tuscany-runtime2 and tuscany-api JARs of the revision that included
>> calculator2, and augmented it based on dependencies from revision 643746,
>> which was a previous revision, until the point in which I received the same
>> errors [2] that Adriano had reported. These errors result in the
>> RuntimeException shown below:
>>
>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceUnavailableException: Service not found for component CalculatorServiceComponent reference setAddService (bindingURI=null operation=add). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable
>>
>>
>> Seeing this error the first question that came to mind was: how do I
>> verify whether the composite containing the service is being loaded? and,
>> does it actually exist? I was thinking that maybe the composite was not
>> being created and thus was resulting in the errors in [3]. To test this I
>> changed the first line of "calculator_composite" to read as follows:
>>
>> <composite name="Calculator" autowire="true">
>>
>> Setting the autowire attribute to true would make the runtime
>> automatically connect services and references in the composite, granted
>> there actually was one. This resulted in the error shown in [4] and included
>> in more detail in [5]. The fact that the runtime wires are being created
>> makes me think that a composite does exist, as documented in [6]. However,
>> the error messages confuse me and make me think otherwise, especially the
>> one shown below:
>>
>> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: Composite not found: dex://calculator.android/raw/calculator.composite
>>
>>
>>
>>
>> Any suggestions or ideas from the Tuscany community to resolve this
>> problem will be greatly appreciated. As Adriano mentioned in the previous
>> thread, we have a feeling we're getting closer to successfully embedding
>> Tuscany/SCA in Android.
>>
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
>> [2] http://androidindelft.googlepages.com/21Jul2.jpg
>> [3]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
>> [4] http://androidindelft.googlepages.com/22Jul1.jpg
>> [5]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
>> [6]
>> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>>
>> --
>> best,
>> -oscar
>>
>> Oscar Castañeda
>>
>
>
Hi Oscar
The ServiceUnavailableException you are seeing comes from the SCA binding
when it tries to create an invoker but it finds there is no wire to support
the connection. This can be the case if your reference targets a service
that doesn't exist or at least which the runtime doesn't think exists. As an
aside I guess you are working on oldish code in the sandbox as this error
message has changed now.
First you need to look in some detail at whether the composite is really
being read. Can you tell if ContributionServiceImpl.contribute() is
returning anything?
Simon
Re: Embedding Tuscany/SCA in Google Android
Posted by Adriano Crestani <ad...@apache.org>.
Good summary Oscar : )
I would like to reproduce your workspace and get this exception with only
the modules set your are using. I tried it, but I'm getting some errors
related to missing classes from the modules I removed. Could you make a new
step by step tutorial of how to reproduce a workspace like yours?
Thanks,
Adriano Crestani
On Tue, Jul 22, 2008 at 4:58 PM, Oscar Castaneda <
oscar.castaneda.gsoc@gmail.com> wrote:
> Hi,
>
> I've been mostly using another thread for issues and questions concerning
> running Tuscany/SCA on Android. Some progress has been made and a new thread
> was needed.
>
> Recently, Adriano reported some errors while testing changes to the android
> sandbox and revision 674723 [1]. There was also a suggestion from Luciano to
> look into calculator2 for coming up with a minimal set of modules necessary
> to run calculator-android. I took the list of modules from the
> tuscany-runtime2 and tuscany-api JARs of the revision that included
> calculator2, and augmented it based on dependencies from revision 643746,
> which was a previous revision, until the point in which I received the same
> errors [2] that Adriano had reported. These errors result in the
> RuntimeException shown below:
>
> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceUnavailableException: Service not found for component CalculatorServiceComponent reference setAddService (bindingURI=null operation=add). Ensure that the composite containing the service is loaded and started somewhere in the SCA domain and that if running in a remote node that the interface of the target service marked as @Remotable
>
>
> Seeing this error the first question that came to mind was: how do I verify
> whether the composite containing the service is being loaded? and, does it
> actually exist? I was thinking that maybe the composite was not being
> created and thus was resulting in the errors in [3]. To test this I changed
> the first line of "calculator_composite" to read as follows:
>
> <composite name="Calculator" autowire="true">
>
> Setting the autowire attribute to true would make the runtime automatically
> connect services and references in the composite, granted there actually was
> one. This resulted in the error shown in [4] and included in more detail in
> [5]. The fact that the runtime wires are being created makes me think that a
> composite does exist, as documented in [6]. However, the error messages
> confuse me and make me think otherwise, especially the one shown below:
>
> java.lang.RuntimeException: Unable to start activity ComponentInfo{calculator.android/calculator.android.CalculatorClient}: org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: Composite not found: dex://calculator.android/raw/calculator.composite
>
>
>
>
> Any suggestions or ideas from the Tuscany community to resolve this problem
> will be greatly appreciated. As Adriano mentioned in the previous thread, we
> have a feeling we're getting closer to successfully embedding Tuscany/SCA in
> Android.
>
>
> [1]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Android+Exception+after+revision+674723
> [2] http://androidindelft.googlepages.com/21Jul2.jpg
> [3]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/21Jul2008-2+-+Error+Stack+trace
> [4] http://androidindelft.googlepages.com/22Jul1.jpg
> [5]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/22Jul2008+-+Error+Stack+trace
> [6]
> http://tuscany.apache.org/sca-java-architecture-guide.html#SCAJavaArchitectureGuide-CompositeActivation
>
> --
> best,
> -oscar
>
> Oscar Castañeda
>