sca/tools/eclipse/plugins/core/.classpath file in svn

[Vamsavardhana Reddy]

Hi,

There is a .classpath file in svn at [1].  I guess it made into svn by
accident.  Can someone remove this file?  Each time I try to create a patch,
this file shows up in the diffs and I have to manual remove it from the
patch files :(.

++Vamsi

[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/core/.classpath

Re: Databinding integration tests

[Vamsavardhana Reddy]

On Thu, Jun 5, 2008 at 3:00 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> The wiki page is very nice. Thanks.
>
> A quick update, the byte[] support is now in place and the test case is
> passing in SVN.


The jaxws-maven-plugin is generating the following types for byte[] :

  

  

  
  

  

  

Whereas ?wsdl is generating the type:

  
  

  

  

++Vamsi



>
>
> Thanks,
> Raymond
>
> --
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 11:09 AM
> To: 
> Subject: Databinding integration tests
>
>
>  Hi,
>>
>> I have been developing some databinding integration tests recently.  The
>> scope and status of this exercise is maintained in Tuscany wiki at [1].
>> The
>> tests developed so far are under sca\itest\databinding\jaxb-bottom-up [2].
>> Please provide comments, suggestions on the scope, anything missing, any
>> improvements to the code already in svn, etc. so that we have a good test
>> coverage.
>>
>> Thanks,
>> Vamsi
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope
>> [2]
>>
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up
>>
>>

Re: Databinding integration tests

[Vamsavardhana Reddy]

Hi Raymond,

The credit goes to Simon Laws for the initial content and setting the pace.
I had a few additions and update to the test status.

Thanks for the update on byte[] support.  I will update the wiki once I
verify that the test passes.

Thanks and best regards,
Vamsi

On Thu, Jun 5, 2008 at 3:00 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> The wiki page is very nice. Thanks.
>
> A quick update, the byte[] support is now in place and the test case is
> passing in SVN.
>
> Thanks,
> Raymond
>
> --
> From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 11:09 AM
> To: 
> Subject: Databinding integration tests
>
>
>  Hi,
>>
>> I have been developing some databinding integration tests recently.  The
>> scope and status of this exercise is maintained in Tuscany wiki at [1].
>> The
>> tests developed so far are under sca\itest\databinding\jaxb-bottom-up [2].
>> Please provide comments, suggestions on the scope, anything missing, any
>> improvements to the code already in svn, etc. so that we have a good test
>> coverage.
>>
>> Thanks,
>> Vamsi
>>
>> [1]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope
>> [2]
>>
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up
>>
>>

Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected

[Scott Kurz]

Since no one objected to the understanding we reached in this thread, shall
we close out TUSCANY-2109?

I'd like to summarize by saying that we agree that when doing interface
matching, namespaces of the interfaces will not be matched.

(Not sure if there is a context I'm not considering which would make that
too broad a statement, however.)

Scott

Re: Databinding integration tests

[Raymond Feng]

The wiki page is very nice. Thanks.

A quick update, the byte[] support is now in place and the test case is 
passing in SVN.


Thanks,
Raymond

--
From: "Vamsavardhana Reddy" <[EMAIL PROTECTED]>
Sent: Wednesday, June 04, 2008 11:09 AM
To: 
Subject: Databinding integration tests


Hi,

I have been developing some databinding integration tests recently.  The
scope and status of this exercise is maintained in Tuscany wiki at [1]. 
The

tests developed so far are under sca\itest\databinding\jaxb-bottom-up [2].
Please provide comments, suggestions on the scope, anything missing, any
improvements to the code already in svn, etc. so that we have a good test
coverage.

Thanks,
Vamsi

[1] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up

[jira] Resolved: (TUSCANY-2349) TransformationException when invoking a method with byte array paramter using webservice binding

[Raymond Feng (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Raymond Feng resolved TUSCANY-2349.
---

Resolution: Fixed

The test case is now passed.

> TransformationException when invoking a method with byte array paramter using 
> webservice binding
> 
>
> Key: TUSCANY-2349
> URL: https://issues.apache.org/jira/browse/TUSCANY-2349
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension, Java SCA Data Binding 
> Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Raymond Feng
>
> I have a service method that takes a byte array as parameter and returns a 
> byte array.  When I invoke the method using webservice binding, I am getting 
> a TransformationException: No path found for the transformation: 
> java:simpleType->java:array.
> The stacktrace is given below:
> org.apache.tuscany.sca.databinding.TransformationException: No path found for 
> the transformation: java:simpleType->java:array
>   at 
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:163)
>   at 
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:67)
>   at 
> org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:152)
>   at 
> org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:1)
>   at 
> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
>   at 
> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:76)
>   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 $Proxy11.negateByteArray(Unknown Source)
>   at 
> org.apache.tuscany.sca.itest.databindings.jaxb.impl.PrimitivesServiceClientImpl.negateByteArrayForward(PrimitivesServiceClientImpl.java:54)
>   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:110)
>   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 $Proxy10.negateByteArrayForward(Unknown Source)
>   at 
> org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.performTestNegateByteArray(PrimitivesDatabindingTestCase.java:372)
>   at 
> org.apache.tuscany.sca.itest.databindings.jaxb.PrimitivesDatabindingTestCase.testWSNegateByteArray(PrimitivesDatabindingTestCase.java:236)
>   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.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>   at 
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
>   at 
> org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
>   at 
> org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
>   at 
> org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52

Databinding integration tests

[Vamsavardhana Reddy]

Hi,

I have been developing some databinding integration tests recently.  The
scope and status of this exercise is maintained in Tuscany wiki at [1].  The
tests developed so far are under sca\itest\databinding\jaxb-bottom-up [2].
Please provide comments, suggestions on the scope, anything missing, any
improvements to the code already in svn, etc. so that we have a good test
coverage.

Thanks,
Vamsi

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope
[2]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/databindings/jaxb-bottom-up

Re: TUSCANY-2344 & 5 - resource & widget validation

[Luciano Resende]

Sorry, for some reason I had to apply your patch manually and missed
that part on the ResourceImplementationProcessor. Please give it a
try, it should be ok now.

On Tue, Jun 3, 2008 at 12:13 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:
> Hi Luciano,
> I tried with the latest code, it looks
> like testCalculator(impl.resource.CouldNotResolveLocationTestCase) is
> failing again due to the same issue we saw with the earlier patch. But this
> time itest for implementation.widget is sucessfull as the patch for
> WidgetImplementationProcessor.java got applied appropriately.
>
> Again i could see that the patch is not fully applied
> to ResourceImplementationProcessor.java file. I could see the patch file
> showing the necessary changes, but could not find them in the
> committed code.
>
> Not sure if the patch files that I am creating has some issues here OR is
> something going wrong while the patches are being applied. I would recommend
> to verify the same and let me know if any corrections are needed from my
> side.
>
>
> On 6/3/08, Luciano Resende <[EMAIL PROTECTED]> wrote:
>>
>> Hi Ram
>>
>>   I have just applied the TUSCANY-2362 patch. Could you please take a
>> quick look as I was having issues trying to get a sucessful run of the
>> validation iTest bucket, but I guess it's due to different issues.
>>
>> Thanks
>>
>> On Mon, Jun 2, 2008 at 3:18 AM, Simon Laws <[EMAIL PROTECTED]>
>> wrote:
>> > On Mon, Jun 2, 2008 at 11:15 AM, Ramkumar R <[EMAIL PROTECTED]>
>> wrote:
>> >
>> >> Hi Simon,
>> >> I have provided the fix with TUSCANY-2362 for the same.
>> >>
>> >> For Junit4, let me have a look and provide the changes accordingly.
>> >>
>> >>
>> >> On 6/2/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >> >
>> >> > On Mon, Jun 2, 2008 at 8:14 AM, Ramkumar R <[EMAIL PROTECTED]>
>> >> wrote:
>> >> >
>> >> > > Hi Simon,
>> >> > > After downloading the complete latest code from the repository, i
>> >> noticed
>> >> > > that the reason for the failure in CouldNotResolveLocation for
>> >> > > implementation.resource and implementation.widget validation is due
>> to
>> >> > the
>> >> > > missed code while applying the patch.
>> >> > >
>> >> > > The changes suggested in the patch does not seem to appear in the
>> >> > committed
>> >> > > code. For instance TUSCANY-2344 suggested a change in
>> >> > > WidgetImplementationProcessor resolve method as shown below, which
>> is
>> >> > > required for the tests to be sucessfull.
>> >> > >
>> >> > > while (reader.hasNext()) {
>> >> > > @@ -128,8 +149,11 @@
>> >> > > } catch (IOException e) {
>> >> > >  ContributionResolveException ce = new
>> >> > > ContributionResolveException(e);
>> >> > >  error("ContributionResolveException", resolver, ce);
>> >> > > -   throw ce;
>> >> > > +   //throw ce;
>> >> > > }
>> >> > > +} else {
>> >> > > +error("CouldNotResolveLocation", resolver,
>> >> > > implementation.getLocation());
>> >> > > +//throw new ContributionResolveException("Could not
>> >> resolve
>> >> > > implementation.widget location: " + implementation.getLocation());
>> >> > > }
>> >> > > Not sure, if i should open a new JIRA OR reopen the older ones to
>> apply
>> >> > the
>> >> > > patch again. Please suggest.
>> >> > >
>> >> > > Also would be helpful if you could elobrate more about the
>> conversion
>> >> of
>> >> > > tests to JUnit4. Thakns.
>> >> > >
>> >> > > On 5/29/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>> >> > > >
>> >> > > > Hi
>> >> > > >
>> >> > > > FYI. I've seen a couple of problems with the widget and resource
>> >> > > validation
>> >> > > > testing during may latest build. CouldNotResolveLocation doesn't
>> seem
>> >> > to
>> >> > > be
>> >> > > > raise. I've @Ignored these tests for now just in case it's going
>> to
>> >> > > affect
>> >> > > > others (I changed the test to JUnit4 to make this easy) .
>> >> > > >
>> >> > > >
>> >> > > > As an aside we should probably go through these tests and convert
>> to
>> >> > > Junit4
>> >> > > >
>> >> > > > Also I notice that the original tests I added don't fit into the
>> neat
>> >> > > > categorization scheme that has been used subsequently so I'll
>> >> endeavor
>> >> > to
>> >> > > > move the original tests into the new scheme to tidy things up.
>> >> > > >
>> >> > > > Simon
>> >> > > >
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Thanks & Regards,
>> >> > > Ramkumar Ramalingam
>> >> > >
>> >> >
>> >> > Hi Ram
>> >> >
>> >> > Can you identify which parts of the patch are missing and create a new
>> >> > patch
>> >> > based on just these. As they didn't apply properly in the first place
>> I
>> >> > don't think that trying to apply the existing patch again will have
>> the
>> >> > desired effect.
>> >> >
>> >> > Re. Junit4. Some of our tests in Tuscany use JUnit4 and some of them
>> use
>> >> > older versions of JUnit. As we are creating new tests here it would be
>> >> > convenient to

Re: svn commit: r663002 - in /incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources: tuscany-sca-data-helper.xsd tuscany-sca-implementation-das.xsd tuscany-sca-implementation-data-xml.xsd

[Luciano Resende]

Sorry for the inconvenience, I have removed the offending XSD for now,
and it looks like this resolved the issue mentioned below.

On Wed, Jun 4, 2008 at 1:19 AM, ant elder <[EMAIL PROTECTED]> wrote:
> I'm getting a build failure in modules/assembly-xml after this with the
> error below, does anyone else see that? Commenting out the includes for
> implementation-das and data-xml gets it going again.
>
> testReadBinding(org.apache.tuscany.sca.assembly.xml.ReadDocumentTestCase)
> Time elapsed: 0.032 sec  <<< ERROR!
> java.lang.IllegalStateException: org.xml.sax.SAXParseException:
> cos-nonambig: WC["http://tuscany.apache.org/xmlns/sca/1.
> 0"] and "http://tuscany.apache.org/xmlns/sca/1.0":ConnectionInfo (or
> elements from their substitution group) violate "Un
> ique Particle Attribution". During validation against this schema, ambiguity
> would be created for those two particles.
>at
> org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.initializeSchemas(DefaultValid
> atingXMLInputFactory.java:135)
>
>   ...ant
>
> On Wed, Jun 4, 2008 at 7:27 AM, <[EMAIL PROTECTED]> wrote:
>
>> Author: lresende
>> Date: Tue Jun  3 23:27:11 2008
>> New Revision: 663002
>>
>> URL: http://svn.apache.org/viewvc?rev=663002&view=rev
>> Log:
>> Schema for implementation.das and implementation.data
>>
>> Added:
>>
>>  
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>>   (with props)
>>
>>  
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>>   (with props)
>>
>>  
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-data-xml.xsd
>>   (with props)
>> Modified:
>>
>>  
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca.xsd
>>
>> Added:
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>> URL:
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd?rev=663002&view=auto
>>
>> ==
>> ---
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>> (added)
>> +++
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>> Tue Jun  3 23:27:11 2008
>> @@ -0,0 +1,44 @@
>> +
>> +
>> +http://www.w3.org/2001/XMLSchema";
>> +targetNamespace="http://data.tuscany.apache.org/xmlns/sca/1.0";
>> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
>> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
>> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
>> +elementFormDefault="qualified">
>> +
>> +
>> +   
>> +   
>> +   
>> +   
>> +   
>> +
>> +
>> +
>> +   
>> +   > +   name="ConnectionProperties"
>> type="data:ConnectionProperties" />
>> +   
>> +   
>> +   > +   default="true" />
>> +
>> +
>>
>> Propchange:
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>>
>> --
>>svn:eol-style = native
>>
>> Propchange:
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>>
>> --
>>svn:keywords = Rev Date
>>
>> Propchange:
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>>
>> --
>>svn:mime-type = text/xml
>>
>> Added:
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>> URL:
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd?rev=663002&view=auto
>>
>> ==
>> ---
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>> (added)
>> +++
>> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>> Tue Jun  3 23:27:11 2008
>> @@ -0,0 +1,46 @@
>> +
>> +
>> +http://www.w3.org/2001/XMLSchema";
>> +targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0";
>> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
>> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
>> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
>> +elementFormDefault="qualified">
>> +
>> +http://www.osoa.org/xmlns/sca/1.0";
>> schemaLocation="sca-core.xsd"/>
>> +http://data.tuscany.apache.org/xmlns/sca/1.0";
>> schemaLocation="tuscany-sca-data-helper.xsd"/>
>> +
>> +
>> +
>>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Raymond Feng]

Hi,

Luciano had a good point that if we keep the version prefix for the 
SNAPSHOT, we can publish them onto the snapshot repos so that other projects 
can use it. +1 to keep the version prefix.


Thanks,
Raymond
--
From: "Luciano Resende" <[EMAIL PROTECTED]>
Sent: Wednesday, June 04, 2008 9:59 AM
To: 
Subject: Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to 
SNAPSHOT



The good thing about having a version on the pom is that you can have
multiple SNAPSHOTs available in a maven repo (e.g 1.2-SNAPSHOT,
1.2.1-SNAPSHOT, TRUNK x-SNAPSHOT and TRUNK y-SNAPSHOT), this also
allows for multiple active development streams.

If you have SNAPSHOT only, I guess you are restricted to only latest
SNAPSHOT, and I also don't see how you would be able to have multiple
active development streams in this case.

As for what's our next release, I think this is decided when we cut a
branch and our SNAPSHOT pom version should not be dictating it. I
guess having 2.0-SNAPSHOT would just allow us to have multiple
releases without having to change trunk pom multiple times, and only
changing the branch when we know what would be the version of the
release, otherwise, we would have to bum trunk version on every
release.

Thoughts ?

On Wed, Jun 4, 2008 at 7:33 AM, Simon Laws <[EMAIL PROTECTED]> 
wrote:

On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:


2008/6/4 ant elder <[EMAIL PROTECTED]>:
> Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need 
> to

> remove "incubating" at some point and as its not clear if the next
release
> would be 2.0 or something else so i wondered if we should also remove 
> the
> 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that 
> or

the
> timeframe for doing the change? I'd like to do it nowish so we have 
> some

> time to discover any problems before the next release.
>
>   ...ant
>

Hi ant,
could you try a fresh build from svn?
I've some problems with and I 'd go on with my work before we're
arriving to 2.0.


Ciao,
Giorgio.
---
"Venceremos adelante, o victoria o muerte!"



I agree that it doesn't feel like the next release will be 2.0
I would prefer that we keep the trunk compatible with our 1.X level APIs 
for

the time being as it feels like there is still a more 1.X releases to do
If people are going to start making breaking changes in a branch (we
discussed this under the 2.0 thread but it's not happening yet) then it
would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
that I know by looking on my disc what I'm working with
When (if?) the time comes down the line to break from our 1.X APIs we 
could

then go to SNAPSHOT  or 2.0 SNAPSHOT

Regards

Simon





--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/ 

Re: Secure-bigbank demo, was Re: svn commit: r641708 - /incubator/tuscany/java/sca/demos/pom.xml

[Luciano Resende]

Thanks Venkat, I have removed the demo under revision #663316.

On Tue, Jun 3, 2008 at 4:18 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> All of what is done in secure-bigbank has now been merged into the bigbank.
> I should have deleted secure-bigbank then.  My bad and apologies for that.
>
> Thanks
>
> - Venkat
>
> On Wed, May 28, 2008 at 10:38 PM, Luciano Resende <[EMAIL PROTECTED]>
> wrote:
>
>> I have added this back to build under revision #661019.
>>
>> On Tue, May 27, 2008 at 11:00 AM, Luciano Resende <[EMAIL PROTECTED]>
>> wrote:
>> > I tried to build the secure-bigbank demo and it worked ok for me.
>> > Any particular reason why this demo was removed from build ?
>> >
>> > On Wed, Mar 26, 2008 at 10:54 PM,  <[EMAIL PROTECTED]> wrote:
>> >> Author: svkrish
>> >> Date: Wed Mar 26 22:54:44 2008
>> >> New Revision: 641708
>> >>
>> >> URL: http://svn.apache.org/viewvc?rev=641708&view=rev
>> >> Log:
>> >> removing secure-bigbank demo
>> >>
>> >> Modified:
>> >>incubator/tuscany/java/sca/demos/pom.xml
>> >>
>> >> Modified: incubator/tuscany/java/sca/demos/pom.xml
>> >> URL:
>> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/demos/pom.xml?rev=641708&r1=641707&r2=641708&view=diff
>> >>
>> ==
>> >> --- incubator/tuscany/java/sca/demos/pom.xml (original)
>> >> +++ incubator/tuscany/java/sca/demos/pom.xml Wed Mar 26 22:54:44 2008
>> >> @@ -43,7 +43,6 @@
>> >> bigbank-stockquote
>> >> mortgage-creditcheck
>> >> mortgage-loanapproval
>> >> -secure-bigbank
>> >> xml-bigbank
>> >> 
>> >> 
>> >>
>> >>
>> >>
>> >> -
>> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Luciano Resende
>> > Apache Tuscany Committer
>> > http://people.apache.org/~lresende
>> > http://lresende.blogspot.com/
>> >
>>
>>
>>
>> --
>> Luciano Resende
>> Apache Tuscany Committer
>> http://people.apache.org/~lresende 
>> http://lresende.blogspot.com/
>>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

[jira] Closed: (TUSCANY-2365) ExtensibleStAXArtifactProcessor should register an error when a unrecognized element is found

[Ramkumar Ramalingam (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ramkumar Ramalingam closed TUSCANY-2365.


Resolution: Invalid

On 6/4/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
On second thoughts.. there is no point of this JIRA if a categorized error
message cannot be logged at this point.. If we do log a warning that an
unrecognized element has been encountered, then it will have to be it.
Nothing more useful can be done if it is not categorized..

You can cancel this JIRA.


> ExtensibleStAXArtifactProcessor should register an error when a unrecognized 
> element is found
> -
>
> Key: TUSCANY-2365
> URL: https://issues.apache.org/jira/browse/TUSCANY-2365
> Project: Tuscany
>  Issue Type: Improvement
> Environment: All
>Reporter: Hasan Muhammad
>Assignee: Ramkumar Ramalingam
>Priority: Critical
>
> ExtensibleStAXArtifactProcessor should register an error instead of a warning 
> when unrecognized elements such as unsupported implementation types and 
> binding types are found. Currently it registers a warning.
> If possible, it is better to isolate unsupported implementation and binding 
> types as separate error messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Ramkumar R]

I have cancelled this JIRA.

On 6/4/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> On second thoughts.. there is no point of this JIRA if a categorized error
> message cannot be logged at this point.. If we do log a warning that an
> unrecognized element has been encountered, then it will have to be it.
> Nothing more useful can be done if it is not categorized..
>
> You can cancel this JIRA.
>
> On Wed, Jun 4, 2008 at 10:10 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
>
> > I believe that we log a warning that an unknown element is encountered.
> > Isn't it sufficient?
> >
> > Thanks,
> > Raymond
> > --
> > From: "Ramkumar R" <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 04, 2008 4:37 AM
> > To: 
> > Subject: Re: ExtensibleStAXArtifactProcessor should register error when
> > unsupported implementation or binding types are found
> >
> >
> >  Hi Hasan,
> >>
> >> The ideal place to catch these exceptions seems to be in the
> >> ExtensibleStAXArtifactProcessor read method, i think it would not be
> >> possible to categorize the exception based on implementation and binding
> >> at
> >> this stage.
> >>
> >> I believe it would be possible to throw a generic exception saying that
> >> this
> >> element is not supported by the runtime as it does not have a suitable
> >> processor to proceed.
> >>
> >> Let me know your say on this. Thanks.
> >> On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
> >>
> >>>
> >>> Hi Simon,
> >>>
> >>> I have raised JIRA 2365 to address this issue.
> >>>
> >>> regards
> >>> Hasan
> >>>
> >>>
> >>
> >>
> >> --
> >> Thanks & Regards,
> >> Ramkumar Ramalingam
> >>
> >>
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

[jira] Closed: (TUSCANY-2367) vtest for binding.ws with promoted services and references

[Kevin Williams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Williams closed TUSCANY-2367.
---

Resolution: Fixed

> vtest for binding.ws with promoted services and references
> --
>
> Key: TUSCANY-2367
> URL: https://issues.apache.org/jira/browse/TUSCANY-2367
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Assignee: Kevin Williams
>Priority: Minor
> Attachments: T2367.vtest.patch, T2367.vtest.zip
>
>
> Test ws bindings with promoted services and references for section 2.2.2 
> 2.3.1, and 2.3.3.1 of WS Binding Spec V1.00

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Luciano Resende]

The good thing about having a version on the pom is that you can have
multiple SNAPSHOTs available in a maven repo (e.g 1.2-SNAPSHOT,
1.2.1-SNAPSHOT, TRUNK x-SNAPSHOT and TRUNK y-SNAPSHOT), this also
allows for multiple active development streams.

If you have SNAPSHOT only, I guess you are restricted to only latest
SNAPSHOT, and I also don't see how you would be able to have multiple
active development streams in this case.

As for what's our next release, I think this is decided when we cut a
branch and our SNAPSHOT pom version should not be dictating it. I
guess having 2.0-SNAPSHOT would just allow us to have multiple
releases without having to change trunk pom multiple times, and only
changing the branch when we know what would be the version of the
release, otherwise, we would have to bum trunk version on every
release.

Thoughts ?

On Wed, Jun 4, 2008 at 7:33 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
>
>> 2008/6/4 ant elder <[EMAIL PROTECTED]>:
>> > Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
>> > remove "incubating" at some point and as its not clear if the next
>> release
>> > would be 2.0 or something else so i wondered if we should also remove the
>> > 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or
>> the
>> > timeframe for doing the change? I'd like to do it nowish so we have some
>> > time to discover any problems before the next release.
>> >
>> >   ...ant
>> >
>>
>> Hi ant,
>> could you try a fresh build from svn?
>> I've some problems with and I 'd go on with my work before we're
>> arriving to 2.0.
>>
>>
>> Ciao,
>> Giorgio.
>> ---
>> "Venceremos adelante, o victoria o muerte!"
>>
>
> I agree that it doesn't feel like the next release will be 2.0
> I would prefer that we keep the trunk compatible with our 1.X level APIs for
> the time being as it feels like there is still a more 1.X releases to do
> If people are going to start making breaking changes in a branch (we
> discussed this under the 2.0 thread but it's not happening yet) then it
> would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
> that I know by looking on my disc what I'm working with
> When (if?) the time comes down the line to break from our 1.X APIs we could
> then go to SNAPSHOT  or 2.0 SNAPSHOT
>
> Regards
>
> Simon
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Splitting binding and impl models and runtimes

[Jean-Sebastien Delfino]

Ramkumar R wrote:

Hi Sebastien,
One thing that comes to my mind is about the JavaRuntimeModuleActivator that
also needs some modularization as we were discussing upon them some time
back.



Yes! I'll do that one next.

--
Jean-Sebastien

[jira] Assigned: (TUSCANY-2367) vtest for binding.ws with promoted services and references

[Kevin Williams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevin Williams reassigned TUSCANY-2367:
---

Assignee: Kevin Williams

> vtest for binding.ws with promoted services and references
> --
>
> Key: TUSCANY-2367
> URL: https://issues.apache.org/jira/browse/TUSCANY-2367
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Assignee: Kevin Williams
>Priority: Minor
> Attachments: T2367.vtest.patch, T2367.vtest.zip
>
>
> Test ws bindings with promoted services and references for section 2.2.2 
> 2.3.1, and 2.3.3.1 of WS Binding Spec V1.00

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: itest/validation problem

[Luciano Resende]

Hi Ant, this should be resolved now.

On Wed, Jun 4, 2008 at 2:23 AM, Ramkumar R <[EMAIL PROTECTED]> wrote:
> Hi Ant,
> This testcase fails due to an issue that we faced while applying the patch.
> FYI... This issue is also discussed in the below thread.
>
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200806.mbox/[EMAIL 
> PROTECTED]
>
> Hope to get this resolved soon.
>
>
> On 6/4/08, ant elder <[EMAIL PROTECTED]> wrote:
>>
>> I'm getting a test fail in itest/validation with the failed test:
>> testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this
>> work or fail for anyone else?
>>
>>   ...ant
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Has anyone run tuscany on a local other than English?

[Adriano Crestani]

Hi Hasan,

Yes, I ran on a brazilian-portuguese system. It worked well. Are you getting
any issues?

Regards,
Adriano Crestani

On Wed, Jun 4, 2008 at 7:56 AM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> I wanted to know if anyone has run tuscany on a local other than English?
> If
> so, did you see any problems?
>
> regards
> Hasan
>

Re: Google Services License, was: Re: [GSoC] [DISCUSS] Development of GData biding

[Luciano Resende]

Sorry, I should have said legal-discuss@,
Below is the thread if others want to follow the discussion.

http://markmail.org/search/?q=google%20services%20license%20legal-discuss#query:google%20services%20license%20legal-discuss+page:1+mid:axkv3tduvnfgynkr+state:results

On Wed, Jun 4, 2008 at 5:01 AM, Robert Burrell Donkin
<[EMAIL PROTECTED]> wrote:
> On Wed, Jun 4, 2008 at 7:59 AM, Luciano Resende <[EMAIL PROTECTED]> wrote:
>> I'm About to forward to legal@ to get further advice.
>
> i recommend legal-discuss as the first point of contact
>
> - robert
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Running Tuscany/SCA in Google Android mobile platform

[Adriano Crestani]

Hi Oscar,


When I imported the projects from [3] the following projects were not
imported:

core-android
host-android
extensibility

Is this normal? Should they be imported?

Yep, they should be imported, if you check inside its folders, there are the
eclipse project files, so they should be identified by the eclipse import
tool as an eclipse project.

Thanks for the detailed explanation. I'm going to give this a try as I found
an introspection related comment [2] as a workaround to another annotations
problem with the current SDK.

I don't think introspection is a good solution, hence you will need to
change how the sca reads the info about each service and also services
implemented for JVM would need to be adapted to run on Android. Let's avoid
to modify so much the SCA code, and lets try to keep retrotranslator in mind
as a temporary workaround for annotations till next SDK release :S

Also, if you get the retrotranslator working, forget the Luciano's
suggestion and vice-versa...do not try both at the same time ; )

Any progress testing retrotranslator on a simpler scenario, just let us know
; )

Kind Regards,
Adriano Crestani


On Wed, Jun 4, 2008 at 3:27 AM, Oscar Castaneda <
[EMAIL PROTECTED]> wrote:

> Hi Adriano,
>
> At first, build a simple, but equivalent scenario, and test it.
>
>
> I think this is a great idea, especially because I found that the "native
> method not implemented" errors I'm getting [1] are still related to the
> annotations problem. I'm getting the same errors when converting the code
> to
> java 1.4. This makes me think that retrotranslator is actually not working.
> Hopefully, testing with a simpler scenario will help me to understand the
> problem better.
>
> Sorry for the not-well-detailed info here. I meant you to do:
> >
> > Search in every sca code for the usage of Class.isAnnotationPresent or
> > getAnnotations or getAnnotation methods. If it checks for a the
> @Remotable
> > annotations force it to true, for example:
> >
> > Annotation isRemotable = class.isAnnotationPresent
> >>
> >> (Remotable.class); =>
> >> Annotation isRemotable = true;
> >>
> >> otherwise, which means, when it's not checking for the @Remotable
> >> annnotation, force to false. For example:
> >>
> >> Annotation isReference = class.isAnnotationPresent(Reference.class); =>
> >> Annotation isReference = false;
> >
> >
>
> Thanks for the detailed explanation. I'm going to give this a try as I
> found
> an introspection related comment [2] as a workaround to another annotations
> problem with the current SDK.
>
> Also, I have another question for you...
>
> When I imported the projects from [3] the following projects were not
> imported:
>
> core-android
> host-android
> extensibility
>
> Is this normal? Should they be imported?
>
>
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/2Jun2008
> [2]
>
>
> http://code.google.com/p/android/issues/detail?id=268&can=1&q=annotations&colspec=ID%20Type%20Version%20Security%20Status%20Owner%20Summary#c3
> [3]
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android
>
>
> On Tue, Jun 3, 2008 at 4:32 AM, Adriano Crestani <
> [EMAIL PROTECTED]>
> wrote:
>
> > Well detailed Oscar ; )
> >
> > It is one thing I learnt after playing hours with Android, you need to
> > rebuild every modified project which is imported in the android project,
> > the
> > android project itself does not check for modifications on its
> dependencies
> > :S...so, when you rebuilt the imported project it recompiled the
> > uncommented
> > code at JavaRuntimeModuleActivator and the SCA started to check for
> > annotations once again, so you got the errors on [1], which means
> > retrotranslator is still not working. Have you tested it on a simpler
> > application as I previously suggested? Did it work? What was the most
> > critical scenario you tested it and it worked?
> >
> > " Voyager-2:30May ocastaneda$ java -jar
> > /../retrotranslator-transformer-1.2.6.jar -srcdir /../workspace
> > -target 1.5 -reflection safe -stripannot -classpath
> > /../retrotranslator-android-1.2.6.jar -verbose"
> >
> > You should also check if it's is working as expected, as I already said,
> > does not go directly testing complex solutions on complex things like
> SCA.
> > At first, build a simple, but equivalent scenario, and test it. For
> > example,
> > a simple android app project that uses an java library project which
> access
> > annotations on classes placed on the android project. Like our android
> > calculator, it's an android app project (calculator-android) which uses
> > java
> > library projects (sca modules), and these libraries checks for
> annotations
> > on classes located at the android app project (CalculatorService.java,
> > AddService.java, etc). When you get it working on the simpler scenario,
> > then
> > you are ready to test it on the complexer sceneario (calculator-android).
> >
> > Please, if you get the retrotranslator working in the simpler scenario,
> >

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602328#action_12602328
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi,

yes, the activator sets TCCL and I also use option -clean.

The difference is in line 3:

at 
org.apache.tuscany.sca.extension.helper.impl.BindingsActivator.start(BindingsActivator.java:72)
 (former exception)
vs.
at 
org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34)
 (current exception)

I debugged a little, it happens when Tuscany tries to find the interface 
org.apache.tuscany.sca.contribution.processor.StAXArtifactProcessorExtensionPoint.
Perhaps this is somehow related to the problems we encountered with JAXB ?

Bye,
Daniel

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Has anyone run tuscany on a local other than English?

[Hasan Muhammad]

I wanted to know if anyone has run tuscany on a local other than English? If
so, did you see any problems?

regards
Hasan

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Hasan Muhammad]

On second thoughts.. there is no point of this JIRA if a categorized error
message cannot be logged at this point.. If we do log a warning that an
unrecognized element has been encountered, then it will have to be it.
Nothing more useful can be done if it is not categorized..

You can cancel this JIRA.

On Wed, Jun 4, 2008 at 10:10 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> I believe that we log a warning that an unknown element is encountered.
> Isn't it sufficient?
>
> Thanks,
> Raymond
> --
> From: "Ramkumar R" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 4:37 AM
> To: 
> Subject: Re: ExtensibleStAXArtifactProcessor should register error when
> unsupported implementation or binding types are found
>
>
>  Hi Hasan,
>>
>> The ideal place to catch these exceptions seems to be in the
>> ExtensibleStAXArtifactProcessor read method, i think it would not be
>> possible to categorize the exception based on implementation and binding
>> at
>> this stage.
>>
>> I believe it would be possible to throw a generic exception saying that
>> this
>> element is not supported by the runtime as it does not have a suitable
>> processor to proceed.
>>
>> Let me know your say on this. Thanks.
>> On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hi Simon,
>>>
>>> I have raised JIRA 2365 to address this issue.
>>>
>>> regards
>>> Hasan
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
>>

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602324#action_12602324
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

I am not sure I missed something, but this stack trace looks exactly the same 
as the previous one.  

Does org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator set TCCL 
before calling EmbeddedSCADomain.start? If so, is it possible that this bundle 
is being loaded from the cache (could you try -clean option)? I will try to fix 
this in Tuscany this weekend, but at the moment it would be safest to set TCCL 
in all your bundle activators starting SCADomains.

- Rajini

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Splitting binding and impl models and runtimes

[Ramkumar R]

Hi Sebastien,
One thing that comes to my mind is about the JavaRuntimeModuleActivator that
also needs some modularization as we were discussing upon them some time
back.

For your reference:
On 5/29/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> JavRuntimeModuleActivator is responsible for setting up the Java component
> implementation runtime, allowing you to activate Java component instances
> and dispatch to invocations from/to them. In theory it should be possible to
> initialize the model, XML reader, and
> introspection layers without bringing up the runtime layer. Unfortunately
> it's probably not possible at the moment as the implementation-java-*
> modules do not follow a clean layering... and mash
> everything up starting in JavaRuntimeModuleActivator.
>
> So to summarize:
> - JavaRuntimeModuleActivator mashes way too much together and should be
> modularized
>
Thanks.


On 6/3/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> I'm starting to split some of the binding and implementation models in
> separate modules, to allow their models to be used without dragging their
> runtime dependencies.
>
> We've already done that on a number of them, I'm going to follow the same
> pattern for the following modules as well:
> - implementation-widget
> - implementation-resource
> - binding-http
> - binding-ejb
> - binding-jsonrpc
>
> This shouldn't break existing code as APIs/SPIs won't change.
>
> If there's no objections I'll commit these changes later this week.
> --
> Jean-Sebastien
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: Changing throw IncompatibleInterfaceContractException to a log

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Jean-Sebastien,

What happens to the model object that is being constructed when this 
error occurs?


I'm assuming this is a reference or a wire of some kind?


Yours,  Mike.

Jean-Sebastien Delfino wrote:
I'm changing the throw new IncompatibleInterfaceContractException() 
statements in the composite builders to log statements. I need to do 
that for three reasons:


- Throwing that exception abruptly stops further processing, 
preventing us to continue validating the composite and log other 
relevant errors.


- That exception stops the composite builder and prevents me to build 
a domain composite when there's an incompatible interface in part of 
the domain.


- We're handling most other similar errors as logs so I'm not sure why 
we've kept that one as a thrown exception, for example in the 
following code:


   boolean isCompatible = 
interfaceContractMapper.isCompatible(compositeServiceInterfaceContract,promotedServiceInterfaceContract); 


if(!isCompatible){
throw new 
IncompatibleInterfaceContractException("Interface of composite service 
"+promotedServiceName +" must be subset of the interface declared by 
promoted component service.", compositeServiceInterfaceContract, 
promotedServiceInterfaceContract);

}
}

} else {
warning("PromotedServiceNotFound", composite, 
composite.getName().toString(), promotedServiceName);


if a "PromotedServiceNotFound" error is considered benign enough to 
just be logged, then an "IncompatibleInterface" situation (in that 
case the promoted service was found, so we're in a better shape here) 
is a good candidate for logging as well :)




No change to the model object.

Looking further in this code (BaseWireBuilderImpl), there are 6 cases of 
incompatible interfaces, 4 were logged, 2 were throwing exceptions. I 
changed the 2 exceptions to log like the 4 other cases.


--
Jean-Sebastien

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602316#action_12602316
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi all, 

I just set up a launch configuration for our "productive" bundle. 
Whitout the Activator fix from Rajini I get the same exception as in the "test" 
bundle. (see above)

Then I added the to the activator and now I get the following exception:

java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
at 
org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:128)
at 
org.apache.tuscany.sca.implementation.notification.NotificationModuleActivator.start(NotificationModuleActivator.java:34)
at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.startModules(ReallySmallRuntime.java:354)
at 
org.apache.tuscany.sca.host.embedded.impl.ReallySmallRuntime.start(ReallySmallRuntime.java:139)
at 
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.start(EmbeddedSCADomain.java:79)
at 
org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.initDomainByContribution(ScaDomainActivator.java:96)
at 
org.eclipse.eilf.connectivity.framework.sca.ScaDomainActivator.start(ScaDomainActivator.java:57)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993)
at 
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974)
at 
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346)
at 
org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:350)
at 
org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1118)
at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:634)
at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:508)
at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:282)
at 
org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:468)
at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195)
at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:297)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.tuscany.sca.core.DefaultExtensionPointRegistry.getExtensionPoint(DefaultExtensionPointRegistry.java:113)
... 19 more
Caused by: java.lang.IllegalArgumentException: 
java.lang.reflect.InvocationTargetException
at 
org.apache.tuscany.sca.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:122)
at 
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.(DefaultStAXArtifactProcessorExtensionPoint.java:68)
... 24 more
Caused by: java.lang.reflect.InvocationTargetException
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.contribution.DefaultModelFactoryExtensionPoint.getFactory(DefaultModelFactoryExtensionPoint.java:120)
... 25 more
Caused by: javax.xml.stream.FactoryConfigurationError: Provider 
com.bea.xml.stream.MXParserFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at 
javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
... 30 more


Are there other Threads that need to get set the ContextClassLoader ?

Daniel


> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
>   

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Simon Laws]

On Wed, Jun 4, 2008 at 3:10 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> I believe that we log a warning that an unknown element is encountered.
> Isn't it sufficient?
>
> Thanks,
> Raymond
> --
> From: "Ramkumar R" <[EMAIL PROTECTED]>
> Sent: Wednesday, June 04, 2008 4:37 AM
> To: 
> Subject: Re: ExtensibleStAXArtifactProcessor should register error when
> unsupported implementation or binding types are found
>
>
>  Hi Hasan,
>>
>> The ideal place to catch these exceptions seems to be in the
>> ExtensibleStAXArtifactProcessor read method, i think it would not be
>> possible to categorize the exception based on implementation and binding
>> at
>> this stage.
>>
>> I believe it would be possible to throw a generic exception saying that
>> this
>> element is not supported by the runtime as it does not have a suitable
>> processor to proceed.
>>
>> Let me know your say on this. Thanks.
>> On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hi Simon,
>>>
>>> I have raised JIRA 2365 to address this issue.
>>>
>>> regards
>>> Hasan
>>>
>>>
>>
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
>>
The warning also contains the name of the element that could not be found so
in your code you could look out for the "ElementCannotBeProcessed" warning
registered with the monitor and then take a look at the name parameter
provided in this case to work out what sort of extension is missing.

Regards

Simon

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Simon Laws]

On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:

> 2008/6/4 ant elder <[EMAIL PROTECTED]>:
> > Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
> > remove "incubating" at some point and as its not clear if the next
> release
> > would be 2.0 or something else so i wondered if we should also remove the
> > 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or
> the
> > timeframe for doing the change? I'd like to do it nowish so we have some
> > time to discover any problems before the next release.
> >
> >   ...ant
> >
>
> Hi ant,
> could you try a fresh build from svn?
> I've some problems with and I 'd go on with my work before we're
> arriving to 2.0.
>
>
> Ciao,
> Giorgio.
> ---
> "Venceremos adelante, o victoria o muerte!"
>

I agree that it doesn't feel like the next release will be 2.0
I would prefer that we keep the trunk compatible with our 1.X level APIs for
the time being as it feels like there is still a more 1.X releases to do
If people are going to start making breaking changes in a branch (we
discussed this under the 2.0 thread but it's not happening yet) then it
would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
that I know by looking on my disc what I'm working with
When (if?) the time comes down the line to break from our 1.X APIs we could
then go to SNAPSHOT  or 2.0 SNAPSHOT

Regards

Simon

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602296#action_12602296
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi Rajini,

yes, calling
Thread.currentThread().setContextClassLoader(OSGiRuntime.getRuntime().getContextClassLoader());
befor creating the SCADomain does the trick. At least for this test bundle.

I will do some more testing with our real bundles (more 3rd party dependencies).

Thanks a lot!

Bye,
Daniel

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Raymond Feng]

I believe that we log a warning that an unknown element is encountered. 
Isn't it sufficient?


Thanks,
Raymond
--
From: "Ramkumar R" <[EMAIL PROTECTED]>
Sent: Wednesday, June 04, 2008 4:37 AM
To: 
Subject: Re: ExtensibleStAXArtifactProcessor should register error when 
unsupported implementation or binding types are found



Hi Hasan,

The ideal place to catch these exceptions seems to be in the
ExtensibleStAXArtifactProcessor read method, i think it would not be
possible to categorize the exception based on implementation and binding 
at

this stage.

I believe it would be possible to throw a generic exception saying that 
this

element is not supported by the runtime as it does not have a suitable
processor to proceed.

Let me know your say on this. Thanks.
On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:


Hi Simon,

I have raised JIRA 2365 to address this issue.

regards
Hasan





--
Thanks & Regards,
Ramkumar Ramalingam

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602292#action_12602292
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

The latest stack trace looks like a problem with thread context classloading. 
For XML parsing, the classes from third party bundles should be visible from 
TCCL. Tuscany's bundle activator sets up a TCCL which includes all 3rd party 
bundles. If this bundle activator is run from a different thread from the one 
starting the Tuscany runtime (or if you want to modify TCCL), you have to 
ensure that TCCL has access to classes from 3rd party libs. The TCCL set by 
Tuscany can be obtained using 
o.a.t.s.osgi.runtime.OSGiRuntime.getContextClassLoader(). In your test bundle 
activator, could you try calling
  
Thread.currentThread().setContextClassLoader(OSGiRuntime.getContextClassLoader());

before starting the Tuscany runtime? This should really be fixed properly in 
Tuscany (at least for straightforward usecases), but for now, could you try 
this fix?

- Rajini

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602264#action_12602264
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi,

I just tried to install and start the same bundles as when using the installer. 
To achieve this, I had to remove the Import-Package entry for "sun.misc" in 
tuscany-databinding-xstream-2.0-incubating-SNAPSHOT.jar

Below is the list, the only difference is that when using the installer it's 
bundle is started and bundle org.eclipse.eilf.scatestdomain_0.5.0 is started:

id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.3.0.v20070530
1   RESOLVEDorg.apache.tuscany.sca.binding.jms_2.0.0
2   RESOLVEDorg.apache.tuscany.sca.3rdparty.commons-lang-2.1_2.1.0
3   RESOLVEDorg.apache.tuscany.sca.binding.rss.rome_2.0.0
4   RESOLVEDorg.apache.tuscany.sca.api_2.0.0
5   RESOLVEDorg.apache.tuscany.sca.3rdparty.saxon-api-9.0.0.2_9.0.0.2
6   RESOLVEDorg.apache.tuscany.sca.definitions.xml_2.0.0
7   RESOLVEDorg.apache.tuscany.sca.implementation.java.runtime_2.0.0
8   RESOLVEDorg.apache.tuscany.sca.domain.manager_2.0.0
9   RESOLVEDorg.apache.tuscany.sca.3rdparty.commons-discovery-0.2_0.2.0
10  RESOLVEDorg.apache.tuscany.sca.3rdparty.xalan-2.7.0_2.7.0
11  RESOLVEDorg.apache.tuscany.sca.data.engine.helper_2.0.0
12  RESOLVEDorg.apache.tuscany.sca.3rdparty.json-rpc-1.0_1.0.0
13  RESOLVEDorg.apache.tuscany.sca.implementation.java_2.0.0
14  RESOLVEDorg.apache.tuscany.sca.interface.wsdl.xml_2.0.0
15  RESOLVEDorg.apache.tuscany.sca.binding.sca.axis2_2.0.0
16  RESOLVEDorg.apache.tuscany.sca.3rdparty.stax-api-1.0.1_1.0.1
17  RESOLVEDorg.apache.tuscany.sca.3rdparty.ecore-2.2.3_2.2.3
18  RESOLVEDorg.apache.tuscany.sca.3rdparty.codegen-ecore-2.2.3_2.2.3
19  RESOLVEDorg.apache.tuscany.sca.3rdparty.stax-api-1.0-2_1.0.0
20  RESOLVEDorg.apache.tuscany.sca.3rdparty.axiom-api-1.2.5_1.2.5
21  RESOLVED
org.apache.tuscany.sca.3rdparty.abdera-parser-0.3.0-incubating_0.3.0
22  RESOLVED
org.apache.tuscany.sca.3rdparty.commons-collections-3.1_3.1.0
23  RESOLVED
org.apache.tuscany.sca.3rdparty.backport-util-concurrent-3.0_3.0.0
24  RESOLVEDorg.apache.tuscany.sca.binding.sca_2.0.0
25  RESOLVEDorg.apache.tuscany.sca.3rdparty.axis2-codegen-1.3_1.3.0
26  RESOLVEDorg.apache.tuscany.sdo.spec_2.1.0
27  RESOLVEDorg.apache.tuscany.sca.3rdparty.easymock-2.2_2.2.0
28  RESOLVEDorg.apache.tuscany.sca.binding.rss_2.0.0
29  RESOLVEDorg.apache.tuscany.sca.3rdparty.jaxb2-reflection-2.1.4_2.1.4
30  RESOLVEDorg.apache.tuscany.sca.3rdparty.xercesImpl-2.8.1_2.8.1
31  ACTIVE  org.eclipse.osgi.services_3.1.200.v20070605
32  RESOLVEDorg.apache.tuscany.sca.databinding.saxon_2.0.0
33  RESOLVEDorg.apache.tuscany.sca.3rdparty.axis2-adb-codegen-1.3_1.3.0
34  RESOLVEDorg.apache.tuscany.sca.3rdparty.spring-beans-2.0.6_2.0.6
35  RESOLVEDorg.mortbay.jetty.server_6.1.7
36  RESOLVEDorg.apache.tuscany.sca.contribution_2.0.0
37  RESOLVEDorg.apache.tuscany.sca.3rdparty.activation-1.1_1.1.0
38  RESOLVEDorg.apache.tuscany.sca.workspace_2.0.0
39  RESOLVEDorg.apache.tuscany.sca.interface.java.xml_2.0.0
40  RESOLVEDorg.apache.tuscany.sca.binding.feed_2.0.0
41  RESOLVEDorg.apache.tuscany.sca.3rdparty.servlet-api-2.5_2.5.0
42  RESOLVEDorg.apache.tuscany.sca.3rdparty.mail-1.4_1.4.0
43  RESOLVED
org.apache.tuscany.sca.3rdparty.abdera-core-0.3.0-incubating_0.3.0
44  RESOLVEDorg.apache.tuscany.sca.3rdparty.axis2-mtompolicy-1.3_1.3.0
45  RESOLVEDorg.apache.tuscany.sca.3rdparty.wsdl4j-1.6.2_1.6.2
46  RESOLVEDorg.apache.tuscany.sca.3rdparty.axis2-java2wsdl-1.3_1.3.0
47  RESOLVEDorg.apache.tuscany.sca.3rdparty.rampart-trust-1.3_1.3.0
48  RESOLVEDorg.apache.tuscany.sca.contribution.groovy_2.0.0
49  RESOLVEDorg.apache.tuscany.sca.binding.atom_2.0.0
50  RESOLVEDorg.apache.tuscany.sca.3rdparty.saaj-api-1.3_1.3.0
51  RESOLVEDorg.apache.tuscany.sca.assembly.xsd_2.0.0
52  RESOLVEDorg.apache.tuscany.sca.implementation.xquery_2.0.0
53  RESOLVED
org.apache.tuscany.sca.3rdparty.tuscany-sdo-impl-1.1-incubating_1.1.0
54  RESOLVEDorg.apache.tuscany.sca.binding.dwr_2.0.0
55  RESOLVEDorg.apache.tuscany.sca.monitor.logging_2.0.0
56  RESOLVED
org.apache.tuscany.sca.3rdparty.woden-1.0-incubating-M7b_1.0.0
57  RESOLVEDorg.apache.tuscany.sca.binding.atom.abdera_2.0.0
58  RESOLVEDorg.apache.tuscany.sca.definitions_2.0.0
59  RESOLVED
org.apache.tuscany.sca.3rdparty.tuscany-sdo-tools-1.1-incubating_1.1.0
60  RESOLVEDorg.apache.tuscany.sca.binding.jsonrpc_2.0.0
61  RESOLVED
org

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Giorgio Zoppi]

2008/6/4 ant elder <[EMAIL PROTECTED]>:
> Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
> remove "incubating" at some point and as its not clear if the next release
> would be 2.0 or something else so i wondered if we should also remove the
> 2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or the
> timeframe for doing the change? I'd like to do it nowish so we have some
> time to discover any problems before the next release.
>
>   ...ant
>

Hi ant,
could you try a fresh build from svn?
I've some problems with and I 'd go on with my work before we're
arriving to 2.0.


Ciao,
Giorgio.
---
"Venceremos adelante, o victoria o muerte!"

Re: Google Services License, was: Re: [GSoC] [DISCUSS] Development of GData biding

[Robert Burrell Donkin]

On Wed, Jun 4, 2008 at 7:59 AM, Luciano Resende <[EMAIL PROTECTED]> wrote:
> I'm About to forward to legal@ to get further advice.

i recommend legal-discuss as the first point of contact

- robert

Re: JMS Client

[Nishant Joshi]

Hi There,
I have resolved last error, actually i forgot to add required jms binding
jar, but now i m getting exception as below

my WS admin console was running on 9202 and have found JMS was on 9205... so
my composite was changed as below
.. jndiURL="iiop://localhost:9205">

Exception is.
org.apache.tuscany.sca.binding.jms.impl.JMSBindingException: JMS Destination
HelloWorldService not found with create mode of "ifnotexist" while
registering binding serviceA invoker

HelloWorldService  is there in WS and i can also test service successfully.

-- 
Thanks
Nishant Joshi

Re: JMS Client

[ant elder]

On Wed, Jun 4, 2008 at 11:21 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Thanks Ant,
> I have composed client for WS Here is the snippet of the client
>
>
> -
>
> public class HelloWorldClientImpl {
>
>@Reference
>protected HelloWorldService serviceA;
>
>public String sayHello(String name) {
> System.out.println("HelloWorldClientImpl.serviceA = "+serviceA);
>return serviceA.sayHello(name);
>}
>
> }
>
> -
> @Remotable
> public interface HelloWorldService {
>String sayHello(String name);
> }
>
>
> -
> public class JMSClient {
>  public static void main(String[] args) throws NodeException  {
>  SCANode node = SCANodeFactory.createNodeWithComposite("client.composite");
>  HelloWorldClientImpl client =
> node.getDomain().getService(HelloWorldClientImpl.class,
> "HelloWorldClient");
>
>  System.out.println(client.sayHello("World"));
>  }
>
> }
>
>
> -
>
> http://www.osoa.org/xmlns/sca/1.0";
>   name="RPCComposite">
>
>
>
>
>
>
>
>
> initialContextFactory="com.ibm.websphere.naming.WsnInitialContextFactory"
> jndiURL="iiop://localhost:2809">
>
>
>   
>
>
>
> 
>
> -
> jndi.properties
>
> # START SNIPPET: jndi
>
> java.naming.factory.initial =
> com.ibm.websphere.naming.WsnInitialContextFactory
>
> # use the following property to configure the default connector
> java.naming.provider.url = vm://localhost?broker.persistent=false
>
> # use the following property to specify the JNDI name the connection
> factory
> # should appear as.
> #connectionFactoryNames = connectionFactory, queueConnectionFactory,
> topicConnectionFactry
> connectionFactoryNames = ConnectionFactory
>
> # register some queues in JNDI using the form
> # queue.[jndiName] = [physicalName]
> # queue.RequestQueue = RequestQueue
> # queue.ResponseQueue = ResponseQueue
> queue.HelloWorldService = HelloWorldService
>
> # register some topics in JNDI using the form
> # topic.[jndiName] = [physicalName]
> #topic.MyTopic = example.MyTopic
>
> # END SNIPPET: jndi
>
>
> Here Service is deployed successfuly, i can test with hello.jspIt was
> working fine in WS.
> Now when i run above code I m getting "HelloWorldClientImpl.serviceA =
> null"
> and gettign NPE
> I m using "HelloWorldService" for both Request and Response queue...
>
> any idea ?
>
> Thanks
> Nishant Joshi


I'll give it a try but it will take a while as I'm still recovering from a
harddrive crash last week so will need to find and reinstall WebSphere.
Anyone else with WAS installed able to give this a try in the meantime with
the helloworld-jms-webapp sample?

   ...ant

[jira] Commented: (TUSCANY-2365) ExtensibleStAXArtifactProcessor should register an error when a unrecognized element is found

[Ramkumar Ramalingam (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602251#action_12602251
 ] 

Ramkumar Ramalingam commented on TUSCANY-2365:
--

Hi Hasan,
The ideal place to catch these exceptions seems to be in the 
ExtensibleStAXArtifactProcessor read method, i think it would not be possible 
to categorize the exception based on implementation and binding at this stage.

I believe it would be possible to throw a generic exception saying that this 
element is not supported by the runtime as it does not have a suitable 
processor to proceed.

Let me know your say on this. Thanks.

> ExtensibleStAXArtifactProcessor should register an error when a unrecognized 
> element is found
> -
>
> Key: TUSCANY-2365
> URL: https://issues.apache.org/jira/browse/TUSCANY-2365
> Project: Tuscany
>  Issue Type: Improvement
> Environment: All
>Reporter: Hasan Muhammad
>Assignee: Ramkumar Ramalingam
>Priority: Critical
>
> ExtensibleStAXArtifactProcessor should register an error instead of a warning 
> when unrecognized elements such as unsupported implementation types and 
> binding types are found. Currently it registers a warning.
> If possible, it is better to isolate unsupported implementation and binding 
> types as separate error messages.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found

[Ramkumar R]

Hi Hasan,

The ideal place to catch these exceptions seems to be in the
ExtensibleStAXArtifactProcessor read method, i think it would not be
possible to categorize the exception based on implementation and binding at
this stage.

I believe it would be possible to throw a generic exception saying that this
element is not supported by the runtime as it does not have a suitable
processor to proceed.

Let me know your say on this. Thanks.
On 6/3/08, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> I have raised JIRA 2365 to address this issue.
>
> regards
> Hasan
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

[jira] Commented: (TUSCANY-2357) CORBA objects invocation mechanism

[ant elder (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602249#action_12602249
 ] 

ant elder commented on TUSCANY-2357:


Applied license header patch in r663066, thanks for the patch!

> CORBA objects invocation mechanism
> --
>
> Key: TUSCANY-2357
> URL: https://issues.apache.org/jira/browse/TUSCANY-2357
> Project: Tuscany
>  Issue Type: New Feature
>Reporter: Wojtek Janiszewski
> Attachments: add-license-headers.patch.tar.gz, 
> corba-operation-invoker.patch.tar.gz
>
>
> Implementation of generic mechanism for remote operation invocation: passing 
> CORBA structures, sequences, primitives as arguments, retrieving return 
> values (also structs, seq, prims.). There is no exception handling yet. 
> It's not connected to CORBA binding extension yet - it won't be hard, and I 
> think it's now more important  to complete this generic mechanism.
> Some tests are provided - you need to have tnameserv in your PATH to run 
> tests correctly!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (TUSCANY-2357) CORBA objects invocation mechanism

[ant elder]

Thanks for reminding, i'm applying it now.

   ...ant

On Wed, Jun 4, 2008 at 12:17 PM, Wojtek Janiszewski <
[EMAIL PROTECTED]> wrote:

> Hi,
> I'm starting to worry that following patch will be orphaned :). Could
> anyone take a look?
> Thanks,
> Wojtek
>
>
> Wojtek Janiszewski (JIRA) wrote:
>
>> [
>> https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Wojtek Janiszewski updated TUSCANY-2357:
>> 
>>
>>Attachment: add-license-headers.patch.tar.gz
>>
>> Thanks for reminding. Here's a patch which adds headers to all java and
>> idl files.
>> Wojtek
>>
>>  CORBA objects invocation mechanism
>>> --
>>>
>>>Key: TUSCANY-2357
>>>URL: https://issues.apache.org/jira/browse/TUSCANY-2357
>>>Project: Tuscany
>>> Issue Type: New Feature
>>>   Reporter: Wojtek Janiszewski
>>>Attachments: add-license-headers.patch.tar.gz,
>>> corba-operation-invoker.patch.tar.gz
>>>
>>>
>>> Implementation of generic mechanism for remote operation invocation:
>>> passing CORBA structures, sequences, primitives as arguments, retrieving
>>> return values (also structs, seq, prims.). There is no exception handling
>>> yet. It's not connected to CORBA binding extension yet - it won't be hard,
>>> and I think it's now more important  to complete this generic mechanism.
>>> Some tests are provided - you need to have tnameserv in your PATH to run
>>> tests correctly!
>>>
>>
>>
>

Re: Running Tuscany/SCA in Google Android mobile platform

[Oscar Castaneda]

Hi Adriano,

At first, build a simple, but equivalent scenario, and test it.


I think this is a great idea, especially because I found that the "native
method not implemented" errors I'm getting [1] are still related to the
annotations problem. I'm getting the same errors when converting the code to
java 1.4. This makes me think that retrotranslator is actually not working.
Hopefully, testing with a simpler scenario will help me to understand the
problem better.

Sorry for the not-well-detailed info here. I meant you to do:
>
> Search in every sca code for the usage of Class.isAnnotationPresent or
> getAnnotations or getAnnotation methods. If it checks for a the @Remotable
> annotations force it to true, for example:
>
> Annotation isRemotable = class.isAnnotationPresent
>>
>> (Remotable.class); =>
>> Annotation isRemotable = true;
>>
>> otherwise, which means, when it's not checking for the @Remotable
>> annnotation, force to false. For example:
>>
>> Annotation isReference = class.isAnnotationPresent(Reference.class); =>
>> Annotation isReference = false;
>
>

Thanks for the detailed explanation. I'm going to give this a try as I found
an introspection related comment [2] as a workaround to another annotations
problem with the current SDK.

Also, I have another question for you...

When I imported the projects from [3] the following projects were not
imported:

core-android
host-android
extensibility

Is this normal? Should they be imported?


[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/2Jun2008
[2]

http://code.google.com/p/android/issues/detail?id=268&can=1&q=annotations&colspec=ID%20Type%20Version%20Security%20Status%20Owner%20Summary#c3
[3]
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/mobile-android


On Tue, Jun 3, 2008 at 4:32 AM, Adriano Crestani <[EMAIL PROTECTED]>
wrote:

> Well detailed Oscar ; )
>
> It is one thing I learnt after playing hours with Android, you need to
> rebuild every modified project which is imported in the android project,
> the
> android project itself does not check for modifications on its dependencies
> :S...so, when you rebuilt the imported project it recompiled the
> uncommented
> code at JavaRuntimeModuleActivator and the SCA started to check for
> annotations once again, so you got the errors on [1], which means
> retrotranslator is still not working. Have you tested it on a simpler
> application as I previously suggested? Did it work? What was the most
> critical scenario you tested it and it worked?
>
> " Voyager-2:30May ocastaneda$ java -jar
> /../retrotranslator-transformer-1.2.6.jar -srcdir /../workspace
> -target 1.5 -reflection safe -stripannot -classpath
> /../retrotranslator-android-1.2.6.jar -verbose"
>
> You should also check if it's is working as expected, as I already said,
> does not go directly testing complex solutions on complex things like SCA.
> At first, build a simple, but equivalent scenario, and test it. For
> example,
> a simple android app project that uses an java library project which access
> annotations on classes placed on the android project. Like our android
> calculator, it's an android app project (calculator-android) which uses
> java
> library projects (sca modules), and these libraries checks for annotations
> on classes located at the android app project (CalculatorService.java,
> AddService.java, etc). When you get it working on the simpler scenario,
> then
> you are ready to test it on the complexer sceneario (calculator-android).
>
> Please, if you get the retrotranslator working in the simpler scenario,
> send
> us a patch with it. You can create a JIRA and attach it. If you need any
> help, just ask ; )
>
> "code that checks for @Remotable you force to true, otherwise force to
> false."
>
> Sorry for the not-well-detailed info here. I meant you to do:
>
> Search in every sca code for the usage of Class.isAnnotationPresent or
> getAnnotations or getAnnotation methods. If it checks for a the @Remotable
> annotations force it to true, for example:
>
> Annotation isRemotable = class.isAnnotationPresent(Remotable.class); =>
> Annotation isRemotable = true;
>
> otherwise, which means, when it's not checking for the @Remotable
> annnotation, force to false. For example:
>
> Annotation isReference = class.isAnnotationPresent(Reference.class); =>
> Annotation isReference = false;
>
> [1] - http://cwiki.apache.org/confluence/display/TUSCANYWIKI/2Jun2008
>
> Kind Regards,
> Adriano Crestani
>
> On Mon, Jun 2, 2008 at 4:19 PM, Oscar Castaneda <
> [EMAIL PROTECTED]> wrote:
>
> > Hi Adriano,
> >
> > I continued testing retrotranslator. Here's what I've done up to now.
> >
> > 1. Downloaded the modified code from [1].
> >
> > 2. Downloaded SCA modules from [2] and installed as shown below:
> >
> > svn checkout --revision 643746
> > https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules
> >
> > cd modules
> >
> > mvn clean install -Dtest=no
> > mvn -Peclipse eclipse:eclipse -Dtest=no
> >
> >  3. C

Re: [jira] Updated: (TUSCANY-2357) CORBA objects invocation mechanism

[Wojtek Janiszewski]

Hi,
I'm starting to worry that following patch will be orphaned :). Could 
anyone take a look?

Thanks,
Wojtek

Wojtek Janiszewski (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wojtek Janiszewski updated TUSCANY-2357:


Attachment: add-license-headers.patch.tar.gz

Thanks for reminding. Here's a patch which adds headers to all java and idl 
files.
Wojtek


CORBA objects invocation mechanism
--

Key: TUSCANY-2357
URL: https://issues.apache.org/jira/browse/TUSCANY-2357
Project: Tuscany
 Issue Type: New Feature
   Reporter: Wojtek Janiszewski
Attachments: add-license-headers.patch.tar.gz, 
corba-operation-invoker.patch.tar.gz


Implementation of generic mechanism for remote operation invocation: passing CORBA structures, sequences, primitives as arguments, retrieving return values (also structs, seq, prims.). There is no exception handling yet. 
It's not connected to CORBA binding extension yet - it won't be hard, and I think it's now more important  to complete this generic mechanism.

Some tests are provided - you need to have tnameserv in your PATH to run tests 
correctly!

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602242#action_12602242
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

I had installed and started tsucany-sca-installer.jar first, so I had all 
Tuscany bundles and 3rd party jars installed before starting your bundles. I 
was expecting that your launch configuration using the installer would also 
result in the same bundles in Equinox. But yes, I am not using Eclipse, so it 
could be an Eclipse issue. Could you list the bundles in Equinox when using the 
installer, and check that all the 3rd party bundles are being installed? Also 
are all the Tuscany module bundles installed, and in RESOLVED state? The 
WorkScheduler is in the core module, so do you have a bundle with symbolic name 
"org.apache.tuscany.sca.core" installed and resolved? Obviously host-embedded 
was installed and resolved since the classes from this module are on your stack 
trace. If all the other bundles are present and resolved, but ServiceDiscovery 
is not finding the classes, there may some additional logic required in the 
Tuscany activator when running the bundles under Eclipse. 

-Rajini

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
remove "incubating" at some point and as its not clear if the next release
would be 2.0 or something else so i wondered if we should also remove the
2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or the
timeframe for doing the change? I'd like to do it nowish so we have some
time to discover any problems before the next release.

   ...ant

[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy updated TUSCANY-2371:
-

Attachment: TUSCANY-2371.patch

TUSCANY-2371.patch: Adds tests for standard types

Notes:
1.  Tests related to java.lang.Object are not added since it is resulting in 
"java.lang.RuntimeException: no data binding for null".
2.  Tests related to javax.xml.transform.Source are not added since it is 
resulting in "java.lang.RuntimeException: no data binding for 
javax.xml.transform.Source".
3. Tests related to the following are marked @Ignore since the tests are 
failing.
binding.sca: URI array, Image array, DataHandler, DataHandler array
binding.ws: QName array, URI, URI array, Image, Image array, DataHandler, 
DataHandler array

> Databinding tests for StandardTypes, array of StandardTypes
> ---
>
> Key: TUSCANY-2371
> URL: https://issues.apache.org/jira/browse/TUSCANY-2371
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
>Affects Versions: Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2371.patch
>
>
> Databinding itests for StandardTypes and array of StandardTypes.  Local and 
> remotable service.  See [1].
> JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes:
> java.lang.String
> java.math.BigInteger
> java.math.BigDecimal
> java.util.Calendar
> java.util.Date
> javax.xml.namespace.QName
> java.net.URI
> javax.xml.datatype.XMLGregorianCalendar
> javax.xml.datatype.Duration
> java.lang.Object
> java.awt.Image
> javax.activation.DataHandler
> javax.xml.transform.Source
> java.util.UUID
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vamsavardhana Reddy updated TUSCANY-2371:
-

Description: 
Databinding itests for StandardTypes and array of StandardTypes.  Local and 
remotable service.  See [1].

JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes:
java.lang.String
java.math.BigInteger
java.math.BigDecimal
java.util.Calendar
java.util.Date
javax.xml.namespace.QName
java.net.URI
javax.xml.datatype.XMLGregorianCalendar
javax.xml.datatype.Duration
java.lang.Object
java.awt.Image
javax.activation.DataHandler
javax.xml.transform.Source
java.util.UUID


[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

  was:
Databinding itests for StandardTypes and array of StandardTypes.  Local and 
remotable service.  See [1]

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

   Assignee: Vamsavardhana Reddy

> Databinding tests for StandardTypes, array of StandardTypes
> ---
>
> Key: TUSCANY-2371
> URL: https://issues.apache.org/jira/browse/TUSCANY-2371
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Integration Tests
>Affects Versions: Java-SCA-Next
>Reporter: Vamsavardhana Reddy
>Assignee: Vamsavardhana Reddy
> Fix For: Java-SCA-Next
>
>
> Databinding itests for StandardTypes and array of StandardTypes.  Local and 
> remotable service.  See [1].
> JAXB Spec v2.1 - Sec 8.5.2Java Standard Classes:
> java.lang.String
> java.math.BigInteger
> java.math.BigDecimal
> java.util.Calendar
> java.util.Date
> javax.xml.namespace.QName
> java.net.URI
> javax.xml.datatype.XMLGregorianCalendar
> javax.xml.datatype.Duration
> java.lang.Object
> java.awt.Image
> javax.activation.DataHandler
> javax.xml.transform.Source
> java.util.UUID
> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2371) Databinding tests for StandardTypes, array of StandardTypes

[Vamsavardhana Reddy (JIRA)]

Databinding tests for StandardTypes, array of StandardTypes
---

 Key: TUSCANY-2371
 URL: https://issues.apache.org/jira/browse/TUSCANY-2371
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-Next
Reporter: Vamsavardhana Reddy
 Fix For: Java-SCA-Next


Databinding itests for StandardTypes and array of StandardTypes.  Local and 
remotable service.  See [1]

[1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Databinding+Scope

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TUSCANY-2370) sample-feed-aggregator-webapp gets 404 error on the feed urls

[ant elder (JIRA)]

sample-feed-aggregator-webapp gets 404 error on the feed urls
-

 Key: TUSCANY-2370
 URL: https://issues.apache.org/jira/browse/TUSCANY-2370
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


The sample-feed-aggregator-webapp says: To read the aggregated feeds, point 
your Web browser to the following addresses:

http://localhost:8080/sample-feed-aggregator-webapp/atomAggregator
http://localhost:8080/sample-feed-aggregator-webapp/atomAggregator/atomsvc (for 
the Atom service document)
http://localhost:8080/sample-feed-aggregator-webapp/rssAggregator

but all three URLs give a 404 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JMS Client

[Nishant Joshi]

Thanks Ant,
I have composed client for WS Here is the snippet of the client

-

public class HelloWorldClientImpl {

@Reference
protected HelloWorldService serviceA;

public String sayHello(String name) {
 System.out.println("HelloWorldClientImpl.serviceA = "+serviceA);
return serviceA.sayHello(name);
}

}
-
@Remotable
public interface HelloWorldService {
String sayHello(String name);
}

-
public class JMSClient {
 public static void main(String[] args) throws NodeException  {
  SCANode node = SCANodeFactory.createNodeWithComposite("client.composite");
  HelloWorldClientImpl client =
node.getDomain().getService(HelloWorldClientImpl.class, "HelloWorldClient");

  System.out.println(client.sayHello("World"));
 }

}

-

http://www.osoa.org/xmlns/sca/1.0";
   name="RPCComposite">











   




-
jndi.properties

# START SNIPPET: jndi

java.naming.factory.initial =
com.ibm.websphere.naming.WsnInitialContextFactory

# use the following property to configure the default connector
java.naming.provider.url = vm://localhost?broker.persistent=false

# use the following property to specify the JNDI name the connection factory
# should appear as.
#connectionFactoryNames = connectionFactory, queueConnectionFactory,
topicConnectionFactry
connectionFactoryNames = ConnectionFactory

# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
# queue.RequestQueue = RequestQueue
# queue.ResponseQueue = ResponseQueue
queue.HelloWorldService = HelloWorldService

# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
#topic.MyTopic = example.MyTopic

# END SNIPPET: jndi


Here Service is deployed successfuly, i can test with hello.jspIt was
working fine in WS.
Now when i run above code I m getting "HelloWorldClientImpl.serviceA = null"
and gettign NPE
I m using "HelloWorldService" for both Request and Response queue...

any idea ?

Thanks
Nishant Joshi

[jira] Created: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy

[ant elder (JIRA)]

sample-calculator-ws-webapp fails to deploy
---

 Key: TUSCANY-2369
 URL: https://issues.apache.org/jira/browse/TUSCANY-2369
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


sample-calculator-ws-webapp fails to deploy on Tomcat with the following:

org.osoa.sca.ServiceRuntimeException: 
java.lang.reflect.InvocationTargetException
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83)
at 
org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218)
at 
org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
at 
org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4356)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829)
at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
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.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258)
... 30 more
Caused by: java.lang.NoSuchMethodError: 
org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class;
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383)
at 
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:159)
at 
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:68)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70)
at 
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47)
at 
or

Re: itest/validation problem

[Ramkumar R]

Hi Ant,
This testcase fails due to an issue that we faced while applying the patch.
FYI... This issue is also discussed in the below thread.

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200806.mbox/[EMAIL 
PROTECTED]

Hope to get this resolved soon.


On 6/4/08, ant elder <[EMAIL PROTECTED]> wrote:
>
> I'm getting a test fail in itest/validation with the failed test:
> testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this
> work or fail for anyone else?
>
>   ...ant
>



-- 
Thanks & Regards,
Ramkumar Ramalingam

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602221#action_12602221
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi all,
thanks for your quick response. 

No, we do not use any security. To check I just added 2 lines of code to the 
BundleActivator:
   String prop = System.getProperty("java.security.manager");
   SecurityManager manager = System.getSecurityManager();
Both prop and manager are null.

I also added -clean to the launch. No change there. I still get the 
NullPointerException.

Yes, if you see the output
"Starting ... test.composite ready !!! 
did something"
the SCADomain was created and a method on the Test service was executed.


Rajini, did you install and start only the bundles that I used in my launch 
files or did you use more/less bundles or even all Tuscany and Tuscany 3rd 
party bundles?
Could this be some eclipse issue, as you said you are not using eclipse.

Bye,
Daniel

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[Simon Laws]

On Wed, Jun 4, 2008 at 6:46 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
>> Please review and vote on the release artifacts for the Tuscany SCA for
>> Java
>> 1.2.1 maintenance release.
>>
>> The artifacts are available for review at:
>> http://people.apache.org/~antelder/tuscany/1.2.1-RC1/
>> 
>>
>> This includes the signed binary and source distributions, Maven staging
>> repository, and eclipse update site.
>>
>> The SVN tag for the release is:
>> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
>>
>> The _only_ code change in this over the 1.2 release is in r657526 [1], all
>> other changes are just version updates and doc changes for the release.
>>
>> +1 to release from me.
>>
>>   ...ant
>>
>> [1]
>>
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>>  PROTECTED]
>>
>>  Folks,
>
> I am at an SCA spec F2F meeting this week and I will not have the time to
> review this RC - apologies in advance.
>
> I'm in favour of doing the update release.
>
> Yours,  Mike.
>

Hi

I ran a few samples, Rat looks good, versions/dates on READMEs etc. look
good.

+1

Simon

itest/validation problem

[ant elder]

I'm getting a test fail in itest/validation with the failed test:
testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this
work or fail for anyone else?

   ...ant

Re: svn commit: r663002 - in /incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources: tuscany-sca-data-helper.xsd tuscany-sca-implementation-das.xsd tuscany-sca-implementation-data-xml.xsd

[ant elder]

I'm getting a build failure in modules/assembly-xml after this with the
error below, does anyone else see that? Commenting out the includes for
implementation-das and data-xml gets it going again.

testReadBinding(org.apache.tuscany.sca.assembly.xml.ReadDocumentTestCase)
Time elapsed: 0.032 sec  <<< ERROR!
java.lang.IllegalStateException: org.xml.sax.SAXParseException:
cos-nonambig: WC["http://tuscany.apache.org/xmlns/sca/1.
0"] and "http://tuscany.apache.org/xmlns/sca/1.0":ConnectionInfo (or
elements from their substitution group) violate "Un
ique Particle Attribution". During validation against this schema, ambiguity
would be created for those two particles.
at
org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory.initializeSchemas(DefaultValid
atingXMLInputFactory.java:135)

   ...ant

On Wed, Jun 4, 2008 at 7:27 AM, <[EMAIL PROTECTED]> wrote:

> Author: lresende
> Date: Tue Jun  3 23:27:11 2008
> New Revision: 663002
>
> URL: http://svn.apache.org/viewvc?rev=663002&view=rev
> Log:
> Schema for implementation.das and implementation.data
>
> Added:
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>   (with props)
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
>   (with props)
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-data-xml.xsd
>   (with props)
> Modified:
>
>  
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca.xsd
>
> Added:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd?rev=663002&view=auto
>
> ==
> ---
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> (added)
> +++
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
> Tue Jun  3 23:27:11 2008
> @@ -0,0 +1,44 @@
> +
> +
> +http://www.w3.org/2001/XMLSchema";
> +targetNamespace="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +elementFormDefault="qualified">
> +
> +
> +   
> +   
> +   
> +   
> +   
> +
> +
> +
> +   
> ++   name="ConnectionProperties"
> type="data:ConnectionProperties" />
> +   
> +   
> ++   default="true" />
> +
> +
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:eol-style = native
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:keywords = Rev Date
>
> Propchange:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-data-helper.xsd
>
> --
>svn:mime-type = text/xml
>
> Added:
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> URL:
> http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd?rev=663002&view=auto
>
> ==
> ---
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> (added)
> +++
> incubator/tuscany/java/sca/modules/assembly-xsd/src/main/resources/tuscany-sca-implementation-das.xsd
> Tue Jun  3 23:27:11 2008
> @@ -0,0 +1,46 @@
> +
> +
> +http://www.w3.org/2001/XMLSchema";
> +targetNamespace="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:sca="http://www.osoa.org/xmlns/sca/1.0";
> +xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
> +xmlns:data="http://data.tuscany.apache.org/xmlns/sca/1.0";
> +elementFormDefault="qualified">
> +
> +http://www.osoa.org/xmlns/sca/1.0";
> schemaLocation="sca-core.xsd"/>
> +http://data.tuscany.apache.org/xmlns/sca/1.0";
> schemaLocation="tuscany-sca-data-helper.xsd"/>
> +
> +
> +
> +
> +
> +
> +
> + processContents="lax"
> +   minOccurs="0" maxOccurs="unbounded"/>
> + name="ConnectionInfo"
> +type="data:ConnectionInfo"/>
> +
> +
> + use="required"/>
> +   

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602211#action_12602211
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Dan,

I dont know whether Daniel runs with security on, so I will wait for his 
response. It could be an OSGi classloading issue rather than a security issue.

Daniel,

Is there a possibility that the bundles from the previous run are still in the 
cache? Could you run with "-clean" option to Equinox?

And to answer the question in your last note - yes, the code creating SCADomain 
should work in OSGi.

- Rajini

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: JMS Client

[ant elder]

On Wed, Jun 4, 2008 at 6:08 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

>  Hi All,
> I m new to JMS, I have a question regarding a JMS client means How can i
> access Tuscnay JMS service remotely.
> I have refered sample from
>
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/helloworld-jms-webapp/
> and
> deployed it on WS with instruction given on README file. It was working
> fine
> and i can access a client jsp given with the sample.
> so in binding.ws i can pass a service url and access the service from my
> client which was remote means on diff machine.
> So how can it be possible with binding.jms ?
> Ex. I have one Sample service which was deployed on machine X and port 8080
> so my service address is like
> http://X:8080/MyService/MyComponent 
> so this is the url where wsdl was generating.
>
> now from client side (which was on machine Y) scdl i have following kinda
> structure...
>
> 
>  
>  
>  
>
>  
>  
>  http://X:8080/MyService/MyComponent<
> http://x:8080/MyService/MyComponent>"
> />
>  
>
>
> so I want same kinda sample for binding.jms
> has anybody try this ?
>
>
> --
> Thanks
> Nishant Joshi
>

Yes you can do this by telling the client where the remote JMS broker is.
You do that with the jndiURL and initialContextFactory attributes of the JMS
binding. There's an example of this in an testcase at
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/jms/src/main/resources/external/client.composite.
That test uses ActiveMQ, I've not actually tried this on WebShpere but I
think by default the JNDI port is 2809 and the initialContextFactory class
is com.ibm.websphere.naming.WsnInitialContextFactory.


   ...ant