Re: Tuscany Support
I have to say that I've not heard of any Luciano. Simon On Sun, Nov 10, 2013 at 11:10 PM, Luciano Resende luckbr1...@gmail.comwrote: I was asked off-list and didn't have any updated answer to this question... Are there any companies currently offering professional support for Tuscany ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: IMPORTANT: Major Confluence Upgrade Coming Soon. Please review test instance now.
Presumably it means that the web site as we see it now would remain up but we would loose the ability to make any changes to by changing the wiki. Sound right? On Tue, Jun 18, 2013 at 11:03 PM, Luciano Resende luckbr1...@gmail.comwrote: Please see below, this is going to cause a BIG impact for Tuscany, as our website is still based on autoexport plugin. -- Forwarded message -- From: *gmcdonald* Date: Tuesday, June 18, 2013 Subject: IMPORTANT: Major Confluence Upgrade Coming Soon. Please review test instance now. To: p...@apache.org, gene...@incubator.apache.org [PMCs please forward to your dev list ; Incubator Mentors please forward to your Podling dev list. Note that this message may be received twice as it will also go to committers@ list.] Hi All, If your project has a Confluence Wiki then this is an IMPORTANT announcement for you and your project. Please read this email carefully. NOTICE: The ASF Confluence instance is planned to be upgraded this Saturday 22nd June 2013. Judging by the time taken to upgrade the test instance, please expect the service to be in a down or read only state for the entire day. This email is to let you know that a test upgrade has already occurred and is live for you to play with now. This gives us all an opportunity to test for stability as well as any upgrade/plugin issues that might have happened along the way. Our current confluence wiki is at version 3.4.9 from way back in February 2011 and Atlassian have released a further 45 updates along the way, including another 2 major versions. The test instance has been upgraded several times along the way, with database surgery, operating system and server changes along the way. There have been casualties. Most notably is the Autoexport Plugin has had to be disabled permanently as during extensive testing, this plugin stopped working on version 4.3. Templates and Macros are also affected with major changes from wiki markup to xhtml amongst other things. Some plugins survived with upgrades all the way whilst some have been decommissioned/replaced or have changed to 'paid for' versions that we need to sort out licensing for. Nothing major that I can tell, but that's where you lot come in with your testing of your own spaces. Please familiarise yourself with what's new in Confluence 5.1 at https://confluence.atlassian.com/display/DOC/Confluence+5.1+Release+Notes and also take a good look around our upgraded test instance. Do not worry about mucking anything up on the test instance as that is what it is there for. Any changes/additions made will be lost on Saturday when a new migration will take place. The current confluence version will remain online in a read only state until the new version is completed. A jira ticket has been raised at https://issues.apache.org/jira/browse/INFRA-6406 where projects can add comments on any issues they are having with the test instance as compared to their old site. Just problems only please, do not turn it into a how to use confluence 5 thread. In addition, if there are any features that you currently use that do not work in the test instance, please replicate the feature in the current production TEST space so that I can test them all in the one place along the way. (Ask if you need create page permissions to cwiki.apache.org/confluence/display/TEST ) It may be possible in the future to replace Autoexport by playing around with the API to export the pages but this is not a priority, nor is it supported. We warned projects long ago that the Autoexport Tool would be incompatible with future Confluence versions and that time has now come. Ok so, please test and report to the Jira Issue mentioned anything amiss with your space. Go to https://cwiki2.apache.org/confluence and have a play around. You have 3 DAYS to report anything you find. Thanks Gavin (ASF Infra) - To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org For additional commands, e-mail: private-h...@incubator.apache.org -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [NOTICE] Welcome Jean-Sebastien Delfino as new Tuscany PMC Chair
Congrats Sebastien and thanks for taking on the role. Simon On Tue, May 28, 2013 at 11:03 AM, Mike Edwards mike.edwards.inglen...@gmail.com wrote: On 22/05/2013 17:35, Luciano Resende wrote: The Tuscany PMC has voted and the Board has confirmed Jean-Sebastien Delfino as the new Tuscany PMC Chair. Congratulations !!! -- Luciano Resende http://people.apache.org/~**lresende http://people.apache.org/~lresende http://twitter.com/**lresende1975 http://twitter.com/lresende1975 http://lresende.blogspot.com/ Congratulations, Jean-Sebastien. Yours, Mike. -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Accept Apache Nuvem as a Tuscany sub-project
On Wed, Nov 14, 2012 at 7:38 AM, Jean-Sebastien Delfino jsdelf...@apache.org wrote: On Mon, Nov 12, 2012 at 10:04 PM, Luciano Resende luckbr1...@gmail.com wrote: Apache Nuvem will define an open application programming interface for common cloud application services, allowing applications to be easily ported across the most popular cloud platforms. It is currently composed of multiple cloud SCA components (Data, Queue, Chat), and supports multiple cloud platforms such as AWS, GAE, etc as well as standalone deployment. Nuvem was accepted for Incubation on June, 2010, and several of the active committers are already part of the Tuscany PMC. Nuvem was accepted for Incubation on June 2010, and is currently a small community, where the contributions are 100% done by volunteers in their own free time, which makes the level of activity low, compared to what is required for graduating it as a TLP. Having said that, Nuvem has a great synergy with Apache Tuscany, and I'd like to call a community vote to accept Nuvem as a sub-project of Apache Tuscany (it could become Tuscany Cloud Components, or something like that). Please cast your vote. +1 - Jean-Sebastien +1 from me Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC2
On Sun, Jun 24, 2012 at 10:58 AM, Nirmal Fernando nirmal070...@gmail.com wrote: +1 for the release! Thanks Ant for the hard work you've put in, on getting this release in!! On Sun, Jun 24, 2012 at 3:13 PM, ant elder ant.el...@gmail.com wrote: Well +1 from me anyway, would anyone else have a vote? ...ant On Tue, Jun 19, 2012 at 10:02 AM, ant elder ant.el...@gmail.com wrote: Here's the 2.0 RC2 release artifacts, please review and vote. The distributions and staging maven repo are at: http://people.apache.org/~antelder/tuscany/2.0-RC2/ The SVN tag: https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/tags/2.0-RC2/ ...ant -- Best Regards, Nirmal C.S.Nirmal J. Fernando Software Engineer, WSO2 Inc. Blog: http://nirmalfdo.blogspot.com/ I second that, thanks Ant for sticking with it when I've not been very responsive. +1 from me Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Fri, May 11, 2012 at 12:49 PM, ant elder ant.el...@gmail.com wrote: On Thu, May 10, 2012 at 6:31 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 9:44 AM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws simonsl...@googlemail.com wrote: ..snip Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. doh - I'm getting out of practice. I'll try again. I can add a sentence to the top sample README saying what it is but what else if anything needs updating before doing a respin just for that? ...ant I'd like to run through the samples before a respin. Won't get to it until this evening. Simon I have just came back from vacation end of last week and I'm finally getting time to go over this and will send feedback soonish. On a related topic, would you guys be ok on waiting for finishing up Wink 1.2 release which a initial RC was done over the weekend, so that we can have it as part of the 2.0 release ? Ok, Wink 1.2 has been trough the voting process. I'll publish the artifacts and update Tuscany. Ok i see you've done that now, I could spin a new RC but there hasn't been much review of RC1 yet and there are still a bunch of issues that Simon raised (i've fixed all the getting started samples). Is anyone going to do any more reviews or fixes? ...ant I still want to do more on RC1 (but am being very slow, sorry). Maybe we should set a deadline for doing RC2. Another couple of weeks? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Sat, Apr 28, 2012 at 9:57 AM, ant elder ant.el...@gmail.com wrote: Ok well thanks for looking. I think we all knew there were issues with some samples, and we saw what happened with the beta1 release when we tried to sort all that out and it descended into unconstructiveness. I can fix some of those that you've pointed out, though i wont have much time for a little while, but there are some i'm not interested in. I'd have preferred to just release what we have quickly and fix things incrementally in more frequent releases but for now i'll wait a little while and see if we get any fixes made and then look at an RC2 in a week or two. ...ant Ok, well for a 2.0 release I think we should either fix or remove stuff that doesn't work. I'll have some time but it's a bit sporadic at the moment. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Wed, Apr 25, 2012 at 9:32 PM, Simon Laws simonsl...@googlemail.com wrote:
snip...
Simon, It looks like you've not included the staging repo, the samples
aren't finding the 2.0 pom's in Maven central because the release
hasn't been published yet.
I've put the staging repo configuration in and am still having
problems. Can you paste you settings.xml configuration.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
I find an old version of settings.xml on a backup disc I have. I have
the config of the mirrors tag correct now and have made more progress.
Not quite done but here's what I've found in case someone has some
time
tuscany--distribution-all-2.0-src.zip - Fail - see [6]
tuscany-distribution-all-2.0.zip - TODO
tuscany-samples-2.0.zip
README- empty
CHANGES RELEASE_NOTES - should they be samples specific?
applications
store - Fail - see [3]
getting-started
getting-started.pdf - OK
helloworld - OK
helloworld-ant - README same as helloworld. Not sure what
it's supposed to do
helloworld-bpel - README talks about this being a Spring example.
helloworld-jaxrs- OK
helloworld-jsonp- OK
helloworld-jsonrpc - OK
helloworld-scaclient- Fail - see [1]
helloworld-spring - OK
helloworld-webapp - OK
helloworld-webservice - OK
helloworld-withdeps - Fail - see [2]
learning-more - No doc at this level
async-invocation- No doc. Fails when run - see [4]
binding-comet
binding-websocket
contribution-osgi
distributed-osgi-dynamic
distributed-osgi-static
running-tuscany
running-tuscany.html- Should be PDF for match getting started
ant - Fail - see [5]
README.html - PDF or text file?
command-line- OK
README.html - PDF or text file?
eclipse - OK
README.html - PDF or text file?
jse
junit
osgi
README.html - PDF or text file?
tuscany-war-2.0.war- TODO
Maven staging repo - OK
RAT- TODO
Signatures - TODO
[1]
C:\simon\sca\release\tuscany-samples-2.0\tuscany-samples-2.0\getting-started\hel
loworld-scaclientmvn tuscany:run
[INFO] Scanning for projects...
[INFO]
[INFO] Building Apache Tuscany SCA Samples Helloworld SCAClient
[INFO]task-segment: [tuscany:run]
[INFO]
[INFO] Preparing tuscany:run
[INFO] [enforcer:enforce {execution: enforce-plugin-versions}]
[INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus
.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 2 source files to C:\simon\sca\release\tuscany-samples-2.0\tusc
any-samples-2.0\getting-started\helloworld-scaclient\target\classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory C:\simon\sca\release\tuscany-samples-
2.0\tuscany-samples-2.0\getting-started\helloworld-scaclient\src\test\resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 1 source file to C:\simon\sca\release\tuscany-samples-2.0\tusca
ny-samples-2.0\getting-started\helloworld-scaclient\target\test-classes
[INFO] [tuscany:run {execution: default-cli}]
[INFO] Invoking sample.HelloworldSCAClient class main method...
HelloworldSCAClient, using domainURI uri:default
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] exception invoking main method
org.apache.tuscany.sca.client.impl.SCAClientFactoryImpl.init(java.net.URI, jav
a.util.Properties)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 5 seconds
[INFO] Finished at: Thu Apr 26 21:33:26 BST 2012
[INFO] Final Memory: 25M/981M
[INFO
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Tue, Apr 24, 2012 at 5:44 PM, Luciano Resende luckbr1...@gmail.com wrote: On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws simonsl...@googlemail.com wrote: ..snip Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. doh - I'm getting out of practice. I'll try again. I can add a sentence to the top sample README saying what it is but what else if anything needs updating before doing a respin just for that? ...ant I'd like to run through the samples before a respin. Won't get to it until this evening. Simon I have just came back from vacation end of last week and I'm finally getting time to go over this and will send feedback soonish. On a related topic, would you guys be ok on waiting for finishing up Wink 1.2 release which a initial RC was done over the weekend, so that we can have it as part of the 2.0 release ? -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/ It's OK by me Lunciano. I think we're going to have to respin here anyhow. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
snip... Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. I've put the staging repo configuration in and am still having problems. Can you paste you settings.xml configuration. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
..snip Simon, It looks like you've not included the staging repo, the samples aren't finding the 2.0 pom's in Maven central because the release hasn't been published yet. doh - I'm getting out of practice. I'll try again. I can add a sentence to the top sample README saying what it is but what else if anything needs updating before doing a respin just for that? ...ant I'd like to run through the samples before a respin. Won't get to it until this evening. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Mon, Apr 23, 2012 at 7:25 PM, Raymond Feng enjoyj...@gmail.com wrote: Hi, I'm struggling to get a clean build. The top-down build hangs at the following otest: Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.397 sec Running client_bjm.BJM_6014_1_1_TestCase Implementation language set to: _Java Apr 23, 2012 11:00:34 AM org.apache.tuscany.sca.node.impl.NodeImpl start INFO: Starting node: http://tuscany.apache.org/sca/1.1/nodes/default0 domain: default Apr 23, 2012 11:00:34 AM org.apache.tuscany.sca.node.impl.NodeFactoryImpl loadContributions INFO: Loading contribution: file:/home/rfeng/tuscany/sca-java-2.x/trunk/testing/compliance-tests/binding-jms/target/oasis-contributions/BJM_6014_1_1/target/BJM_6014_1_1.zip Apr 23, 2012 11:00:34 AM org.apache.tuscany.sca.node.impl.NodeFactoryImpl loadContributions INFO: Loading contribution: file:/home/rfeng/tuscany/sca-java-2.x/trunk/testing/compliance-tests/binding-jms/target/oasis-contributions/BJM_General/target/BJM_General.zip Apr 23, 2012 11:00:34 AM org.apache.tuscany.sca.node.impl.NodeFactoryImpl loadContributions INFO: Loading contribution: file:/home/rfeng/tuscany/sca-java-2.x/trunk/testing/compliance-tests/binding-jms/target/oasis-contributions/BJM_General_Java/target/BJM_General_Java.zip Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.binding.jms.host.DefaultJMSServiceListener registerListener INFO: JMS service 'Service3' listening on destination TEST_BJM_6014_Service_Queue Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.core.assembly.impl.DomainRegistryImpl addEndpoint INFO: Add endpoint - binding.jms - TEST_BJM_6014Component1/Service3 Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.binding.jms.host.DefaultJMSServiceListener registerListener INFO: JMS callback service 'reference4' listening on destination TEST_BJM_6014_Callback_Queue Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.core.assembly.impl.DomainRegistryImpl addEndpoint INFO: Add endpoint - binding.jms - TEST_BJM_6014Component1/reference4 Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.node.impl.NodeImpl stop Test BJM_6014_1_1 completed successfully INFO: Stopping node: http://tuscany.apache.org/sca/1.1/nodes/default0 Apr 23, 2012 11:00:35 AM org.apache.tuscany.sca.core.assembly.impl.DomainRegistryImpl removeEndpoint INFO: Remove endpoint - binding.jms - TEST_BJM_6014Component1/Service3 I had to interrupt the process. Thanks, Raymond On Apr 22, 2012, at 10:54 PM, ant elder wrote: Still looking for votes. Its been nearly two weeks now... ...ant On Thu, Apr 12, 2012 at 6:04 PM, ant elder ant.el...@gmail.com wrote: I've spun the artifacts for the 2.0 release, they're available at: http://people.apache.org/~antelder/tuscany/2.0-RC1/ Please review and cast your vote on releasing. Many thanks, ...ant Hi Raymond I've seen that a few times in my normal development build. It seemed to be behaving itself recently but obviously not. I did however see an issue I've not seen before when building the all source on linux with a clean repo. [INFO] [INFO] Error for project: Apache Tuscany SCA Comet Binding Runtime (during insta ll) [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:jersey-server:bundle:null Reason: Cannot find parent: com.sun.jersey:jersey-project for project: null:jers ey-server:bundle:null for project null:jersey-server:bundle:null Haven't looked into it yet. In parallel i'm starting to look through the samples. The first issues is that the top level README is empty. It's like this in svn so not sure what's happened. More later Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [VOTE] Release Tuscany SCA 2.0 RC1
On Mon, Apr 16, 2012 at 8:15 AM, ant elder ant.el...@gmail.com wrote: Looks ok to me so +1. ...ant On Thu, Apr 12, 2012 at 6:04 PM, ant elder ant.el...@gmail.com wrote: I've spun the artifacts for the 2.0 release, they're available at: http://people.apache.org/~antelder/tuscany/2.0-RC1/ Please review and cast your vote on releasing. Many thanks, ...ant Hi Ant Have been a bit busy with something else so haven't got to this yet. Sorry. It's on my list;-) Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Assigned] (TUSCANY-4036) WSDL service names are duplicated when user does not provide WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4036: --- Assignee: Simon Laws WSDL service names are duplicated when user does not provide WSDL - Key: TUSCANY-4036 URL: https://issues.apache.org/jira/browse/TUSCANY-4036 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Attachments: TUSCANY-4036.patch Scenario: An SCA composite has multiple components which * use binding.ws * do not provide a WSDL document via the wsdlElement attribute * implement the same Java interface In this case, for each web service binding, WSDLServiceGenerator takes the WSDL Definition that is generated by Interface2WSDLGenerator and adds a WSDL service and port to it. In this scenario where multiple components implement the same interface, the resulting WSDL services have the same definition namespace (which is derived from the Java package name) and the same local name (which is derived from the Java class name). This may make it difficult for the runtime to tailor the WSDL to support component-specific policy. This problem does not exist when the user does provide WSDL (either via wsdlElement or interface.wsdl). In that case WSDLServiceGenerator creates a new WSDL Definition with a modified namespace that includes the component name. This is possible because the generated WSDL can import the user's WSDL document. It is more difficult to do this in the problem scenario because WSDLServiceGenerator is already working with a generated document that has no physical location for the import to refer to. An alternate solution is for WSDLServiceGenerator to include the component name in the WSDL service name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4036) WSDL service names are duplicated when user does not provide WSDL
[ https://issues.apache.org/jira/browse/TUSCANY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4036. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304746. Thanks for the patch Greg. WSDL service names are duplicated when user does not provide WSDL - Key: TUSCANY-4036 URL: https://issues.apache.org/jira/browse/TUSCANY-4036 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4036.patch Scenario: An SCA composite has multiple components which * use binding.ws * do not provide a WSDL document via the wsdlElement attribute * implement the same Java interface In this case, for each web service binding, WSDLServiceGenerator takes the WSDL Definition that is generated by Interface2WSDLGenerator and adds a WSDL service and port to it. In this scenario where multiple components implement the same interface, the resulting WSDL services have the same definition namespace (which is derived from the Java package name) and the same local name (which is derived from the Java class name). This may make it difficult for the runtime to tailor the WSDL to support component-specific policy. This problem does not exist when the user does provide WSDL (either via wsdlElement or interface.wsdl). In that case WSDLServiceGenerator creates a new WSDL Definition with a modified namespace that includes the component name. This is possible because the generated WSDL can import the user's WSDL document. It is more difficult to do this in the problem scenario because WSDLServiceGenerator is already working with a generated document that has no physical location for the import to refer to. An alternate solution is for WSDLServiceGenerator to include the component name in the WSDL service name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding
[ https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236484#comment-13236484 ] Simon Laws commented on TUSCANY-4031: - Hi Greg Are you happy to have this patch applied? If so can you check the box in the JIRA to confirm that. Thanks. IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding -- Key: TUSCANY-4031 URL: https://issues.apache.org/jira/browse/TUSCANY-4031 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Priority: Minor Attachments: TUSCANY-4031.patch ComponentPolicyBuilderImpl.checkIntentsResolved() checks when intents used by an Endpoint are provided by the binding. It should do the same for intents used by an EndpointReference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4030) AccessControlException when trying to read schemas with Java 2 security enabled
[
https://issues.apache.org/jira/browse/TUSCANY-4030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4030:
---
Assignee: Simon Laws
AccessControlException when trying to read schemas with Java 2 security
enabled
---
Key: TUSCANY-4030
URL: https://issues.apache.org/jira/browse/TUSCANY-4030
Project: Tuscany
Issue Type: Bug
Reporter: Kaushik Mukherjee
Assignee: Simon Laws
Attachments: TUSCANY-4030v3.patch
I believe we need to wrap line 183 in the XSDModelResolver with an
AccessController.doPrivileged so we can read a schema when java 2 security is
enabled. Working on a patch now.
InputSource xsd = null;
final XSDefinition finaldef = definition;
try {
try {
xsd = (InputSource) AccessController.doPrivileged(new
PrivilegedExceptionActionInputSource() {
public InputSource run() throws IOException {
return
XMLDocumentHelper.getInputSource(finaldef.getLocation().toURL());
}
});
} catch (PrivilegedActionException e) {
throw (IOException) e.getException();
}
} catch (IOException e) {
throw new ContributionRuntimeException(e);
}
java.security.AccessControlException: Access denied (java.io.FilePermission
C:\WAS\was85a\profiles\AppSrv01\installedAssets\sdoscope-shared-oasis.jar\BASE\sdoscope-shared-oasis.jar
read)
at
java.security.AccessController.checkPermission(AccessController.java:132)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:544)
at
com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208)
at java.lang.SecurityManager.checkRead(SecurityManager.java:883)
at java.util.zip.ZipFile.init(ZipFile.java:145)
at java.util.jar.JarFile.init(JarFile.java:149)
at java.util.jar.JarFile.init(JarFile.java:86)
at sun.net.www.protocol.jar.URLJarFile.init(URLJarFile.java:84)
at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:60)
at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:92)
at
sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:119)
at
sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:147)
at
org.apache.tuscany.sca.common.xml.XMLDocumentHelper.openStream(XMLDocumentHelper.java:139)
at
org.apache.tuscany.sca.common.xml.XMLDocumentHelper.getInputSource(XMLDocumentHelper.java:129)
at
org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:183)
at
org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:224)
at
org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:123)
at
org.apache.tuscany.sca.contribution.resolver.ExtensibleModelResolver.resolveModel(ExtensibleModelResolver.java:154)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema
[ https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236509#comment-13236509 ] Simon Laws commented on TUSCANY-4035: - Hi Kaushik Can you check the flag that says you're happy that this is a patch that Apache can use? Application could possibly fail to start if multiple threads are loading the same schema Key: TUSCANY-4035 URL: https://issues.apache.org/jira/browse/TUSCANY-4035 Project: Tuscany Issue Type: Bug Reporter: Kaushik Mukherjee Attachments: TUSCANY-4035.patch This was an issue in Tuscany 1.x and is likely an issue in the 2.x code as well. The fix in 1.x was to synchronize schema loading across all XSDModelResolvers. Starting multiple applications simultaneously can lead to an exception such as: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection. Namespace: http://my.namespace at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:223) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:202) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:204) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:240) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:114) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4033) Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
[
https://issues.apache.org/jira/browse/TUSCANY-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4033.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Fix applied at revision: 1304327
Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
Key: TUSCANY-4033
URL: https://issues.apache.org/jira/browse/TUSCANY-4033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0
Reporter: Vijai Kalathur
Assignee: Simon Laws
Fix For: Java-SCA-2.0
If I have a service interface which does not contain a no-arg default
constructor and try to do a remote service invocation to that service, the
invocation fails when the haveMatchingInterfaceContracts method in
EndpointReferenceBinderImpl tries to generate a WSDL. Since the interface
does not contain a no-arg constructor, the wsdl gen fails. We might have to
update something in this check
if (endpointReferenceContract.getClass() !=
endpointContract.getClass() ||
endpointReferenceContract.getNormalizedWSDLContract() != null ||
endpointContract.getNormalizedWSDLContract() != null) {
endpointReferenceContract =
((RuntimeEndpointReference)endpointReference).getGeneratedWSDLContract(endpointReferenceContract);
endpointContract =
((RuntimeEndpoint)endpoint).getGeneratedWSDLContract(endpointContract);
}
to not generate the wsdl in certain cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4033) Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
[
https://issues.apache.org/jira/browse/TUSCANY-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4033:
---
Assignee: Simon Laws
Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen
Key: TUSCANY-4033
URL: https://issues.apache.org/jira/browse/TUSCANY-4033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-2.0
Reporter: Vijai Kalathur
Assignee: Simon Laws
Fix For: Java-SCA-2.0
If I have a service interface which does not contain a no-arg default
constructor and try to do a remote service invocation to that service, the
invocation fails when the haveMatchingInterfaceContracts method in
EndpointReferenceBinderImpl tries to generate a WSDL. Since the interface
does not contain a no-arg constructor, the wsdl gen fails. We might have to
update something in this check
if (endpointReferenceContract.getClass() !=
endpointContract.getClass() ||
endpointReferenceContract.getNormalizedWSDLContract() != null ||
endpointContract.getNormalizedWSDLContract() != null) {
endpointReferenceContract =
((RuntimeEndpointReference)endpointReference).getGeneratedWSDLContract(endpointReferenceContract);
endpointContract =
((RuntimeEndpoint)endpoint).getGeneratedWSDLContract(endpointContract);
}
to not generate the wsdl in certain cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding
[ https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4031: --- Assignee: Simon Laws IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding -- Key: TUSCANY-4031 URL: https://issues.apache.org/jira/browse/TUSCANY-4031 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4031.patch ComponentPolicyBuilderImpl.checkIntentsResolved() checks when intents used by an Endpoint are provided by the binding. It should do the same for intents used by an EndpointReference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding
[ https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4031. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304507. Thanks for the patch Greg. IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding -- Key: TUSCANY-4031 URL: https://issues.apache.org/jira/browse/TUSCANY-4031 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4031.patch ComponentPolicyBuilderImpl.checkIntentsResolved() checks when intents used by an Endpoint are provided by the binding. It should do the same for intents used by an EndpointReference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4032) Remote getService() lookup with only component name fails when target has a callback
[ https://issues.apache.org/jira/browse/TUSCANY-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4032: --- Assignee: Simon Laws Remote getService() lookup with only component name fails when target has a callback Key: TUSCANY-4032 URL: https://issues.apache.org/jira/browse/TUSCANY-4032 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: Simon Laws If I deploy a composite with the following component component name=SCAJFrontendComponent implementation.java class=test.bindings.sca.FrontendImpl/ service name=FrontendService interface.java interface=test.bindings.sca.intf.FrontendService/ binding.sca / /service reference name=backendService target=SerializationBackendComponent interface.java interface=test.bindings.sca.intf.SerializeBackendService callbackInterface=test.bindings.sca.intf.SerializeCallback/ callback binding.sca / /callback /reference /component and try to do a getService lookup using just the component name on a different JVM, the lookup fails saying there are multiple services in the component and I need to specify a service name. The check in DefaultEndpointFinder to check if the endpoint service is a callback service doesn't seem to be working in the remote case. I think the code in the EndpointProcessor needs to be updated to include some attribute to indicate that the service is a callback service when it's getting serialized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4032) Remote getService() lookup with only component name fails when target has a callback
[ https://issues.apache.org/jira/browse/TUSCANY-4032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4032. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Fix applied at revision: 1304510 Remote getService() lookup with only component name fails when target has a callback Key: TUSCANY-4032 URL: https://issues.apache.org/jira/browse/TUSCANY-4032 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.0 Environment: All OS Reporter: Vijai Kalathur Assignee: Simon Laws Fix For: Java-SCA-2.0 If I deploy a composite with the following component component name=SCAJFrontendComponent implementation.java class=test.bindings.sca.FrontendImpl/ service name=FrontendService interface.java interface=test.bindings.sca.intf.FrontendService/ binding.sca / /service reference name=backendService target=SerializationBackendComponent interface.java interface=test.bindings.sca.intf.SerializeBackendService callbackInterface=test.bindings.sca.intf.SerializeCallback/ callback binding.sca / /callback /reference /component and try to do a getService lookup using just the component name on a different JVM, the lookup fails saying there are multiple services in the component and I need to specify a service name. The check in DefaultEndpointFinder to check if the endpoint service is a callback service doesn't seem to be working in the remote case. I think the code in the EndpointProcessor needs to be updated to include some attribute to indicate that the service is a callback service when it's getting serialized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema
[ https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4035: --- Assignee: Simon Laws Application could possibly fail to start if multiple threads are loading the same schema Key: TUSCANY-4035 URL: https://issues.apache.org/jira/browse/TUSCANY-4035 Project: Tuscany Issue Type: Bug Reporter: Kaushik Mukherjee Assignee: Simon Laws Attachments: TUSCANY-4035v2.patch This was an issue in Tuscany 1.x and is likely an issue in the 2.x code as well. The fix in 1.x was to synchronize schema loading across all XSDModelResolvers. Starting multiple applications simultaneously can lead to an exception such as: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection. Namespace: http://my.namespace at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:223) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:202) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:204) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:240) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:114) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema
[ https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4035. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Applied at revision: 1304516. Thanks for the patch Kaushik. Application could possibly fail to start if multiple threads are loading the same schema Key: TUSCANY-4035 URL: https://issues.apache.org/jira/browse/TUSCANY-4035 Project: Tuscany Issue Type: Bug Reporter: Kaushik Mukherjee Assignee: Simon Laws Fix For: Java-SCA-2.0 Attachments: TUSCANY-4035v2.patch This was an issue in Tuscany 1.x and is likely an issue in the 2.x code as well. The fix in 1.x was to synchronize schema loading across all XSDModelResolvers. Starting multiple applications simultaneously can lead to an exception such as: org.apache.ws.commons.schema.XmlSchemaException: Schema name conflict in collection. Namespace: http://my.namespace at org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:223) at org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:202) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:347) at org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:379) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:204) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.aggregate(XSDModelResolver.java:240) at org.apache.tuscany.sca.xsd.xml.XSDModelResolver.resolveModel(XSDModelResolver.java:114) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4034) More memory leak fixes
More memory leak fixes -- Key: TUSCANY-4034 URL: https://issues.apache.org/jira/browse/TUSCANY-4034 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Plugging variuous potential memory leaks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4034) More memory leak fixes
[ https://issues.apache.org/jira/browse/TUSCANY-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4034: --- Assignee: Simon Laws More memory leak fixes -- Key: TUSCANY-4034 URL: https://issues.apache.org/jira/browse/TUSCANY-4034 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 Plugging variuous potential memory leaks. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4028) Don't duplicate intents in Java implementation model
[ https://issues.apache.org/jira/browse/TUSCANY-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4028: --- Assignee: Simon Laws Don't duplicate intents in Java implementation model Key: TUSCANY-4028 URL: https://issues.apache.org/jira/browse/TUSCANY-4028 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 We have code in CompositeProcessor that caches intents and copies them back into the JavaImplementationModel. Add a check so that intents that are already present are not duplicated. I think this code is a hang over from when we used to share implementation models. If I remove it though I get test failures so for now I'm fixing the symptom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4028) Don't duplicate intents in Java implementation model
Don't duplicate intents in Java implementation model Key: TUSCANY-4028 URL: https://issues.apache.org/jira/browse/TUSCANY-4028 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 We have code in CompositeProcessor that caches intents and copies them back into the JavaImplementationModel. Add a check so that intents that are already present are not duplicated. I think this code is a hang over from when we used to share implementation models. If I remove it though I get test failures so for now I'm fixing the symptom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4028) Don't duplicate intents in Java implementation model
[ https://issues.apache.org/jira/browse/TUSCANY-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4028. --- Resolution: Fixed Change committed at revision 1301369 Don't duplicate intents in Java implementation model Key: TUSCANY-4028 URL: https://issues.apache.org/jira/browse/TUSCANY-4028 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 We have code in CompositeProcessor that caches intents and copies them back into the JavaImplementationModel. Add a check so that intents that are already present are not duplicated. I think this code is a hang over from when we used to share implementation models. If I remove it though I get test failures so for now I'm fixing the symptom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4027: --- Assignee: Simon Laws EndpointFinder is ineffective - Key: TUSCANY-4027 URL: https://issues.apache.org/jira/browse/TUSCANY-4027 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Attachments: TUSCANY-4027.patch SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder. I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference(). This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4027) EndpointFinder is ineffective
[ https://issues.apache.org/jira/browse/TUSCANY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4027. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Thanks for the patch Greg, Committed at revision: 1299664 EndpointFinder is ineffective - Key: TUSCANY-4027 URL: https://issues.apache.org/jira/browse/TUSCANY-4027 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 Attachments: TUSCANY-4027.patch SCAClientFactoryImpl calls the EndpointFinder to find a matching endpoint. If the endpoint returned by EndpointFinder is local to the same JVM, SCAClientFactoryImpl then calls RuntimeComponentImpl.getServiceReference() which calls ComponentContextImpl.createSelfReference(). If the client's URI does not include a binding name, ComponentContextImpl picks the first binding. This supercedes whatever selection was made by the EndpointFinder. I am attaching a patch that fixes the issue. It constructs a full URI based on the selection made by the EndpointFinder and passes that to RuntimeComponentImpl.getServiceReference(). This exposed another issue. The scaclient-api itest tests that a getService() using component name only is rejected with a ServiceRuntimeException if the target component implements multiple services. This is because it is ambiguous which service is desired (SCAClientFactoryImpl does not do interface matching). This was being enforced in ComponentContextImpl, but with the above fix that isn't possible since it now gets a fully-specified URI. In order to fix this, I added a check into DefaultEndpointFinder. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4026) XSDModelResolver fails to initiate WSDL model resolution for inline schemas
[ https://issues.apache.org/jira/browse/TUSCANY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227198#comment-13227198 ] Simon Laws commented on TUSCANY-4026: - Hi Kaushik I tried to apply the patch but there seems to be some changes missing. The patch applies a dependency from xsd to interface-wsdl. However there is already a dependency in the opposite direction. How did you get round this in your build? XSDModelResolver fails to initiate WSDL model resolution for inline schemas --- Key: TUSCANY-4026 URL: https://issues.apache.org/jira/browse/TUSCANY-4026 Project: Tuscany Issue Type: Bug Components: Java SCA Databinding-SDO Affects Versions: Java-SCA-2.x Reporter: Kaushik Mukherjee Attachments: JIRA-4206.patch XSDModelResolver fails to initiate WSDLModelResolver for inline schemas during start so there is no inline schema document object model added to the contribution. When we try to resolve the namespace and type associated with the inline schema we fail to find the document since it was never built. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it
Give registry contribution listeners a chance to retireve the contribution info
before removing it
--
Key: TUSCANY-4025
URL: https://issues.apache.org/jira/browse/TUSCANY-4025
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-2.0
In our DomainRegistryImpl class we have
public void uninstallContribution(String uri) {
contributionDescriptions.remove(uri);
for (ContributionListener listener : contributionlisteners) {
listener.contributionRemoved(uri);
}
}
It should wait until the listeners have been called before removing the
contribution description.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it
[
https://issues.apache.org/jira/browse/TUSCANY-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4025:
---
Assignee: Simon Laws
Give registry contribution listeners a chance to retireve the contribution
info before removing it
--
Key: TUSCANY-4025
URL: https://issues.apache.org/jira/browse/TUSCANY-4025
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
In our DomainRegistryImpl class we have
public void uninstallContribution(String uri) {
contributionDescriptions.remove(uri);
for (ContributionListener listener : contributionlisteners) {
listener.contributionRemoved(uri);
}
}
It should wait until the listeners have been called before removing the
contribution description.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it
[
https://issues.apache.org/jira/browse/TUSCANY-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4025.
---
Resolution: Fixed
Fix committed at revision: 1298469
Give registry contribution listeners a chance to retireve the contribution
info before removing it
--
Key: TUSCANY-4025
URL: https://issues.apache.org/jira/browse/TUSCANY-4025
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
In our DomainRegistryImpl class we have
public void uninstallContribution(String uri) {
contributionDescriptions.remove(uri);
for (ContributionListener listener : contributionlisteners) {
listener.contributionRemoved(uri);
}
}
It should wait until the listeners have been called before removing the
contribution description.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3054) Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class
[ https://issues.apache.org/jira/browse/TUSCANY-3054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3054. --- Resolution: Fixed Fix Version/s: Java-SCA-1.x Been look at this with a view to copying the change to 2.x but it looks like we already do the caching that's cintained in ClassCachedJavaInterfaceFactory Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class Key: TUSCANY-3054 URL: https://issues.apache.org/jira/browse/TUSCANY-3054 Project: Tuscany Issue Type: Improvement Components: Java SCA Java Implementation Extension Reporter: Scott Kurz Priority: Minor Fix For: Java-SCA-1.x Nothing's broken .. just suggesting a better-performing impl. Will checkin shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3770) Tomcat 7 reports a memory leak when stopping a Tuscany webapp
[ https://issues.apache.org/jira/browse/TUSCANY-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3770: Attachment: ThreadMessageContext.java.patch A patch for the 2.x code base. Want to do this fix separately so I can be sure I'm not messing anything up. Tomcat 7 reports a memory leak when stopping a Tuscany webapp - Key: TUSCANY-3770 URL: https://issues.apache.org/jira/browse/TUSCANY-3770 Project: Tuscany Issue Type: Bug Components: Java SCA Web App Integration Affects Versions: Java-SCA-1.6 Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-1.6.1 Attachments: ThreadMessageContext.java.patch On Tomcat 7, when a Tuscany webapp is stopped, the following message is displayed: SEVERE: The web application [/sample-calculator-webapp] created a ThreadLocal with key of type [null] (value [org.apache.tuscany.sca.core.invocation.ThreadMessageContext$1@1b071c0]) and a value of type [org.apache.tuscany.sca.core.invocation.MessageImpl] (value [org.apache.tuscany.sca.core.invocation.MessageImpl@fbf51d]) but failed to remove it when the web application was stopped. This is very likely to create a memory leak. This happens because Tuscany adds a thread-local ThreadMessageContext object to every invocation thread when starting a request invocation and doesn't remove this object when the request is complete. There is code in WebAppServletHost.destroy() that attempts to remove this context information when the webapp is stopped. This usually doesn't succeed in removing the context information because the ThreadLocal.remove() method only removes context information from the current thread and not from other threads. There's no Java API for removing this information from other threads. The only way to remove this information is to track the completion of each request invocation and remove the context information from the current thread when the request has been completed. The context information will be recreated for the next request on the thread. This is very easy to implement by adding a few lines of code to the ThreadMessageContext class. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4020) Still some hard coded message strings in the code
[ https://issues.apache.org/jira/browse/TUSCANY-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4020. --- Resolution: Fixed I've moved any hard coded messages I could find to properties files at revision: 1295144 Still some hard coded message strings in the code - Key: TUSCANY-4020 URL: https://issues.apache.org/jira/browse/TUSCANY-4020 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 Some code still contains hard coded message strings. For example, see BaseAssemblyProcessor ComponentTypeDocumentProcessor CompositeDocumentProcessor CompositeProcessor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217216#comment-13217216 ] Simon Laws commented on TUSCANY-4017: - Another thought. We collate the policy information from the composite, component, reference/service, binding hierarchy onto Endpoints and EncpointReferences. I don't believe we push that back to bindings. So if you look at the binding I can well believe you still see exactlyOnce. If you look at the Endpoint or EndpointReference you should see atleastOnce/atMostOnce. Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Assignee: Simon Laws Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r1293172 - in /tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers: HeaderReferenceInterceptor.java HeaderServiceInterceptor
On Fri, Feb 24, 2012 at 10:45 AM, jennt...@apache.org wrote:
Author: jennthom
Date: Fri Feb 24 10:45:15 2012
New Revision: 1293172
URL: http://svn.apache.org/viewvc?rev=1293172view=rev
Log:
Fix for JIRA TUSCANY 4019 - remote scsOperationName from response messages.
Modified:
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderReferenceInterceptor.java
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderServiceInterceptor.java
Modified:
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderReferenceInterceptor.java
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderReferenceInterceptor.java?rev=1293172r1=1293171r2=1293172view=diff
==
---
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderReferenceInterceptor.java
(original)
+++
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderReferenceInterceptor.java
Fri Feb 24 10:45:15 2012
@@ -175,15 +175,6 @@ public class HeaderReferenceInterceptor
javax.jms.Message responseMsg = msg.getBody();
try {
- // Operation name...
- String operationName =
responseMsg.getStringProperty(scaOperationName);
- for( Operation op : operations ) {
- if( operationName.equals(op.getName())) {
- msg.setOperation(op);
- break;
- } // end if
- } // end for
-
// Relates to header...
String relatesTo =
responseMsg.getStringProperty(RELATES_TO);
if( relatesTo != null ) {
Modified:
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderServiceInterceptor.java
URL:
http://svn.apache.org/viewvc/tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderServiceInterceptor.java?rev=1293172r1=1293171r2=1293172view=diff
==
---
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderServiceInterceptor.java
(original)
+++
tuscany/sca-java-2.x/trunk/modules/binding-jms-runtime/src/main/java/org/apache/tuscany/sca/binding/jms/headers/HeaderServiceInterceptor.java
Fri Feb 24 10:45:15 2012
@@ -77,8 +77,6 @@ public class HeaderServiceInterceptor ex
Operation operation = tuscanyMsg.getOperation();
String operationName = operation.getName();
-
- responseMessageProcessor.setOperationName(operationName, jmsMsg);
for (String propName : jmsBinding.getPropertyNames()) {
Object value = jmsBinding.getProperty(propName);
Hi Jennifer
I'm seeing an issue in itest/async-services which I think might be
related to this change. Let me run it by you
In the async case a response arriving back at the reference is
processed backwards along the reference change. When it goes in the
HeaderReferenceInterceptor the operation is not longer set on the
Message. The wire format interceptor, in my case
WireFormatJMSDefaultReferenceInterceptor, relies on operation being
set (it uses it to look up data type information) so fails with an
NPE.
So if we're not going to pass scaOperationName with the message we
need to find an alternative way of configuring the message object.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Assigned] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer
[ https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4018: --- Assignee: Simon Laws JMS TransportServiceInterceptor using wrong values to set JMS headers in producer - Key: TUSCANY-4018 URL: https://issues.apache.org/jira/browse/TUSCANY-4018 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Fix For: Java-SCA-2.x Attachments: Tuscany-4018.patch In TransportServiceInterceptor.invokeResponse is setting the effective TimeToLive, Priority in the response message, but when the values are set in the producer, the values from the request are used, potentially leading to an incorrect value. So the following: // Set jms header attributes in producer, not message. int deliveryMode = requestJMSMsg.getJMSDeliveryMode(); producer.setDeliveryMode(deliveryMode); int deliveryPriority = requestJMSMsg.getJMSPriority(); producer.setPriority(deliveryPriority); long timeToLive = requestJMSMsg.getJMSExpiration(); producer.setTimeToLive(timeToLive); Should be: // Set jms header attributes in producer, not message. producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode()); producer.setPriority(responseJMSMsg.getJMSPriority()); producer.setTimeToLive(responseJMSMsg.getJMSExpiration()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: TUSCANY-4005 is in error
On Tue, Feb 21, 2012 at 10:04 AM, Simon Laws simonsl...@googlemail.com wrote: On Mon, Feb 20, 2012 at 7:03 PM, Greg Dritschler greg.dritsch...@gmail.com wrote: I believe the fix for TUSCANY-4005 is in error. The goal of the fix was to comply with this requirement: The target component has multiple services. According to the following text in the assembly specification, the target component must have one and only one service with a compatible interface. 1844 If service-name is not present, the target component MUST have one and only 1845 one service with an interface that is a compatible superset of the wire source's 1845 interface and satisifies the policy requirements of the wire source, and the SCA 1846 runtime MUST use this service for the wire. [ASM60048] The fix checks if there are multiple candidate targets BEFORE DOING ANY FILTERING for interface compatibility or policy matching. If the target does have one and only one service with a compatible interface and policy, you now get the error introduced by the fix. This was not the intention. My mistake, let me switch the test around. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com Change applied at r1291714 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Closed] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer
[ https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4018. --- Resolution: Fixed Committed at revision: 1291715. Thanks for the patch Jennifer. JMS TransportServiceInterceptor using wrong values to set JMS headers in producer - Key: TUSCANY-4018 URL: https://issues.apache.org/jira/browse/TUSCANY-4018 Project: Tuscany Issue Type: Bug Components: Java SCA JMS Binding Extension Affects Versions: Java-SCA-2.x Reporter: Jennifer A Thompson Assignee: Simon Laws Fix For: Java-SCA-2.x Attachments: Tuscany-4018.patch In TransportServiceInterceptor.invokeResponse is setting the effective TimeToLive, Priority in the response message, but when the values are set in the producer, the values from the request are used, potentially leading to an incorrect value. So the following: // Set jms header attributes in producer, not message. int deliveryMode = requestJMSMsg.getJMSDeliveryMode(); producer.setDeliveryMode(deliveryMode); int deliveryPriority = requestJMSMsg.getJMSPriority(); producer.setPriority(deliveryPriority); long timeToLive = requestJMSMsg.getJMSExpiration(); producer.setTimeToLive(timeToLive); Should be: // Set jms header attributes in producer, not message. producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode()); producer.setPriority(responseJMSMsg.getJMSPriority()); producer.setTimeToLive(responseJMSMsg.getJMSExpiration()); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4017: --- Assignee: Simon Laws Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Assignee: Simon Laws Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211771#comment-13211771 ] Simon Laws commented on TUSCANY-4017: - At revision: 1291186 I added a test case which looks at how the exactlyOnce profile intent resolves to atLeastOnce and atMostOnce in the endpoint. I need a bit more information about where in the code you were looking for the resolved intents. Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Assignee: Simon Laws Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
[
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4016:
---
Assignee: Simon Laws
NodeImpl startComposite forgets about a composite if there is a failure on
start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of
the providers may have been started. So even in the failure case we should
consider the composite partially started so that it can be stopped correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Overriding remotable
On Mon, Feb 20, 2012 at 10:19 AM, Simon Nash n...@apache.org wrote:
Raymond Feng wrote:
Hi,
At that time, I was questioning the merit to introduce remotable
attribute in the composite to override the Java interface. Really, to make
the service remotable, the interface design has to take that into
consideration upfront, especially the data model (for example, DTO instead
of an Object).
The rationale for this is that some Java interfaces can't be modified to
add SCA annotations, perhaps because they're in some standard spec or a
pre-existing framework library. However, these interfaces may have been
designed to have remotable semantics (SCA didn't invent remotability!)
Simon
Thanks,
Raymond
On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws simonsl...@googlemail.com
mailto:simonsl...@googlemail.com wrote:
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
luckbr1...@gmail.com mailto:luckbr1...@gmail.com wrote:
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
simonsl...@googlemail.com mailto:simonsl...@googlemail.com wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld
remotable=true/
binding.ws/ http://binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When
Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to
fix
but it leads to a question. In some of the databinding code
there are
tests for remotable which prevents further processing if an
interface
is not remotable. For example, DataBindingjavaInterfaceProcessor
has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
http://tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://people.apache.org/%7Elresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.
I don't really understand Raymond's comment It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.
Simon
--
Apache Tuscany committer: tuscany.apache.org
http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
http
[jira] [Closed] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3459.
---
Resolution: Fixed
I applied the patch at revision: 1291191 which should provide a general
solution to this by allowing the interface remotable status to be overriden.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
[
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4016.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
At revision: 1291234 I committed a fix and a test. On closer inspection it
turns out that we added code to the Activator a while back to stop providers if
there is a failure on start. So the extra stop added here may not do anything
but it won't do any harm. Moving the stopped composite to the stopped list does
allow the unused contributions to be unloaded if the appropriate operation is
called.
NodeImpl startComposite forgets about a composite if there is a failure on
start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of
the providers may have been started. So even in the failure case we should
consider the composite partially started so that it can be stopped correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-2735) Testing case where interface extends other that use Generics
[ https://issues.apache.org/jira/browse/TUSCANY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-2735. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Patch applied to 2.x at revision: 1291283. Thanks Rodolfo. Testing case where interface extends other that use Generics Key: TUSCANY-2735 URL: https://issues.apache.org/jira/browse/TUSCANY-2735 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-1.3.2 Environment: Ubuntu, Tuscany SCA 1.3.2, jrockit_150_11 Reporter: Rodolfo Dias Assignee: Rodolfo Dias Priority: Minor Fix For: Java-SCA-2.0, Java-SCA-2.x Attachments: ServicesTest.diff, itest-services-1.3.2-JIRA-2735.jar, itest-services-1.3.2-src-jira-2735.jar Project itest-service not test case where interface extends other that use Generics. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3859) tuscany generated wsdl: namespace prefix for the attribute base is missing
[ https://issues.apache.org/jira/browse/TUSCANY-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3859. --- I believe this is fixed now as I applied the 1.x/TUSCANY-3298 fixes to 2.x and took the WSDL verify tests from 1.x and added them to the wsdlgen itest on 2.x. tuscany generated wsdl: namespace prefix for the attribute base is missing Key: TUSCANY-3859 URL: https://issues.apache.org/jira/browse/TUSCANY-3859 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.6.1 Reporter: Antonio De Berardis Assignee: Simon Nash Fix For: Java-SCA-1.x I have a problem when I let tuscany generate the wsdl for a service. Namespace prefix for the attribute base is missing. If I have an object that extends another object, the schema generated should be: ... xs:complexType name=myObjChild xs:complexContent xs:extension base=tns:myObj ... but i got ... xs:complexType name=myObjChild xs:complexContent xs:extension base=myObj ... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3838) PolicyHandler.afterInvoke() is skipped when AxisFault occurs
[ https://issues.apache.org/jira/browse/TUSCANY-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3838. --- I believe this is fixed now. The policy runtime is slightly different in 2.x when compared to 1.x. In 2.x we have policy interceptors on the operation wire and on the binding wire and the binding wire providers get the opportunity to configure the binding. In the exception case the exception, wrapped in a Message object, should flow back along the wire and through the interceptors in the same way as a non-exception response does. PolicyHandler.afterInvoke() is skipped when AxisFault occurs Key: TUSCANY-3838 URL: https://issues.apache.org/jira/browse/TUSCANY-3838 Project: Tuscany Issue Type: Improvement Components: Java SCA Policy Affects Versions: Java-SCA-1.6 Environment: Windows 2003. Reporter: Gang Yang Assignee: Simon Nash Fix For: Java-SCA-1.x Attachments: code-snippet.txt When AxisFault is generated from invoking a remote service using WS binding, the reference side PolicyHandler.afterInvoke() is not called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Overriding remotable
On Sat, Feb 18, 2012 at 7:25 PM, Raymond Feng enjoyj...@gmail.com wrote:
Hi,
At that time, I was questioning the merit to introduce remotable attribute
in the composite to override the Java interface. Really, to make the service
remotable, the interface design has to take that into consideration upfront,
especially the data model (for example, DTO instead of an Object).
Thanks,
Raymond
On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws simonsl...@googlemail.com
wrote:
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende luckbr1...@gmail.com
wrote:
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws simonsl...@googlemail.com
wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld
remotable=true/
binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld
looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.
I don't really understand Raymond's comment It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Ok, thanks Raymond
They went ahead and did it and it's now in the spec.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Updated] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws updated TUSCANY-3459:
Attachment: 3459.patch
General changes to make the infrastructure apply the remotable overide.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Overriding remotable
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende luckbr1...@gmail.com wrote:
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws simonsl...@googlemail.com wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld remotable=true/
binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld looks
like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.
I don't really understand Raymond's comment It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Question about wsdl.service and SOAP intent
On Thu, Feb 16, 2012 at 4:00 AM, Greg Dritschler
greg.dritsch...@gmail.com wrote:
For something that seems so simple, this is turning into a quagmire.
The web service binding processor is not the best place to test intents
because the builder obviously has not yet run and propagated intents down to
the binding. It would only be able to test the intent on the binding
itself.
The other option is to do the selection in the reference binding provider,
and actually it does happen that way now. By the point where the provider
gets control, the binding's port is null. Axis2ReferenceBindingProvider has
code to select the port. Unlike the web service binding provider, it
doesn't just pick the first. It gives preference to the first port with a
SOAP 1.1 address element, and it can't find one it takes the first SOAP 1.2
port.
How is the binding's port null in the provider if the processor previously
selected the first port? Well, WSDLServiceGenerator tests if the user WSDL
provided a port by calling binding.getPortName(). Since the binding model
is still marked unresolved, it returns null (this is wsdl.service so there
is no port name). This causes WSDLServiceGenerator to import all the
bindings and set the binding's port to null.
Why is the binding model still unresolved? Well, the processor's resolve
operation never marks it resolved.
So, if the provider already has to select the port, why not have it use the
SOAP intent to drive a selection? Well, when the binding processor selected
the first port, it set the binding uri to that port's address. Then when
WSDLServiceGenerator copies the ports over to the wrapper WSDL, it stores
the binding uri into the port address. So the address to use is clobbered.
Ok, let's change the binding processor to not select a port for wsdl.service
since the provider's going to choose it anyway. Well, when I tried this, I
got a NoSuchElementException in WebServiceBindingImpl.setIsDocumentStyle().
The binding is null, so it looks for the first WSDL Message in the
Definition to determine the document style. In my case the main WSDL
document has no Messages of its own but imports them from another file. I
suppose this is a problem that could be hit in other ways and I just got
unlucky.
I guess I can continue to poke away at this, but I'm beginning to wonder if
this functionality is worth the effort.
On Wed, Feb 15, 2012 at 12:53 PM, Simon Laws simonsl...@googlemail.com
wrote:
On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler
greg.dritsch...@gmail.com wrote:
When a web service binding uses wsdl.service, WebServiceBindingProcessor
picks the first port.
if (model.getPortName() != null) {
port =
service.getElement().getPort(model.getPortName());
} else {
// BWS20006 - no port specified so pick the
first
one
port =
(Port)service.getElement().getPorts().values().iterator().next();
}
What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it
pick a
port that uses a matching SOAP binding? The web services binding
specification says:
139 If the binding is for an SCA reference, the set of available ports
for
the reference consists of the
140 ports in the WSDL service that have portTypes which are compatible
supersets of the SCA
141 reference as defined in the SCA Assembly Model specification
[SCA-Assembly] and satisfy all
142 the policy constraints of the binding.
Greg
Sounds right to me.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
It sounds like that to get the WSDL gen to work properly the port has
to be selected before the provider runs. But it looks like this test
can't even be moved to the WebServiceBindingBuilder as that runs
before the CompositePolicyBuilder. Tricky.
The fix that first comes to mind based on what you've described is to
try and correct the WSDL gen piece so that it doesn't mess up the URL
so that there is a chance of performing the proper selection in the
provider.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Overriding remotable
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld remotable=true/
binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code there are
tests for remotable which prevents further processing if an interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Created] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
NodeImpl startComposite forgets about a composite if there is a failure on start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of the
providers may have been started. So even in the failure case we should consider
the composite partially started so that it can be stopped correctly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4015) JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name
[
https://issues.apache.org/jira/browse/TUSCANY-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4015.
---
Resolution: Fixed
Change comitted at r120. Thanks for the patch Vijai.
JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name
--
Key: TUSCANY-4015
URL: https://issues.apache.org/jira/browse/TUSCANY-4015
Project: Tuscany
Issue Type: Bug
Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Vijai Kalathur
Assignee: Simon Laws
Attachments: JIRA-4015.patch
The writeActivationSpecProperties method in JMSBindingProcessor uses wrong
attribute name for activationSpec. It should be using jndiName instead of
name.
if ( asName != null asName.length() 0) {
writer.writeAttribute(name, asName);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Question about wsdl.service and SOAP intent
On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler
greg.dritsch...@gmail.com wrote:
When a web service binding uses wsdl.service, WebServiceBindingProcessor
picks the first port.
if (model.getPortName() != null) {
port =
service.getElement().getPort(model.getPortName());
} else {
// BWS20006 - no port specified so pick the first
one
port =
(Port)service.getElement().getPorts().values().iterator().next();
}
What if the reference requires SOAP.v1_1 or SOAP.v1_2? Shouldn't it pick a
port that uses a matching SOAP binding? The web services binding
specification says:
139 If the binding is for an SCA reference, the set of available ports for
the reference consists of the
140 ports in the WSDL service that have portTypes which are compatible
supersets of the SCA
141 reference as defined in the SCA Assembly Model specification
[SCA-Assembly] and satisfy all
142 the policy constraints of the binding.
Greg
Sounds right to me.
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Closed] (TUSCANY-4011) Callback binding gets overriden and other issues
[ https://issues.apache.org/jira/browse/TUSCANY-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4011. --- Resolution: Fixed Closing as change was committed at rev1242412 Callback binding gets overriden and other issues Key: TUSCANY-4011 URL: https://issues.apache.org/jira/browse/TUSCANY-4011 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding. In trying to work out what was going on here I noticed a couple of other things that I'd like to improve: - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it -- Key: TUSCANY-4013 URL: https://issues.apache.org/jira/browse/TUSCANY-4013 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 The BindingURIBuilder overwrites any URI provided by the user so I propose to add a new field to binding (userSpecifiedURI) to hold what the user originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it
[ https://issues.apache.org/jira/browse/TUSCANY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13206168#comment-13206168 ] Simon Laws commented on TUSCANY-4013: - I've just noticed that the binding model is all over the pace in terms of what extended what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. I wanted this fix for binding.ws so I'll fix that first and raise a separate JIRA to tidy up the binding models. Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it -- Key: TUSCANY-4013 URL: https://issues.apache.org/jira/browse/TUSCANY-4013 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 The BindingURIBuilder overwrites any URI provided by the user so I propose to add a new field to binding (userSpecifiedURI) to hold what the user originally typed in. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4014) Tidy up the binding model hierarchy
Tidy up the binding model hierarchy --- Key: TUSCANY-4014 URL: https://issues.apache.org/jira/browse/TUSCANY-4014 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 As per TUSCANY-4013 the binding model is all over the pace in terms of what extends what. We seem to have two base implementations, BindingImpl and BaseBindingImpl, and very few binding models choose to extend them for some reason. Would be good to tidy this up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13204341#comment-13204341 ] Simon Laws commented on TUSCANY-3924: - I'm seeing the same Raymond. I don't think my approach is good so am about to revert some of it. I had a chat offline with Mike Edwards and I think we need to rethink the interpretation of the spec (which is not clear in this area) as I'm feeling uncomfortable about the code ignoring base class information. Inherited fields in service impl classes are treated as Properties -- Key: TUSCANY-3924 URL: https://issues.apache.org/jira/browse/TUSCANY-3924 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Vijai Kalathur Assignee: Simon Laws Fix For: Java-SCA-2.x In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties. Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tuscany board report is due
On Tue, Feb 7, 2012 at 11:44 AM, ant elder ant.el...@gmail.com wrote: The Tuscany board report is due this week, i'll prepare a draft but let me know if there is something you want mentioned. ...ant The only thing that comes to mind is the addition of a committer. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Created] (TUSCANY-4011) Callback binding gets overriden and other issues
Callback binding gets overriden and other issues Key: TUSCANY-4011 URL: https://issues.apache.org/jira/browse/TUSCANY-4011 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've noticed that any callback binding configuration provided in the SCDL is not present when the binding is used. It's because the binding is overridden by the callback endpoint created by the service binding. Only the URI is required so we can take this out of the binding created by the service binding and set it on the callback binding. In trying to work out what was going on here I noticed a couple of other things that I'd like to improve: - The code here is complicated by the thought that a single CallbackServiceReference might be used to contact multiple callback endpoints. This is no longer the case. For STATELESS components a new set of callback proxies (and hence CallbackServiceReference) is created for each new incoming message, because that's what happens with STATELESS components. For COMPOSITE components a new callback proxy is created for each call through the RequestContext object. Hence there is always a new CallbackServiceReference instance for each incoming call and related callback target. I believe the current complexity can be removed so that the CallbackServiceReference only every refers to one callback endpoint - There is an opportunity for further optimization if a binding is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. This need a bit of thought so I'll open a separate JIRA for it when I get to looking at it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3932. --- Resolution: Fixed Am closing this now as I think the specific issue is solved. I've opened TUSCANY-4011 as a follow up with some other callback issues/improvements Callbacks don't work in the distributed domain -- Key: TUSCANY-3932 URL: https://issues.apache.org/jira/browse/TUSCANY-3932 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 The callback wire calculation currently requires knowledge of the service runtime. This will not be available in the distributed case where the Endpoint matched by and retrieved from the registry will not have a built runtime behind it. We need to refactor this based on the configuration available in the SCDL written to represent a remote Endpoint. Of particular interest is callback bindings that are generated vs callback bindings that are specified by the user. If a user specifies a binding this should automatically be available in the reference node as it will be written be default when the Endpoint is written out. Automatically generated callback bindings, usually generated to match the forward binding, won't be in that list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4012) Callback performance improvement
Callback performance improvement Key: TUSCANY-4012 URL: https://issues.apache.org/jira/browse/TUSCANY-4012 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Separating this out from TUSCANY-4011 - There is an opportunity to optimize callbacks if a binding implementation is prepared to be responsible for resetting it's reference target address in the callback case. For example, if we provide a field in the forward message where a service binding can place the callback URI then we can remove the EPR clone in the CallbackServiceReference and have the callback reference binding take the target address out of the callback message. The address will have to be cached in the CallbackServiceReference (or close by) so that when the callback message is sent the URI can be transmitted to the callback reference binding implementation which can then set/reset the target URI. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Another 2.x beta release
On Mon, Feb 6, 2012 at 9:21 AM, ant elder ant.el...@gmail.com wrote: I'd like to get some of the 2.x changes since beta3 out in a release so am thinking about doing a beta4 release. Does anyone have anything coming up they would like the release to wait for, if not I'd like to start soon. I'm suggesting beta4 as I don't think the current trunk is quite ready for a 2.0 final and i expect it might take a little while to get it up to scratch and i'd like a new release sooner. I'd be happy to help start working towards the 2.0 release as well though if anyone else has time for that as well. ...ant Sounds good. It's been a long time since the last Beta and doing another one before 2.0 will give us a chance to get back into the swing of doing a release. Is this you offering to RM a beta4? Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Another 2.x beta release
On Mon, Feb 6, 2012 at 3:05 PM, ant elder antel...@apache.org wrote: On Mon, Feb 6, 2012 at 2:58 PM, Simon Laws simonsl...@googlemail.com wrote: On Mon, Feb 6, 2012 at 9:21 AM, ant elder ant.el...@gmail.com wrote: I'd like to get some of the 2.x changes since beta3 out in a release so am thinking about doing a beta4 release. Does anyone have anything coming up they would like the release to wait for, if not I'd like to start soon. I'm suggesting beta4 as I don't think the current trunk is quite ready for a 2.0 final and i expect it might take a little while to get it up to scratch and i'd like a new release sooner. I'd be happy to help start working towards the 2.0 release as well though if anyone else has time for that as well. ...ant Sounds good. It's been a long time since the last Beta and doing another one before 2.0 will give us a chance to get back into the swing of doing a release. Is this you offering to RM a beta4? Yes, though I'm not so keen on the RM label any more, especially so after some of the recent discussion on the Incubator mailing lists. Most releases are a team effort and build on the work of others. I will though be proactively trying to get it done but also happy to have anyone else help. ...ant Point taken. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [NOTICE] Jennifer Thompson voted as a Tuscany Committer
On Fri, Feb 3, 2012 at 11:32 PM, Raymond Feng enjoyj...@gmail.com wrote: Welcome on board, Jennifer! Raymond On Feb 3, 2012, at 1:30 AM, ant elder wrote: The Tuscany PMC have voted to make Jennifer a Tuscany committer in recognition of all the patches submitted, particularly for the JMS binding. Congratulations and welcome Jennifer! ...ant Congrats Jennifer. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: Jenkins build became unstable: Tuscany-2x #524
On Fri, Feb 3, 2012 at 1:17 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: See https://builds.apache.org/job/Tuscany-2x/524/changes Hmmm, seems that I messed up some changes. Am looking. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Closed] (TUSCANY-4005) Ambiguous wire target is not reported as an error
[ https://issues.apache.org/jira/browse/TUSCANY-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4005. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Change committed at revision: 1239597 Ambiguous wire target is not reported as an error - Key: TUSCANY-4005 URL: https://issues.apache.org/jira/browse/TUSCANY-4005 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor Fix For: Java-SCA-2.0 I have a component reference with a target that includes only a component name. reference name=xyz target=MultipleServiceComponent/ The target component has multiple services. According to the following text in the assembly specification, the target component must have one and only one service with a compatible interface. 1844 If service-name is not present, the target component MUST have one and only 1845 one service with an interface that is a compatible superset of the wire source's 1845 interface and satisifies the policy requirements of the wire source, and the SCA 1846 runtime MUST use this service for the wire. [ASM60048] This implies to me that if there are multiple services with compatible interfaces, I should get an error. This does not happen. Instead the first match is taken. It's unclear to me why there needs to be only one match. If there are multiple matches that satisfy the interface and the policy requirements, it seems like using any of the matches is just as good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-4007) Mutliple delegations for binding.sca
[ https://issues.apache.org/jira/browse/TUSCANY-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-4007: Attachment: delegation-v2.patch Updates to the original patch. Putting here for backup. Am going off this approach a little as it's got a bit more complicated. Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: delegation-v2.patch, delegation.patch I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4005) Ambiguous wire target is not reported as an error
[ https://issues.apache.org/jira/browse/TUSCANY-4005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4005: --- Assignee: Simon Laws Ambiguous wire target is not reported as an error - Key: TUSCANY-4005 URL: https://issues.apache.org/jira/browse/TUSCANY-4005 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-2.0 Reporter: Greg Dritschler Assignee: Simon Laws Priority: Minor I have a component reference with a target that includes only a component name. reference name=xyz target=MultipleServiceComponent/ The target component has multiple services. According to the following text in the assembly specification, the target component must have one and only one service with a compatible interface. 1844 If service-name is not present, the target component MUST have one and only 1845 one service with an interface that is a compatible superset of the wire source's 1845 interface and satisifies the policy requirements of the wire source, and the SCA 1846 runtime MUST use this service for the wire. [ASM60048] This implies to me that if there are multiple services with compatible interfaces, I should get an error. This does not happen. Instead the first match is taken. It's unclear to me why there needs to be only one match. If there are multiple matches that satisfy the interface and the policy requirements, it seems like using any of the matches is just as good. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4007) Mutliple delegations for binding.sca
Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-4007) Mutliple delegations for binding.sca
[ https://issues.apache.org/jira/browse/TUSCANY-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-4007: Attachment: delegation.patch Mutliple delegations for binding.sca Key: TUSCANY-4007 URL: https://issues.apache.org/jira/browse/TUSCANY-4007 Project: Tuscany Issue Type: Improvement Components: SCA Java Runtime Affects Versions: Java-SCA-2.x Environment: All Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: delegation.patch I've come across a situation where I'd like to support multiple remote delegations for a single binding.sca instance. This came up because I was looking at a situation where I wanted to support reliable and non-reliable comms at the same time so thought I would experiment with delegating to different underlying binding implementations. Currently the code doesn't allow you to do that as it assumes a local delegation and a single remote delegation are represented by the single binding.sca instance take from the component model. I've attached a patch with a fix to make this work. It creates a new endpoint for each required delegation. Am going to raise on the dev list before committing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Multiple binding.sca delegations
I just opened TUSCANY-4007 which talks about updating the 2.x code to allow binding.sca to have multiple remote binding delegations active at the same time. Because the binding type has an impact on the wire (in particular the binding contract and hence the databinding) this implies creating a new endpoint for each binding.sca/delegation pair. The implication for the code is that there are a number of places where we assume and check that each component/service/binding only has a single endpoint. I've made some changes to relax this restriction specifically for binding.sca. A positive side effect will likely be that we can make the local binding implementation much clearer. Rather than jumping round the side of the databinding of the remote service wire we can have an endpoint dedicated to the local optimization. This is only applicable to the service side which has to be ready and listening for incoming messages. On the reference side it just picks the single delegation that matches the service that it's wired to. It will just pick the first local or remote one as appropriate but I guess you could write a special mapper that did something different. Anyhow I'm opening this thread in case people can think of any general problems that I might not have considered. I get a clean local build with the patch attached to the JIRA but there are still a few changes I need to make so I haven't committed it yet. [1] https://issues.apache.org/jira/browse/TUSCANY-4007 Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Assigned] (TUSCANY-4006) Intent transactedOneWay with an interface that has both one-way and two-way methods should be allowed
[ https://issues.apache.org/jira/browse/TUSCANY-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4006: --- Assignee: Simon Laws Intent transactedOneWay with an interface that has both one-way and two-way methods should be allowed - Key: TUSCANY-4006 URL: https://issues.apache.org/jira/browse/TUSCANY-4006 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.0-M1 Environment: All Reporter: Hasan Muhammad Assignee: Simon Laws Fix For: Java-SCA-2.x This is a bug in CompositePolicyBuilderImpl.validateTransactionIntents(). It is failing the use of transactedOneWay with an interface that has both one-way and two-way methods. This is allowed; transactedOneWay applies only to the one-way methods. (It's conceptually the same as propagatesTransaction, which by definition applies to the two-way methods and is ignored for one-way methods.) The check should be deleted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
[ https://issues.apache.org/jira/browse/TUSCANY-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-3910: --- Assignee: Simon Laws (was: Scott Kurz) 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: Simon Laws 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
[ https://issues.apache.org/jira/browse/TUSCANY-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3910. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Reversed the order of the processors and applied changes similar to those from TUSCANY-3804 at revision: 1229088 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: Simon Laws Fix For: Java-SCA-2.0 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models
[
https://issues.apache.org/jira/browse/TUSCANY-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4004.
---
Resolution: Fixed
At revision: 1229110 I made a small change to maintain the coherence of WSDL
URI and location for imported WSDL documents.
WSDL import handling creates definitions where the URI is set to the location
which is different from the top level models
--
Key: TUSCANY-4004
URL: https://issues.apache.org/jira/browse/TUSCANY-4004
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.0
There is code in WSDLModelResolver.resolveImports()
if
(unresolved.getNamespace().equals(resolved.getDefinition().getTargetNamespace()))
{
resolved.setNamespace(resolved.getDefinition().getTargetNamespace());
resolved.setUnresolved(false);
resolved.setURI(resolved.getLocation());
return modelClass.cast(resolved);
That puts the absolute location in the (usually relative) URI field. This was
causing me some confusion when debugging another issue as the imported WSDL
definition was constructed differently form the top level WSDL definition. I
don't know whether the imported WSDL absolutely must have this URI file set
to the location or whether it's just that the contribution relative URI is
not readily available in the part of the code.
As an aside, while looking that this, I notices that in
WSDLModelResolver.loadDefinition() there is a loop over the imports in order
to resolve the WSDLDefinition. All the unresolved definitions are represented
by the same WSDLDefinition object and the unresolved object becomes the
resolved object. This is likely to end in tears if there is more than one
import.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models
[
https://issues.apache.org/jira/browse/TUSCANY-4004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4004:
---
Assignee: Simon Laws
WSDL import handling creates definitions where the URI is set to the location
which is different from the top level models
--
Key: TUSCANY-4004
URL: https://issues.apache.org/jira/browse/TUSCANY-4004
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.0
There is code in WSDLModelResolver.resolveImports()
if
(unresolved.getNamespace().equals(resolved.getDefinition().getTargetNamespace()))
{
resolved.setNamespace(resolved.getDefinition().getTargetNamespace());
resolved.setUnresolved(false);
resolved.setURI(resolved.getLocation());
return modelClass.cast(resolved);
That puts the absolute location in the (usually relative) URI field. This was
causing me some confusion when debugging another issue as the imported WSDL
definition was constructed differently form the top level WSDL definition. I
don't know whether the imported WSDL absolutely must have this URI file set
to the location or whether it's just that the contribution relative URI is
not readily available in the part of the code.
As an aside, while looking that this, I notices that in
WSDLModelResolver.loadDefinition() there is a loop over the imports in order
to resolve the WSDLDefinition. All the unresolved definitions are represented
by the same WSDLDefinition object and the unresolved object becomes the
resolved object. This is likely to end in tears if there is more than one
import.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reopened TUSCANY-3924: - Reopening as I didn't answer the JSR250 question Inherited fields in service impl classes are treated as Properties -- Key: TUSCANY-3924 URL: https://issues.apache.org/jira/browse/TUSCANY-3924 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Vijai Kalathur Fix For: Java-SCA-2.x In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties. Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties
[ https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-3924: --- Assignee: Simon Laws Inherited fields in service impl classes are treated as Properties -- Key: TUSCANY-3924 URL: https://issues.apache.org/jira/browse/TUSCANY-3924 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-2.x Reporter: Vijai Kalathur Assignee: Simon Laws Fix For: Java-SCA-2.x In the scenario where the Service impl class extends a class which has no SCA annotations in it, protected fields in the base class are interpreted like Properties. Ideally, only the fields in the impl class should be introspected for References/Properties. The fields in the base class should not be interpreted as References/Properties if there are no SCA annotations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models
WSDL import handling creates definitions where the URI is set to the location
which is different from the top level models
--
Key: TUSCANY-4004
URL: https://issues.apache.org/jira/browse/TUSCANY-4004
Project: Tuscany
Issue Type: Improvement
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Priority: Minor
Fix For: Java-SCA-2.0
There is code in WSDLModelResolver.resolveImports()
if
(unresolved.getNamespace().equals(resolved.getDefinition().getTargetNamespace()))
{
resolved.setNamespace(resolved.getDefinition().getTargetNamespace());
resolved.setUnresolved(false);
resolved.setURI(resolved.getLocation());
return modelClass.cast(resolved);
That puts the absolute location in the (usually relative) URI field. This was
causing me some confusion when debugging another issue as the imported WSDL
definition was constructed differently form the top level WSDL definition. I
don't know whether the imported WSDL absolutely must have this URI file set to
the location or whether it's just that the contribution relative URI is not
readily available in the part of the code.
As an aside, while looking that this, I notices that in
WSDLModelResolver.loadDefinition() there is a loop over the imports in order to
resolve the WSDLDefinition. All the unresolved definitions are represented by
the same WSDLDefinition object and the unresolved object becomes the resolved
object. This is likely to end in tears if there is more than one import.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding
[ https://issues.apache.org/jira/browse/TUSCANY-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181245#comment-13181245 ] Simon Laws commented on TUSCANY-3910: - In the code currently these two visitors are configured as follows: org.apache.tuscany.sca.core.databinding.processor.WrapperJavaInterfaceProcessor;ranking=200 org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor;ranking=100 They are used in descending order so the WrapperJavaInterfaceProcessor will always run before JAXWSJavaInterfaceProcessor. My first suggestion would be to swap this order and see if this improves things. 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4000) WS binding: ClassCastException: org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible with org.apache.tuscany.sca.interfacedef.java.JavaInterface
[
https://issues.apache.org/jira/browse/TUSCANY-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4000.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
Fix committed at revision: 1228143
WS binding: ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
Key: TUSCANY-4000
URL: https://issues.apache.org/jira/browse/TUSCANY-4000
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-2.0-Beta3
Reporter: Rashmi Hunt
Assignee: Simon Laws
Fix For: Java-SCA-2.0
WS Binding reference with WSDL interface with a WSDL callback interface
---invoking--- WS Binding Service with WSDL interface with a WSDL callback
interface
throws ClassCastException when Tuscany tries to cast WSDLInterfaceImpl to
JavaInterface
at JavaImplementationInvoker.invoke() method, at
(JavaInterface)interfaze.getCallbackInterface()
// If there is a callback interface and the implementation is
stateless, we need to
// inject callbacks at invocation time. For Composite scope, this
has already been done.
if (( interfaze.getCallbackInterface() != null )
(scopeContainer.getScope().equals(Scope.STATELESS))){
injectCallbacks(wrapper,
(JavaInterface)interfaze.getCallbackInterface());
}
This exception occurs when Web Service message reaches service implementation
which eventually invokes
JavaImplementationInvoker.invoke()
The above code is assuming that interfaze.getCallbackInterface() will return
instance of JavaInterface.
What if the callback interface on both service and reference are using WSDL
interface?
Shouldn't above logic take care of WSDL interface case?
Exception stack,
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:117)
...
at
org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:58)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:126)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:109)
at
org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:328)
components,
component name=MyComponent
implementation.java class=samples.MyServiceImpl/
service name=MyService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws name=MyServiceCallback/
/callback
/service
/component
component name=MySummaryService
implementation.java class=samples.MySummaryServiceImpl/
reference name=myService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.binding(MyServiceCallback)/
/callback
/reference
/component
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TUSCANY-4003) Allow ResourceHost to be specified
[ https://issues.apache.org/jira/browse/TUSCANY-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-4003. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Thanks for the patch Brian. I made a small change by moving the ResourceHost impl into implementation-java rather than interface-java. Committed at revision: 1228143 Allow ResourceHost to be specified --- Key: TUSCANY-4003 URL: https://issues.apache.org/jira/browse/TUSCANY-4003 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Brian Sullivan Assignee: Simon Laws Fix For: Java-SCA-2.0 Attachments: patches.zip Allow ResourceHost to be specified for SDO Helper Context resource injection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13181260#comment-13181260 ] Simon Laws commented on TUSCANY-3932: - Following on from my first comment I've made some initial changes at revision: 1228150 to make the handling of callbacks more consistent in the code as it stands at the moment. These are. Make the sca binding retain it's original URI rather than overwriting with the delegate URI (I've added some more fields to hold the delegate info) Have the delegate WS binding detect when it is delegating and pass the sca binding URI for callbacks in this case. In this was the callback code at the service can use the usual SCA endpoint lookup process to satisfy the callback reference. Make the JMS binding use the From EPR-CallbackEP model to transfer the callback binding infro into the infrastructure. This simplifies the CallbackServiceReference somewhat. Callbacks don't work in the distributed domain -- Key: TUSCANY-3932 URL: https://issues.apache.org/jira/browse/TUSCANY-3932 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 The callback wire calculation currently requires knowledge of the service runtime. This will not be available in the distributed case where the Endpoint matched by and retrieved from the registry will not have a built runtime behind it. We need to refactor this based on the configuration available in the SCDL written to represent a remote Endpoint. Of particular interest is callback bindings that are generated vs callback bindings that are specified by the user. If a user specifies a binding this should automatically be available in the reference node as it will be written be default when the Endpoint is written out. Automatically generated callback bindings, usually generated to match the forward binding, won't be in that list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4003) Allow ResourceHost to be specified
[ https://issues.apache.org/jira/browse/TUSCANY-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4003: --- Assignee: Simon Laws Allow ResourceHost to be specified --- Key: TUSCANY-4003 URL: https://issues.apache.org/jira/browse/TUSCANY-4003 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0 Reporter: Brian Sullivan Assignee: Simon Laws Attachments: patches.zip Allow ResourceHost to be specified for SDO Helper Context resource injection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TUSCANY-3932) Callbacks don't work in the distributed domain
[ https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13179567#comment-13179567 ] Simon Laws commented on TUSCANY-3932: - I've been looking at this an I also note that there is code in the CallbackServiceReference that resets the binding on the original callback endpoint reference rather than the cloned version which doesn't sound right. Also after the clone the binding provider isn't reset so in effect the binding provider, and associated wires, are shared between all callback references for a particular component. I suspect that this will cause problems for concurrent requests to the component. Callbacks don't work in the distributed domain -- Key: TUSCANY-3932 URL: https://issues.apache.org/jira/browse/TUSCANY-3932 Project: Tuscany Issue Type: Bug Components: SCA Java Runtime Affects Versions: Java-SCA-2.0-Beta3 Environment: All Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 The callback wire calculation currently requires knowledge of the service runtime. This will not be available in the distributed case where the Endpoint matched by and retrieved from the registry will not have a built runtime behind it. We need to refactor this based on the configuration available in the SCDL written to represent a remote Endpoint. Of particular interest is callback bindings that are generated vs callback bindings that are specified by the user. If a user specifies a binding this should automatically be available in the reference node as it will be written be default when the Endpoint is written out. Automatically generated callback bindings, usually generated to match the forward binding, won't be in that list and won't get written out so we need to address that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TUSCANY-4000) WS binding: ClassCastException: org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible with org.apache.tuscany.sca.interfacedef.java.JavaInterfac
[
https://issues.apache.org/jira/browse/TUSCANY-4000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4000:
---
Assignee: Simon Laws
WS binding: ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
Key: TUSCANY-4000
URL: https://issues.apache.org/jira/browse/TUSCANY-4000
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-2.0-Beta3
Reporter: Rashmi Hunt
Assignee: Simon Laws
WS Binding reference with WSDL interface with a WSDL callback interface
---invoking--- WS Binding Service with WSDL interface with a WSDL callback
interface
throws ClassCastException when Tuscany tries to cast WSDLInterfaceImpl to
JavaInterface
at JavaImplementationInvoker.invoke() method, at
(JavaInterface)interfaze.getCallbackInterface()
// If there is a callback interface and the implementation is
stateless, we need to
// inject callbacks at invocation time. For Composite scope, this
has already been done.
if (( interfaze.getCallbackInterface() != null )
(scopeContainer.getScope().equals(Scope.STATELESS))){
injectCallbacks(wrapper,
(JavaInterface)interfaze.getCallbackInterface());
}
This exception occurs when Web Service message reaches service implementation
which eventually invokes
JavaImplementationInvoker.invoke()
The above code is assuming that interfaze.getCallbackInterface() will return
instance of JavaInterface.
What if the callback interface on both service and reference are using WSDL
interface?
Shouldn't above logic take care of WSDL interface case?
Exception stack,
Caused by: java.lang.ClassCastException:
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible
with org.apache.tuscany.sca.interfacedef.java.JavaInterface
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:117)
...
at
org.apache.tuscany.sca.core.invocation.InterceptorAsyncImpl.invoke(InterceptorAsyncImpl.java:58)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:126)
at
org.apache.tuscany.sca.core.invocation.RuntimeInvoker.invoke(RuntimeInvoker.java:109)
at
org.apache.tuscany.sca.core.assembly.impl.RuntimeEndpointImpl.invoke(RuntimeEndpointImpl.java:328)
components,
component name=MyComponent
implementation.java class=samples.MyServiceImpl/
service name=MyService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws name=MyServiceCallback/
/callback
/service
/component
component name=MySummaryService
implementation.java class=samples.MySummaryServiceImpl/
reference name=myService
interface.wsdl
interface=http://www.mybank.com/account#wsdl.interface(MyService)
callbackInterface=http://www.mybank.com/account#wsdl.interface(MyServiceCallback)
/
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)
/
callback
binding.ws
wsdlElement=http://www.mybank.com/account#wsdl.binding(MyServiceCallback)/
/callback
/reference
/component
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TUSCANY-3882) Are there any changes in 1.x that we still need to apply to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-3882: Attachment: edited-list-2.txt Here's a list based on the revisions made to 1.x after the 2.x branch was taken. I've taken a pass through this list (hence the -2 suffix) and removed what seem to have been applied to 2.x already. It may be that the majority of the changes in this list are not required for 2.x we just need to go through an check. Are there any changes in 1.x that we still need to apply to 2.x --- Key: TUSCANY-3882 URL: https://issues.apache.org/jira/browse/TUSCANY-3882 Project: Tuscany Issue Type: Improvement Affects Versions: Java-SCA-2.0-M5 Reporter: Simon Laws Fix For: Java-SCA-2.0 Attachments: edited-list-2.txt I don't know this to be true but I'm wondering if there are still changes in 1.x that we need in 2.x. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Happy new year to one an all!
Hope you all had a restful holiday. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Callback fixes
I'm trying to knock off a couple of long(ish) standing JIRA around callbacks. I was looking in the code and noticed some TODOs I had left there previously. I've taken a look at the code and here are some issues and patterns that we need to fix and enforce. The first three are related to TUSCANY-3932. I have a feeling there is a JIRA for the last one two but I haven't looked yet. - The URI of the top level (non delegate binding.sca model) should represent what was set in the SCDL so that it can 1/ be re-written accurately and 2/ so that it can be used in the callback scenario and be transported across the wire in the case where we want to look up the callback endpoint at the service side. This is not the case at the moment as binding.sca uri is reset to the delegate uri. The delegate uri is required when binding.sca is resolved via the registry and we want to configure the reference binding with configuration from the service. The solution here is, I think, to store both pieces of information in the binding.sca model and make sure that they are serialized correctly. - Absolute uris that arrive as callback addresses should be dealt with in the service binding. I.e. the service binding should be responsible for callback binding configuration based on binding specific callback headers. This is mostly the case already I think. There is some commented out code that I added that suggests there might be an alternative approach but I'm going to remove that unused code now - The passing of callback binding configuration from the service binding to the CallbackServiceReferenceImpl that uses currently relies on the creation of a EPR-EP structure that mirrors the structure that is available in the local version of binding.sca. I've heard comments that this seems quite complicated. An option is to have the service binding just create the callback binding and pass this along in the message header. - Callback endpoints registered in the registry can be confused for forward endpoints when the component name only form of the reference target URI is used. I think we need to be able to make an endpoint as representing a callback so we can distinguish between forward and callback endpoints when matching. I'll start to rough outs some changes. Any comments. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Reopened] (TUSCANY-3890) Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x
[ https://issues.apache.org/jira/browse/TUSCANY-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reopened TUSCANY-3890: - Assignee: Simon Laws I've had a change of heart about this and I've gone ahead and ported the changes to separate the request and response wrapper info. I'll commit shortly. Port TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms to 2.x - Key: TUSCANY-3890 URL: https://issues.apache.org/jira/browse/TUSCANY-3890 Project: Tuscany Issue Type: Sub-task Components: SCA Java Runtime Reporter: Simon Laws Assignee: Simon Laws Fix For: Java-SCA-2.0 TUSCANY-2931 Allow for separate request and response wireFormats in binding.jms was added to 1.x after the 2.x branch was taken. Needs porting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
