On Mon, Aug 11, 2008 at 10:39 PM, Adriano Crestani <
[EMAIL PROTECTED]> 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 <
> [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]>
>>> wrote:
>>> >
>>> >
>>> > On Fri, Jul 25, 2008 at 2:05 PM, Oscar Castaneda
>>> > <[EMAIL PROTECTED]> 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 <
>>> [EMAIL PROTECTED]>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On Wed, Jul 23, 2008 at 8:32 AM, Adriano Crestani
>>> >>> <[EMAIL PROTECTED]> 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
>>> >>>> <[EMAIL PROTECTED]> 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
