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
