Re: [VOTE] Release Tuscany SCA 2.0-Beta3 RC2

[Florian Moga]

Things are looking good to me. Here's my +1.

Sorry for the late response.

Florian

On Wed, Aug 3, 2011 at 1:38 AM, ant elder  wrote:

> Anyone have time for a release vote?
>
>   ...ant
>
> On Thu, Jul 28, 2011 at 9:29 PM, ant elder  wrote:
> > Please review and vote on the 2.0-Beta3 RC2  release artifacts.
> >
> > The artifacts are available at:
> >
> > http://people.apache.org/~antelder/tuscany/2.0-Beta3-RC2/
> >
> > The SVN tag for the release is:
> >
> >
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta3-RC2/
> >
> > TIA,
> >
> >  ...ant
> >
>

getting TooManyReferenceTargets when overriding binding uri of promoted reference

[Greg Dritschler]

I have the following composites:

Composite A has a component reference myService with binding.sca uri="X".
 The reference is promoted.
Composite B has a component that uses A as its implementation.  It redefines
reference myService and specifies binding.sca uri="Y".

I get the error
[ASM50022] Too many targets on reference: myService

I've found that EndpointReferenceBuilderImpl.pushDownEndpointReferences() is
adding the endpoint references from the outer component reference to the
inner component reference.  This doesn't seem like it applies in this case.
 My understanding is that bindings configured on the outer component
reference override bindings that would otherwise have been inherited from
the promoted reference.  pushDownEndpointReferences() was introduced in
revision 833132 which says:

"Fix motivated by ASM-5023. Update code to reflect the OASIS treatment
of promoted references. Endpoint references are now copied down to the
promoted component reference and the multiplicity validation is performed
there."

ASM-5023 uses reference target.  If I were using reference target instead of
binding uri, then I would agree I have an error (assuming multiplicity 0..n
or 1..n), since reference targets are additive.  But I'm not using reference
target.

Greg

[jira] [Commented] (TUSCANY-3911) ServiceReference type not marshalled to XML correctly

[Simon Nash (JIRA)]

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

Simon Nash commented on TUSCANY-3911:
-

JAXB provides the @XmlJavaTypeAdapter annotation to do custom marshalling and 
unmarshalling. The marshalling side is easy (for example, an adapter could 
convert a ServiceReferenceImpl to a String containg the XML representation), 
but it might be harder to persuade the JAXB unmarshaller to do the right thing 
with the XML element that it reads from the wire. There's a example in [1] that 
may provide some useful pointers, though it seems like quite a complex approach.

[1] http://stackoverflow.com/questions/512337/custom-serialization-in-jaxb

> ServiceReference type not marshalled to XML correctly
> -
>
> Key: TUSCANY-3911
> URL: https://issues.apache.org/jira/browse/TUSCANY-3911
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.0
>Reporter: Scott Kurz
>Priority: Minor
> Attachments: 3911.recreate.patch
>
>
> When using a binding with an XML wireformat, the ServiceReference type is 
> going to be treated as a JAXB by the Tuscany databinding framework, and is 
> not going to get serialized correctly.
> E.g. see this intf from the itest/service-reference module:
> @Remotable
> public interface DComponent {
> String foo(ServiceReference aReference); 
> It works fine when we use a binding.sca config that does Java serialization, 
> but if we try to use an XML wireformat we get the JAXB error:
>   org.oasisopen.sca.ServiceReference is an interface, and JAXB can't handle 
> interfaces.
> I'm guessing the solution is to use JAXBs customizations/annotations to tell 
> JAXB how to handle our ServiceReference impl.But I'd have to look into 
> that.
> I guess there's also the idea of defining a new databinding but that seems 
> odd.
> Will attach a recreate patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: should ServiceReference be used as a parameter on remotable interface method?

[Simon Nash]

Scott Kurz wrote:
Thanks for finding that Simon.   I think when I last came across that I 
parsed it as assuming a local, PBR interface.
But...I don't have any support for that and the surrounding text 
specifically mentions serialization, so I think you've captured the intent.



In restrospect, it would have been good to make this more explicit in the
spec, with conformance statements and test assertions to enforce support.
However, I'm sure that this was the intention of the spec group, based on
a discussion that we had about possibly removing ServiceReference from
the spec and instead making reference proxies serializable so that they
could be passed remotely, which wasn't accepted.

Well, it still seems ugly to me... if something in our Tuscany impl 
changes, then your WSDL-mapped interface is now different?   It seems 
like we're talking about a class of service:   remotable in the sense of 
cross-JVM, but never invocable outside of the Tuscany runtime, not very 
SOA-ish.I'm not saying it's useless... it's just kind of a new 
concept thrown in from my perspective.



I believe the generated WSDL uses xs:anyType, so this wouldn't change if
the Tuscany XML serialization format changed.

As you say, the current approach isn't perfect because it doesn't work
across different vendor implementations.  This would require a spec change
to mandate a standardized XML format.  At least the Tuscany implementation
provides a "straw man" to demonstrate that this is possible.


Anyway, I opened
https://issues.apache.org/jira/browse/TUSCANY-3911
as it doesn't work currently, so when someone gets a chance we can 
resume this discussion.



Thanks.  I'll add some comments there.

  Simon


Scott


On Thu, Jul 28, 2011 at 6:12 PM, Simon Nash > wrote:


Scott Kurz wrote:

Simon,

I didn't find the spec requirement to support this, do you happen to
see it?BTW, as I mentioned in TUSCANY-3894, I did leave the
current behavior so that it preferes Java serialization over the
local
binding-sca-runtime path.

Ths,
Scott


 >From section 7.2.5 in the latest javacaa spec version that I have:

 ServiceReference objects can also be passed as parameters on service
 invocations, enabling the responsibility for making the callback to be
 delegated to another service.

Although this is mentioned in the context of callbacks, the statement
in the first part of the sentence isn't limited or qualified as only
applying to this particular usage.

I don't think it matters whether Tuscany uses Java serialization or
XML serialization when passing service references, because Tuscany's
ServiceReferenceImpl supports both of these with identical semantics.

 Simon

Re: should ServiceReference be used as a parameter on remotable interface method?

[Simon Nash]

Giorgio Zoppi wrote:

2011/8/3 Scott Kurz :

Thanks for finding that Simon.   I think when I last came across that I
parsed it as assuming a local, PBR interface.
But...I don't have any support for that and the surrounding text
specifically mentions serialization, so I think you've captured the intent.

Well, it still seems ugly to me... if something in our Tuscany impl changes,
then your WSDL-mapped interface is now different?   It seems like we're
talking about a class of service:   remotable in the sense of cross-JVM, but
never invocable outside of the Tuscany runtime, not very SOA-ish.I'm not
saying it's useless... it's just kind of a new concept thrown in from my
perspective.

An other naive way is using the MTOM support and serialize in Java.
However if you want something
really SOAish, forget about Java serialization.What about if you have
a C#/Python client?
Using for example Apache Thrift will provide better interoperability
if you want  binary serialization.



I don't want binary serialization; I think XML serialization is much
better for all cases other than Java->Java.  That's why we have support
for XML serialization in ServiceReferenceImpl :-)

  Simon

Re: [GSoC] Adding jmx capabilities to tuscany

[Amindri Udugala]

Hi,

Thanks for the response

>
> I'm trying to understand the project setting for the code you use to test
> the JMX integration. Do you have your own maven module or do you reuse an
> existing sample module?
>
> Are you trying to run
> samples/running-tuscany/jse/src/main/java/launcher/LaunchCalculatorContributionto
>  see if the JMX is activated?
>

   Yes I'm using
samples/running-tuscany/jse/src/main/java/launcher/LaunchCalculatorContribution
to test JMX integration.

>
> If so, that pom has the following dependency:
>
> 
> org.apache.tuscany.sca
> tuscany-base-runtime
> 2.0-SNAPSHOT
> 
>
> If you have the jmx modules added to the base-runtime pom, they should be
> picked up. You can run "mvn dependency:tree" under samples/running-tuscany/jse
> to confirm.
>

 I added the tuscany-base-runtime dependency to
samples/running-tuscany/pom.xml. Built the project (but stopped half way
through due to the permgen error)
Then executed mvn dependency:tree, and this is the result I get

[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ jse ---
[INFO] org.apache.tuscany.sca.samples:jse:jar:2.0-SNAPSHOT
[INFO] +-
org.apache.tuscany.sca:tuscany-base-runtime:jar:2.0-SNAPSHOT:compile
[INFO] |  +- cglib:cglib:jar:2.2:compile
[INFO] |  +- org.apache.ws.commons.schema:XmlSchema:jar:1.4.3:compile
[INFO] |  +- asm:asm:jar:3.1:compile
[INFO] |  \- wsdl4j:wsdl4j:jar:1.6.2:compile
[INFO] \- junit:junit:jar:4.8.1:test

seems like the two jmx modules are not picked  up. (I have added the two jmx
modules to the modules/base-runtime/pom.xml)


>
> Back to the build issue, can you do the following:
>
> 1) Send us the error message
> 2) Use "mvn clean install -fae -Dmaven.test.skip=true" for the purpose of
> compilation and archive.
>
>   I still get the permgen error even if I ignore errors using mvn clean
install -fae. Following is  end of the log.

[INFO]

[INFO] Building Apache Tuscany SCA iTest WS Contribution WSDL First
2.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:2.4:clean (default-clean) @
itest-ws-contribution-wsdl-first ---
[INFO] Deleting
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target
[INFO]
[INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-plugin-versions) @
itest-ws-contribution-wsdl-first ---
[INFO] The requirePluginVersions rule is currently not compatible with
Maven3.
[INFO]
[INFO] --- build-helper-maven-plugin:1.0:add-test-source (add-source) @
itest-ws-contribution-wsdl-first ---
[INFO] Test Source directory:
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target/jaxws-source
added.
[INFO]
[INFO] --- maven-remote-resources-plugin:1.1:process (default) @
itest-ws-contribution-wsdl-first ---
[INFO]
[INFO] --- maven-resources-plugin:2.4.2:resources (default-resources) @
itest-ws-contribution-wsdl-first ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 7 resources
[INFO] Copying 0 resource
[INFO] Copying 3 resources
[INFO]
[INFO] --- jaxws-maven-plugin:1.10:wsimport (wsimport2) @
itest-ws-contribution-wsdl-first ---
[INFO] Processing:
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target/classes/helloworld-external-service.wsdl
[INFO] jaxws:wsimport args: [-s,
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target/jaxws-source,
-d,
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target/classes,
-verbose, -p,
org.apache.tuscany.sca.binding.ws.jaxws.external.service.iface, -target,
2.1, -Xnocompile,
/home/amindri/tuscany/trunk/testing/itest/ws/contribution-wsdl-first/target/classes/helloworld-external-service.wsdl]
---
constituent[0]: file:/opt/maven/lib/sisu-inject-plexus-1.4.3.1.jar
constituent[1]: file:/opt/maven/lib/wagon-http-shared-1.0-beta-7.jar
constituent[2]: file:/opt/maven/lib/maven-artifact-3.0.2.jar
constituent[3]: file:/opt/maven/lib/plexus-utils-2.0.4.jar
constituent[4]: file:/opt/maven/lib/maven-repository-metadata-3.0.2.jar
constituent[5]: file:/opt/maven/lib/maven-plugin-api-3.0.2.jar
constituent[6]: file:/opt/maven/lib/plexus-cipher-1.4.jar
constituent[7]: file:/opt/maven/lib/maven-settings-builder-3.0.2.jar
constituent[8]: file:/opt/maven/lib/commons-cli-1.2.jar
constituent[9]: file:/opt/maven/lib/aether-connector-wagon-1.9.jar
constituent[10]: file:/opt/maven/lib/aether-api-1.9.jar
constituent[11]: file:/opt/maven/lib/plexus-component-annotations-1.5.5.jar
constituent[12]: file:/opt/maven/lib/nekohtml-1.9.6.2.jar
constituent[13]: file:/opt/maven/lib/sisu-inject-bean-1.4.3.1.jar
constituent[14]: file:/opt/maven/lib/wagon-file-1.0-beta-7.jar
constituent[15]: file:/opt/maven/lib/plexus-sec-dispatcher-1.3.jar
constituent[16]: file:/opt/maven/lib/wagon-http-lightweight-1.0-beta-7.jar
constituent[

Re: should ServiceReference be used as a parameter on remotable interface method?

[Giorgio Zoppi]

2011/8/3 Scott Kurz :
> Thanks for finding that Simon.   I think when I last came across that I
> parsed it as assuming a local, PBR interface.
> But...I don't have any support for that and the surrounding text
> specifically mentions serialization, so I think you've captured the intent.
>
> Well, it still seems ugly to me... if something in our Tuscany impl changes,
> then your WSDL-mapped interface is now different?   It seems like we're
> talking about a class of service:   remotable in the sense of cross-JVM, but
> never invocable outside of the Tuscany runtime, not very SOA-ish.    I'm not
> saying it's useless... it's just kind of a new concept thrown in from my
> perspective.
An other naive way is using the MTOM support and serialize in Java.
However if you want something
really SOAish, forget about Java serialization.What about if you have
a C#/Python client?
Using for example Apache Thrift will provide better interoperability
if you want  binary serialization.


-- 
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".

Re: anyway I can contribute

[Simon Laws]

On Sat, Jul 30, 2011 at 2:27 AM, Monosij Dutta-Roy
 wrote:
> hi Ant -
> Thanks. I am still a beginner with Tuscany so as I finish this application I
> am working on I think I will have a better understanding of the framework
> and can contribute to the dev efforts.
> Unless you think I need to help work on the framework to write docs on it
> and maintain website?
> Maybe I can work through the tutorials and make sure they all work and write
> the docs for them - and overall docs?
> I have not contributed to an open source effort before - so do not want to
> hamper your efforts either.
> Will wait to get an understanding from you.
> Thanks.
> monosij
> NB: Also on the note of build environments - Maven is not my forte, however
> I have begun to use Gradle which seems to be a much better build environment
> based on Groovy. Just wanted to put it out there in case you have not
> considered it.
> http://www.gradle.org/get-excited.html
>
> On Fri, Jul 29, 2011 at 5:42 AM, ant elder  wrote:
>>
>> There are plenty of things that need doing so i'm sure we can find you
>> things to help with, what those are really comes down to what you're
>> interested in. One place to look is at one of the many open JIRA, for
>> example something in these lists:
>>
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+TUSCANY+AND+fixVersion+%3D+%22Java-SCA-2.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide
>>
>>
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+TUSCANY+AND+fixVersion+%3D+%22Java-SCA-2.x%22+AND+status+%3D+Open+ORDER+BY+priority+DESC&mode=hide
>>
>> Some of the JIRA in those wont be appropriate or are no longer valid
>> but if you tell us a few from there which sound interesting to you it
>> would give us some idea of the type of things that interest you?
>>
>> Would you like to develop some new function from scratch? There are
>> still a couple of things in the SCA specs which we don't yet implement
>> which you could help with.
>>
>> Or is there something that you've used in Tuscany that has seemed a
>> bit less that perfect, if you tell us what those are we could give you
>> some ideas about how you could improve it.
>>
>> Or if you know Maven there are some issues with the build that you
>> could help with.
>>
>> The website and doc could really do with a lot of work to catch up
>> with Tuscany 2.x and OASIS SCA so if you're interested in that aspect
>> then there would be plenty to keep you busy.
>>
>>   ...ant
>>
>> On Thu, Jul 28, 2011 at 6:31 PM, Monosij Dutta-Roy
>>  wrote:
>> > hello all -
>> > I wanted to see if there was I can help contribute towards the efforts
>> > of
>> > the development of Tuscany.
>> > My background and strengths:
>> > 1. Experience with several programming languages - Java, C++, Python and
>> > OO
>> > methods.
>> > 2. DBMS design and development.
>> > 3. Web-app implementations is Struts and home-grown frameworks.
>> > 4. Some development is Tuscany - with much help from the user community.
>> > 5. Principled organizer, re-factoring approaches.
>> > 6. 15+ years in design / development.
>> > I am still learning the Tuscany framework and looking to get good at it
>> > -
>> > especially interested in integration, deployment aspects with other
>> > frameworks.
>> > In my discussions in the user community before we briefly touched upon
>> > restarting the Wiki but don't know where that stands now. Am open to
>> > whatever you think would be best to start with.
>> > Am available to discuss on phone with you as well as suits best.
>> > Thanks for your consideration.
>> > Regards.
>> > monosij
>> >
>> >
>> >
>> >
>
>

Hi Monosij

Sounds like you're taking the right approach to me. Work through the
material there is and see how you get on. We do need work on samples
and docs for the 2.x code that we've been working on. You'll have a
better understanding of what's required once you've had a chance to
try using the code. All suggestions are most welcome.

Regards

Simon


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: should ServiceReference be used as a parameter on remotable interface method?

[Scott Kurz]

Thanks for finding that Simon.   I think when I last came across that I
parsed it as assuming a local, PBR interface.
But...I don't have any support for that and the surrounding text
specifically mentions serialization, so I think you've captured the intent.

Well, it still seems ugly to me... if something in our Tuscany impl changes,
then your WSDL-mapped interface is now different?   It seems like we're
talking about a class of service:   remotable in the sense of cross-JVM, but
never invocable outside of the Tuscany runtime, not very SOA-ish.I'm not
saying it's useless... it's just kind of a new concept thrown in from my
perspective.

Anyway, I opened
https://issues.apache.org/jira/browse/TUSCANY-3911
as it doesn't work currently, so when someone gets a chance we can resume
this discussion.

Scott


On Thu, Jul 28, 2011 at 6:12 PM, Simon Nash  wrote:

> Scott Kurz wrote:
>
>> Simon,
>>
>> I didn't find the spec requirement to support this, do you happen to
>> see it?BTW, as I mentioned in TUSCANY-3894, I did leave the
>> current behavior so that it preferes Java serialization over the local
>> binding-sca-runtime path.
>>
>> Ths,
>> Scott
>>
>>
>>  From section 7.2.5 in the latest javacaa spec version that I have:
>
>  ServiceReference objects can also be passed as parameters on service
>  invocations, enabling the responsibility for making the callback to be
>  delegated to another service.
>
> Although this is mentioned in the context of callbacks, the statement
> in the first part of the sentence isn't limited or qualified as only
> applying to this particular usage.
>
> I don't think it matters whether Tuscany uses Java serialization or
> XML serialization when passing service references, because Tuscany's
> ServiceReferenceImpl supports both of these with identical semantics.
>
>  Simon
>
>

[jira] [Updated] (TUSCANY-3911) ServiceReference type not marshalled to XML correctly

[Scott Kurz (JIRA)]

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

Scott Kurz updated TUSCANY-3911:


Attachment: 3911.recreate.patch

Assuming you have my recent binding.sca changes (r1153291), simply apply this 
small tweak to binding-sca-runtime

> ServiceReference type not marshalled to XML correctly
> -
>
> Key: TUSCANY-3911
> URL: https://issues.apache.org/jira/browse/TUSCANY-3911
> Project: Tuscany
>  Issue Type: Bug
>  Components: SCA Java Runtime
>Affects Versions: Java-SCA-2.0
>Reporter: Scott Kurz
>Priority: Minor
> Attachments: 3911.recreate.patch
>
>
> When using a binding with an XML wireformat, the ServiceReference type is 
> going to be treated as a JAXB by the Tuscany databinding framework, and is 
> not going to get serialized correctly.
> E.g. see this intf from the itest/service-reference module:
> @Remotable
> public interface DComponent {
> String foo(ServiceReference aReference); 
> It works fine when we use a binding.sca config that does Java serialization, 
> but if we try to use an XML wireformat we get the JAXB error:
>   org.oasisopen.sca.ServiceReference is an interface, and JAXB can't handle 
> interfaces.
> I'm guessing the solution is to use JAXBs customizations/annotations to tell 
> JAXB how to handle our ServiceReference impl.But I'd have to look into 
> that.
> I guess there's also the idea of defining a new databinding but that seems 
> odd.
> Will attach a recreate patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TUSCANY-3911) ServiceReference type not marshalled to XML correctly

[Scott Kurz (JIRA)]

ServiceReference type not marshalled to XML correctly
-

 Key: TUSCANY-3911
 URL: https://issues.apache.org/jira/browse/TUSCANY-3911
 Project: Tuscany
  Issue Type: Bug
  Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0
Reporter: Scott Kurz
Priority: Minor


When using a binding with an XML wireformat, the ServiceReference type is going 
to be treated as a JAXB by the Tuscany databinding framework, and is not going 
to get serialized correctly.

E.g. see this intf from the itest/service-reference module:

@Remotable
public interface DComponent {
String foo(ServiceReference aReference); 

It works fine when we use a binding.sca config that does Java serialization, 
but if we try to use an XML wireformat we get the JAXB error:
  org.oasisopen.sca.ServiceReference is an interface, and JAXB can't handle 
interfaces.

I'm guessing the solution is to use JAXBs customizations/annotations to tell 
JAXB how to handle our ServiceReference impl.But I'd have to look into that.

I guess there's also the idea of defining a new databinding but that seems odd.

Will attach a recreate patch.







--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TUSCANY-3904) SCAClientFactory.getService() may use wrong binding when referencing a promoted service

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-3904:
---

Assignee: Simon Laws

> SCAClientFactory.getService() may use wrong binding when referencing a 
> promoted service
> ---
>
> Key: TUSCANY-3904
> URL: https://issues.apache.org/jira/browse/TUSCANY-3904
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-2.0
>Reporter: Greg Dritschler
>Assignee: Simon Laws
>Priority: Minor
> Attachments: TUSCANY-3904.patch
>
>
> SCAClientFactory.getService() doesn't work correctly when referencing a 
> promoted service.
> Let's say I have composite A with component C1
> 
> 
> 
> 
> 
> 
> and composite B with component C2
> 
> 
> 
> 
> 
> 
> 
> When I use SCAClientFactory.getService("C1/S1Promoted/myscabinding") to 
> obtain the service, the invocation uses binding.ws, not binding.sca.  This 
> doesn't sound correct to me.  It certainly seems wrong to ignore the explicit 
> binding name and pick something else.  But even I left out the binding name 
> and just asked for "C1/S1Promoted", I would expect binding.sca to be used 
> since that's the binding that's defined for that component service.
> RuntimeComponentImpl.getServiceReference(Class businessInterface, String 
> serviceName) checks for
> implementation.composite and then uses the component context of the promoted 
> component to create a self-reference.
> ComponentContextImpl.getEndpoint(ComponentService service, String 
> bindingName) searches for the endpoint in the promoted component's context.  
> It has a check for binding name, but if it can't find a match, logic added by 
> TUSCANY-3543 just picks the first endpoint.
> The logic in getServiceReference() to use the promoted component's context 
> doesn't seem to be necessary.  I deleted it and re-tested and got the desired 
> results (binding.sca was used).  I am attaching a patch.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [GSoC] Adding jmx capabilities to tuscany

[Raymond Feng]

Hi,

I'm trying to understand the project setting for the code you use to test the 
JMX integration. Do you have your own maven module or do you reuse an existing 
sample module? 

Are you trying to run 
samples/running-tuscany/jse/src/main/java/launcher/LaunchCalculatorContribution 
to see if the JMX is activated? 

If so, that pom has the following dependency:


org.apache.tuscany.sca
tuscany-base-runtime
2.0-SNAPSHOT


If you have the jmx modules added to the base-runtime pom, they should be 
picked up. You can run "mvn dependency:tree" under samples/running-tuscany/jse 
to confirm.

Back to the build issue, can you do the following:

1) Send us the error message
2) Use "mvn clean install -fae -Dmaven.test.skip=true" for the purpose of 
compilation and archive.

Thanks,
Raymond
 
Raymond Feng
rf...@apache.org
Apache Tuscany PMC member and committer: tuscany.apache.org
Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
Personal Web Site: www.enjoyjava.com


On Aug 3, 2011, at 7:03 AM, Amindri Udugala wrote:

> Hi Raymond,
> 
> I quite didn't understand what u asked for. Can you please explain what you 
> exactly meant.
> I'm running the LaunchCalculatorContribution class in the sample module to 
> bootstrap tuscany.
> 
> 
> 
> On 2 August 2011 23:16, Raymond Feng  wrote:
> Can you point out which sample from svn are you trying to pick up your 
> modules?
> 
> Thanks,
> Raymond
>  
> Raymond Feng
> rf...@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> 
> 
> On Aug 2, 2011, at 9:12 AM, Amindri Udugala wrote:
> 
>> Hi,
>> 
>> I tried that out but still could not resolve the memory issue, changed the 
>> surefire plugin in trunk/pom.xml as follows
>> 
>> -ea -Xmx1024m -Xms756m -XX:MaxPermSize=512m
>> 
>>  
>> I added dependencies to  features/all/pom.xml and 
>> modules/base-runtime/pom.xml and still the modules are not included to the 
>> class path. Is it because I was not able to build the project?
>> 
>> On 25 July 2011 19:24, Amindri Udugala  wrote:
>> Thanx Raymond I'll try that out.
>> 
>> 
>> On 26 July 2011 11:24, Raymond Feng  wrote:
>> Hi, Amindri.
>> 
>> Can you try to add your modules to features/all/pom.xml and 
>> modules/base-runtime/pom.xml? It seems that the sample uses base-runtime as 
>> the dependency to create the class path.
>> 
>> For the memory issue, can you try to change memory setting for the surefire 
>> plugin? It is configured in the pom.xml under the  element whose 
>> artifactid is maven-surefire-plugin.
>> 
>> Sent from my iPad
>> 
>> On Jul 24, 2011, at 8:11 PM, Amindri Udugala  
>> wrote:
>> 
>>> Hi,
>>>  Herewith I have listed down the artifacts that I have exposed to JMX 
>>> connection and the attributes of the artifacts I have exposed. Also I have 
>>> exposed some of the operations of these artifacts as well to the JMX 
>>> connection.  Please comment if I have missed anything out. Have attached 
>>> the latest patch with all the latest changes. 
>>> 
>>> With this I think I have done with most of my work, but the problem which 
>>> I'm facing is that I still couldn't get the jmx-activator module activated 
>>> when Tuscany is bootstrapped. I'm using LaunchCalculatorContribution in the 
>>> sample module to bootstrap tuscany. I found out that jmx-activator module 
>>> is not included in the classpath when I'm running the 
>>> LaunchCalculatorContribution. 
>>> 
>>> I guess the reason for this is, that I was never able to build the whole 
>>> trunk at once, due to lack of perm space. I executed MAVEN_OPTS="-Xmx1024m 
>>> -Xms512m -XX:MaxPermSize=384m" before building the trunk, but still the 
>>> problem remains.  
>>> 
>>> If I can get a solution for this problem, I'll be able to verify the 
>>> correctness of the code...
>>> Component 
>>> Attributes
>>> getComponents - Lists all runtime Components with following 
>>> attributes - Name, URI, AutoWire, Implementation 
>>> 
>>> Operations
>>> getComponent(String name) - Lists all the attributes of the 
>>> specified component- Name, URI, AutoWire, Implementation, ExtensionType,
>>>
>>> AttributeExtensions, Services, References, Properties, RequiredIntents, 
>>> PolicySets, Extensions
>>> setComponentURI(String currURI, String newURI) 
>>> setComponentName(String uri, String newName)
>>> setComponentAutoWire(String uri, boolean autoWire)
>>> setComponentUnresolved(String uri, boolean unresolved)
>>> 

[jira] [Closed] (TUSCANY-3893) Policy appliesTo not correctly specified in policy compliance tests

[Simon Laws (JIRA)]

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

Simon Laws closed TUSCANY-3893.
---

Resolution: Fixed

Correct contributions committed to the local Tuscany repo at revision: 1153516  


> Policy appliesTo not correctly specified in policy compliance tests
> ---
>
> Key: TUSCANY-3893
> URL: https://issues.apache.org/jira/browse/TUSCANY-3893
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-2.0-Beta2
>Reporter: Simon Laws
>Assignee: Simon Laws
> Fix For: Java-SCA-2.0
>
>
> In several of the policy compliance tests the appliesTo XPath expression 
> includes a note test describing an element without an explicit namespace. For 
> example, from POL_4020, 
> attachTo="//sca:reference[@name='reference1']/interface.wsdl">
>   
>
> Note. appliesTo="//binding.sca" rather than appliesTo="//sca:binding.sca"
> The XPath spec expects the namespace to be specified and maps the elements 
> without a namespace shortname to the null namespace. (see 
> http://www.w3.org/TR/xpath/#node-tests). We need to get OASIS to fix the 
> tests. The only one that appears to fail because of this in Tuscany is 4020 
> but others have the same problem so we need to look at why they don't fail 
> also. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (TUSCANY-3893) Policy appliesTo not correctly specified in policy compliance tests

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-3893:
---

Assignee: Simon Laws

> Policy appliesTo not correctly specified in policy compliance tests
> ---
>
> Key: TUSCANY-3893
> URL: https://issues.apache.org/jira/browse/TUSCANY-3893
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-2.0-Beta2
>Reporter: Simon Laws
>Assignee: Simon Laws
> Fix For: Java-SCA-2.0
>
>
> In several of the policy compliance tests the appliesTo XPath expression 
> includes a note test describing an element without an explicit namespace. For 
> example, from POL_4020, 
> attachTo="//sca:reference[@name='reference1']/interface.wsdl">
>   
>
> Note. appliesTo="//binding.sca" rather than appliesTo="//sca:binding.sca"
> The XPath spec expects the namespace to be specified and maps the elements 
> without a namespace shortname to the null namespace. (see 
> http://www.w3.org/TR/xpath/#node-tests). We need to get OASIS to fix the 
> tests. The only one that appears to fail because of this in Tuscany is 4020 
> but others have the same problem so we need to look at why they don't fail 
> also. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding

[Scott Kurz (JIRA)]

Ensure that JAX-WS wrapper generation occurs before databinding introspection 
to avoid need for @RequestWrapper, etc. to set databinding


 Key: TUSCANY-3910
 URL: https://issues.apache.org/jira/browse/TUSCANY-3910
 Project: Tuscany
  Issue Type: Improvement
  Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0
Reporter: Scott Kurz
Assignee: Scott Kurz


Say I have a wrapped-style WSDL interface which I want to map to Java intf:

Node greetDOM(Node name);

Our databinding introspection will correctly mark the input/output with 
DOMDataBinding.   The JAXWSJavaInterfaceProcessor will generate the wrappers 
since they are not already present from the Java perspective.

Then there is some more function in WrapperJavaInterfaceProcessor to "promote" 
the parm/returnVal databindings to the wrapper-level databindings. However, 
while in 1.x this always ran after the wrappers were generated, in 2.x the 
order isn't so determined because of the way we factored out the addition of 
the interface processors.

So the user has to ensure the JAX-WS annotations are present and that they 
specify the databinding (via the className), which is a pain to add manually if 
he doesn't have a tool to do it, e.g.:

@RequestWrapper(localName = "greetDOM", targetNamespace = 
"http://intf.privatecopy.itest/";, className = "org.w3c.dom.Node")
@ResponseWrapper(localName = "greetDOMResponse", targetNamespace = 
"http://intf.privatecopy.itest/";, className = "org.w3c.dom.Node")
Node greetDOM(Node name);

We seem to need an ordering so that the WrapperJavaInterfaceProcessor runs 
after JAXWSJavaInterfaceProcessor.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [GSoC] Adding jmx capabilities to tuscany

[Amindri Udugala]

Hi Raymond,

I quite didn't understand what u asked for. Can you please explain what you
exactly meant.
I'm running the LaunchCalculatorContribution class in the sample module to
bootstrap tuscany.



On 2 August 2011 23:16, Raymond Feng  wrote:

> Can you point out which sample from svn are you trying to pick up your
> modules?
>
> Thanks,
> Raymond
> *
> Raymond Feng
> rf...@apache.org
> Apache Tuscany PMC member and committer: tuscany.apache.org
> Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com
> Personal Web Site: www.enjoyjava.com
> *
>
> On Aug 2, 2011, at 9:12 AM, Amindri Udugala wrote:
>
> Hi,
>
> I tried that out but still could not resolve the memory issue, changed the
> surefire plugin in trunk/pom.xml as follows
> 
> -ea -Xmx1024m -Xms756m -XX:MaxPermSize=512m
> 
>
> I added dependencies to  features/all/pom.xml and
> modules/base-runtime/pom.xml and still the modules are not included to the
> class path. Is it because I was not able to build the project?
>
> On 25 July 2011 19:24, Amindri Udugala  wrote:
>
>> Thanx Raymond I'll try that out.
>>
>>
>> On 26 July 2011 11:24, Raymond Feng  wrote:
>>
>>> Hi, Amindri.
>>>
>>> Can you try to add your modules to features/all/pom.xml and
>>> modules/base-runtime/pom.xml? It seems that the sample uses base-runtime as
>>> the dependency to create the class path.
>>>
>>> For the memory issue, can you try to change memory setting for the
>>> surefire plugin? It is configured in the pom.xml under the  element
>>> whose artifactid is maven-surefire-plugin.
>>>
>>> Sent from my iPad
>>>
>>> On Jul 24, 2011, at 8:11 PM, Amindri Udugala 
>>> wrote:
>>>
>>> Hi,
>>>  Herewith I have listed down the artifacts that I have exposed to JMX
>>> connection and the attributes of the artifacts I have exposed. Also I have
>>> exposed some of the operations of these artifacts as well to the JMX
>>> connection.  Please comment if I have missed anything out. Have attached the
>>> latest patch with all the latest changes.
>>>
>>> With this I think I have done with most of my work, but the problem which
>>> I'm facing is that I still couldn't get the jmx-activator module activated
>>> when Tuscany is bootstrapped. I'm using LaunchCalculatorContribution in the
>>> sample module to bootstrap tuscany. I found out that jmx-activator module is
>>> not included in the classpath when I'm running the
>>> LaunchCalculatorContribution.
>>>
>>> I guess the reason for this is, that I was never able to build the whole
>>> trunk at once, due to lack of perm space. I executed MAVEN_OPTS="-Xmx1024m
>>> -Xms512m -XX:MaxPermSize=384m" before building the trunk, but still the
>>> problem remains.
>>>
>>> If I can get a solution for this problem, I'll be able to verify the
>>> correctness of the code...
>>>
>>>- Component
>>>
>>> *Attributes
>>> ***getComponents - Lists all runtime Components with
>>> following attributes* - Name, URI, AutoWire, Implementation
>>>
>>> Operations*
>>> getComponent(String name) - Lists all the attributes of the
>>> specified component- *Name, URI, AutoWire, Implementation, **ExtensionType,
>>>
>>> AttributeExtensions, Services, References, Properties, RequiredIntents,
>>> PolicySets, Extensions*
>>> setComponentURI(String currURI, String newURI)
>>> setComponentName(String uri, String newName)
>>> setComponentAutoWire(String uri, boolean autoWire)
>>> setComponentUnresolved(String uri, boolean unresolved)
>>>
>>>
>>>- ComponentService*
>>>*
>>>
>>> * Attributes *
>>>  getComponentServices - Lists all runtime ComponentServices with
>>> following attributes* - Name, CallBackReference, Service
>>>
>>>  Operations*
>>>  getComponentService(String name) - Lists all attributes of the
>>> specified ComponentService - *Name, CallBackReference, Service,
>>>
>>> **InterfaceContract, Bindings,* *AttributeExtensions, Endpoints, 
>>> **RequiredIntents,
>>> PolicySets ,
>>> Extensions*
>>>  setComponentServiceUnresolved(String name, boolean unresolved)
>>>  setComponentServiceForCallback(String name, boolean forCallBack)
>>>  setComponentServiceName(String currName, String newName)
>>>
>>>
>>>- Composite
>>>
>>> * Attributes
>>>   *getComposites() - Lists all runtime Composites with following
>>> attributes - *Name, URI,** ExtensionType, ContributionURI, SpecVersion,
>>> Local*
>>> *
>>>  Operations*
>>>   getComposite(String uri) - Lists all attributes of the
>>> specified ComponentService - *Name, URI,** ExtensionType,
>>> ContributionURI, SpecVersion ,
>>> Local, IsAutoWire, Unresolved, Components, Includes, FusedIncludes, 
>>> **RequiredIntents,
>>> Services, references ,
>>> Operations, Wires, Properties, Po

[jira] [Updated] (TUSCANY-3909) Exceptions occur over time

[ant elder (JIRA)]

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

ant elder updated TUSCANY-3909:
---

Attachment: tuscany-implementation-spring-1.6-TUSCANY-3909.jar
tuscany-host-jms-asf-1.6-TUSCANY-3909.jar

Add some extra debug info as discussed on ML. For changes see:

svn diff https://svn.apache.org/repos/asf/tuscany/sca-java-1.x/tags/1.6/modules 
https://svn.a
pache.org/repos/asf/tuscany/sca-java-1.x/tags/1.6-TUSCANY-3909

> Exceptions occur over time
> --
>
> Key: TUSCANY-3909
> URL: https://issues.apache.org/jira/browse/TUSCANY-3909
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-1.6
>Reporter: ant elder
> Attachments: tuscany-host-jms-asf-1.6-TUSCANY-3909.jar, 
> tuscany-implementation-spring-1.6-TUSCANY-3909.jar
>
>
> We're getting this error occurring over time in our application. It's a 
> distributed Domain spread over 5 machines using JMS as the transport. When 
> the modules start, all communication is fine. After a period of time (random, 
> but never shorter than a couple of hours), some of the connections start 
> getting this error. Nothing changes code wise between the application 
> working, and not working.
>  
>  
> remote service exception, see nested exception
> java.lang.RuntimeException: Message = argument type mismatch   
> >>   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:597)
> >>   at 
> org.apache.tuscany.sca.implementation.spring.invocation.SpringInvoker.doInvoke(SpringInvoker.java:97)
> >>   at 
> org.apache.tuscany.sca.implementation.spring.invocation.SpringInvoker.invoke(SpringInvoker.java:113)
> >>   at 
> org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:60)
>  
> See ML thread http://apache.markmail.org/message/fzhokuyyl5lqy3wo

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TUSCANY-3909) Exceptions occur over time

[ant elder (JIRA)]

Exceptions occur over time
--

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


We're getting this error occurring over time in our application. It's a 
distributed Domain spread over 5 machines using JMS as the transport. When the 
modules start, all communication is fine. After a period of time (random, but 
never shorter than a couple of hours), some of the connections start getting 
this error. Nothing changes code wise between the application working, and not 
working.

 

 

remote service exception, see nested exception

java.lang.RuntimeException: Message = argument type mismatch   

>>   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:597)

>>   at 
org.apache.tuscany.sca.implementation.spring.invocation.SpringInvoker.doInvoke(SpringInvoker.java:97)

>>   at 
org.apache.tuscany.sca.implementation.spring.invocation.SpringInvoker.invoke(SpringInvoker.java:113)

>>   at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:60)

 
See ML thread http://apache.markmail.org/message/fzhokuyyl5lqy3wo

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release Tuscany SCA 2.0-Beta3 RC2

[ant elder]

Anyone have time for a release vote?

   ...ant

On Thu, Jul 28, 2011 at 9:29 PM, ant elder  wrote:
> Please review and vote on the 2.0-Beta3 RC2  release artifacts.
>
> The artifacts are available at:
>
> http://people.apache.org/~antelder/tuscany/2.0-Beta3-RC2/
>
> The SVN tag for the release is:
>
> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-Beta3-RC2/
>
> TIA,
>
>  ...ant
>