Re: Tuscany Support

[Simon Laws]

I have to say that I've not heard of any Luciano.

Simon


On Sun, Nov 10, 2013 at 11:10 PM, Luciano Resende wrote:

> 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.

[Simon Laws]

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 wrote:

> 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

[Simon Laws]

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://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

[Simon Laws]

On Wed, Nov 14, 2012 at 7:38 AM, Jean-Sebastien Delfino
 wrote:
> On Mon, Nov 12, 2012 at 10:04 PM, Luciano Resende 
> 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

[Simon Laws]

On Sun, Jun 24, 2012 at 10:58 AM, Nirmal Fernando
 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  wrote:
>>
>> Well +1 from me anyway, would anyone else have a vote?
>>
>>   ...ant
>>
>> On Tue, Jun 19, 2012 at 10:02 AM, ant elder  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

[Simon Laws]

On Fri, May 11, 2012 at 12:49 PM, ant elder  wrote:
> On Thu, May 10, 2012 at 6:31 PM, Luciano Resende  wrote:
>> On Tue, Apr 24, 2012 at 9:44 AM, Luciano Resende  
>> wrote:
>>> On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws  
>>> 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

[Simon Laws]

On Sat, Apr 28, 2012 at 9:57 AM, ant elder  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

[Simon Laws]

On Wed, Apr 25, 2012 at 9:32 PM, Simon Laws  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-scaclient>mvn 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.(java.net.URI, jav
a.util.Properties)
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 

Re: [VOTE] Release Tuscany SCA 2.0 RC1

[Simon Laws]

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

[Simon Laws]

On Tue, Apr 24, 2012 at 5:44 PM, Luciano Resende  wrote:
> On Tue, Apr 24, 2012 at 12:28 AM, Simon Laws  
> 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

[Simon Laws]

..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

[Simon Laws]

On Mon, Apr 23, 2012 at 9:57 PM, Raymond Feng  wrote:
> I tried on a different machine and the JMS related otest passed. Maybe it's a 
> timing issue waiting for the JMS response from the queue.
>
> I saw your problem too but it works on a different machine.
>
> The maven build is tricky :-(
>
> Thanks,
> Raymond
>
> On Apr 23, 2012, at 1:35 PM, Simon Laws wrote:
>
>> On Mon, Apr 23, 2012 at 7:25 PM, Raymond Feng  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  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

Re: [VOTE] Release Tuscany SCA 2.0 RC1

[Simon Laws]

On Mon, Apr 23, 2012 at 7:25 PM, Raymond Feng  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  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

[Simon Laws]

On Mon, Apr 16, 2012 at 8:15 AM, ant elder  wrote:
> Looks ok to me so +1.
>
>   ...ant
>
> On Thu, Apr 12, 2012 at 6:04 PM, ant elder  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] [Closed] (TUSCANY-4036) WSDL service names are duplicated when user does not provide WSDL

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4036) WSDL service names are duplicated when user does not provide WSDL

[Simon Laws (Assigned) (JIRA)]

 [ 
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-4035) Application could possibly fail to start if multiple threads are loading the same schema

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema

[Simon Laws (Assigned) (JIRA)]

 [ 
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-4032) Remote getService() lookup with only component name fails when target has a callback

[Simon Laws (Closed) (JIRA)]

 [ 
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
> 
> 
> 
>  interface="test.bindings.sca.intf.FrontendService"/>
> 
> 
>  target="SerializationBackendComponent">
>  interface="test.bindings.sca.intf.SerializeBackendService"
> callbackInterface="test.bindings.sca.intf.SerializeCallback"/>
> 
> 
> 
> 
> 
> 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-4032) Remote getService() lookup with only component name fails when target has a callback

[Simon Laws (Assigned) (JIRA)]

 [ 
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
> 
> 
> 
>  interface="test.bindings.sca.intf.FrontendService"/>
> 
> 
>  target="SerializationBackendComponent">
>  interface="test.bindings.sca.intf.SerializeBackendService"
> callbackInterface="test.bindings.sca.intf.SerializeCallback"/>
> 
> 
> 
> 
> 
> 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-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding

[Simon Laws (Closed) (JIRA)]

 [ 
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-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4033) Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Closed] (TUSCANY-4033) Interface matching code in EndpointReferenceBinderImpl fails doing a wsdlgen

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Commented] (TUSCANY-4035) Application could possibly fail to start if multiple threads are loading the same schema

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4030) AccessControlException when trying to read schemas with Java 2 security enabled

[Simon Laws (Closed) (JIRA)]

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

Simon Laws closed TUSCANY-4030.
---

   Resolution: Fixed
Fix Version/s: Java-SCA-2.0

Applied at revision: 1304257. Thanks for the patch Kaushik.

> 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
> Fix For: Java-SCA-2.0
>
> 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 
> PrivilegedExceptionAction() {
> 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.(ZipFile.java:145)
>   at java.util.jar.JarFile.(JarFile.java:149)
>   at java.util.jar.JarFile.(JarFile.java:86)
>   at sun.net.www.protocol.jar.URLJarFile.(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] [Assigned] (TUSCANY-4030) AccessControlException when trying to read schemas with Java 2 security enabled

[Simon Laws (Assigned) (JIRA)]

 [ 
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 
> PrivilegedExceptionAction() {
> 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.(ZipFile.java:145)
>   at java.util.jar.JarFile.(JarFile.java:149)
>   at java.util.jar.JarFile.(JarFile.java:86)
>   at sun.net.www.protocol.jar.URLJarFile.(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-4031) IntentNotSatisfiedAtBuild warning occurs when reference uses an intent provided by binding

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4034) More memory leak fixes

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Created] (TUSCANY-4034) More memory leak fixes

[Simon Laws (Created) (JIRA)]

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] [Closed] (TUSCANY-4028) Don't duplicate intents in Java implementation model

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Created] (TUSCANY-4028) Don't duplicate intents in Java implementation model

[Simon Laws (Created) (JIRA)]

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] [Assigned] (TUSCANY-4028) Don't duplicate intents in Java implementation model

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Closed] (TUSCANY-4027) EndpointFinder is ineffective

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4027) EndpointFinder is ineffective

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Commented] (TUSCANY-4026) XSDModelResolver fails to initiate WSDL model resolution for inline schemas

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

Re: JIRA-4206 XSDModelResolver fails to initiate WSDL model resolution for inline schemas

[Simon Laws]

On Thu, Mar 8, 2012 at 10:06 PM, Kaushik Mukherjee  wrote:
> I wanted to clarify the use case for JIRA-4206 a bit. The scenario I
> am looking at involves a WSDL with an inline schema. This inline
> schema is then referenced from another xsd through an import. The WSDL
> is not referenced in any other way such as through interface.wsdl. It
> is only indirectly referenced from the import of the inline schema
> namespace. Should we expect to add a model of the inline schema to the
> contribution in this scenario?
>
> Thanks,
> Kaushik

I had a feeling of deja vu about this and found TUSCANY-3709. Scott
never did get an answer to his question about the scope of inline XSD
in WSDL. I can't immediately find anything explicit about this via
Google. The WSDL spec [1] says "The types element encloses data type
definitions that are relevant for the exchanged messages." but that is
not very precise.

 I could imagine a user creating a contribution, stuffing a WSDL in
there with inline schemas, and then trying to reference the schema for
things like property descriptions without thought about whether those
schema are accessible.

It probably comes down to how we want to make it work and what we
think will be most useful for users. Unless someone can find better
information.

Simon

[1] http://www.w3.org/TR/wsdl

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

[jira] [Closed] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Created] (TUSCANY-4025) Give registry contribution listeners a chance to retireve the contribution info before removing it

[Simon Laws (Created) (JIRA)]

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] [Closed] (TUSCANY-3054) Introduce JavaInterfaceFactory impl employing caching of JavaInterface(s) based on Class

[Simon Laws (Closed) (JIRA)]

 [ 
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

[Simon Laws (Updated) (JIRA)]

 [ 
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

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-4020) Still some hard coded message strings in the code

[Simon Laws (Assigned) (JIRA)]

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

Simon Laws reassigned TUSCANY-4020:
---

Assignee: Simon Laws

> 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] [Created] (TUSCANY-4020) Still some hard coded message strings in the code

[Simon Laws (Created) (JIRA)]

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
 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

Re: Another 2.x beta release

[Simon Laws]

On Thu, Feb 16, 2012 at 5:45 PM, Luciano Resende  wrote:
> On Thu, Feb 16, 2012 at 7:06 AM, ant elder  wrote:
>> On Thu, Feb 9, 2012 at 11:50 PM, Luciano Resende  
>> wrote:
>>
>>>
>>> If I don't get them done by sunday night, then i don't want to hold this ...
>>>
>>
>> Turns out the internet where i am is slow and flaky and I'm not making
>> fast progress on this so no one needs to worry about holding anything
>> up for now.
>>
>>   ...ant
>
> Thanks for the updates, we have brought up the current trunk to our
> environment successfully, so I'm done with the bug fixing part.
> I'm still working on the policy archetype, but that's not a must.
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/

Shall I create a Java-SCA-2.0-Beta-4 to track what we want to get in.

In the hope that we will to a 2.0 release at some point we could try
and close down on some of the outstanding items that we've been
putting off and make 2.0 less painful?

Also, IIRC, we should be looking at CMS for the website. This will
likely be become more pressing if we want to make changes to the 2.0
pages.

Simon

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

[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[Simon Laws]

On Fri, Feb 24, 2012 at 10:45 AM,   wrote:
> Author: jennthom
> Date: Fri Feb 24 10:45:15 2012
> New Revision: 1293172
>
> URL: http://svn.apache.org/viewvc?rev=1293172&view=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=1293172&r1=1293171&r2=1293172&view=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=1293172&r1=1293171&r2=1293172&view=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] [Closed] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

[Simon Laws (Closed) (JIRA)]

 [ 
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

Re: TUSCANY-4005 is in error

[Simon Laws]

On Tue, Feb 21, 2012 at 10:04 AM, Simon Laws  wrote:
> On Mon, Feb 20, 2012 at 7:03 PM, Greg Dritschler
>  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  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] [Assigned] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

[Simon Laws (Assigned) (JIRA)]

 [ 
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

[Simon Laws]

On Mon, Feb 20, 2012 at 7:03 PM, Greg Dritschler
 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  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

[jira] [Closed] (TUSCANY-3838) PolicyHandler.afterInvoke() is skipped when AxisFault occurs

[Simon Laws (Closed) (JIRA)]

 [ 
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

[jira] [Closed] (TUSCANY-3859) tuscany generated wsdl: namespace prefix for the attribute "base" is missing

[Simon Laws (Closed) (JIRA)]

 [ 
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:
> ...
> 
> 
> 
> ...
> but i got
> ...
> 
> 
> 
> ...

--
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-3869) WSDL data types not generated correctly

[Simon Laws (Closed) (JIRA)]

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

Simon Laws closed TUSCANY-3869.
---

Resolution: Fixed

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.

> WSDL data types not generated correctly
> ---
>
> Key: TUSCANY-3869
> URL: https://issues.apache.org/jira/browse/TUSCANY-3869
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-2.0-Beta2
> Environment: All
>Reporter: David Cueva
>  Labels: axis2, jaxb, wsdl
> Fix For: Java-SCA-2.0
>
>
> When a @Remotable interface receives or returns a POJO, the WSDL generated 
> when using  is not valid.
> This limits the applicability of  to methods receiving or 
> returning primitive types or wrappers only.
> If the WSDL is loaded in SoapUI, the following error is thrown:
> Fri Jun 03 11:43:04 EDT 2011:WARN:Error: 
> http://localhost:8090/Registration?wsdl:0: error: src-resolve.a: Could not 
> find type 'conference@http://dc.simple/'. Do you mean to refer to the type 
> named conference (in Registration_3Fwsdl)?
> It seems that the namespace being used for the type definition is missing or 
> misplaced
> ---
> More information:
> Mail thread
> [http://mail-archives.apache.org/mod_mbox/tuscany-user/201106.mbox/%3cbanlktimh6bbuwucumea9ifx8wtyrdw0...@mail.gmail.com%3E]
> Sample project to reproduce the issue:
> [http://cid-6f107cd11157608a.office.live.com/self.aspx/Tuscany/02.SimpleWS.zip]
> The offending WSDL
> [http://cid-6f107cd11157608a.office.live.com/self.aspx/Tuscany/Registration.wsdl]
> Scott Kurz has indicated this is probably related to
> [https://issues.apache.org/jira/browse/TUSCANY-3298]
> Info on the 1.x issue already resolved
> [http://www.mail-archive.com/dev%40tuscany.apache.org/msg10002.html]
> ---
> Copy of the original mail thread
> Hi there
> I am building a composite using the Tuscany 2.0-Beta2, The composite includes 
> a single component with one service. After compiling, the contribution loads 
> in Tuscany with no issues. I can even open the WSDL in the browser, but when 
> trying to test the service I get the following exception in 
> SoapUI/AdarnaStorm/EclipseWTP:
> Fri Jun 03 11:43:04 EDT 2011:WARN:Error: 
> http://localhost:8090/Registration?wsdl:0: error: src-resolve.a: Could not 
> find type 'conference@http://dc.simple/'. Do you mean to refer to the type 
> named conference (in Registration_3Fwsdl)?
> I hit a wall with this problem, I have searched the web quite a lot but 
> nothing. It may be a trivial setting that I am overlooking in my code.
> Basically, the contribution is supposed to be a service to register for a 
> conference. It has three very simple classes, and the composite definition:
> // ---
> // The Conference POJO: Conference.java
> package simple.dc.model;
> public class Conference {
>   private int id;
>   private String topic;
>  
>   // Here getters and setters generated by Eclipse
> }
> // ---
> // The remotable interface: Registration.java
> package simple.dc;
> import org.oasisopen.sca.annotation.Remotable;
> import simple.dc.model.Conference;
> @Remotable
> public interface Registration {
>public int register(Conference conference);
> }
> // ---
> // The component implementation: RegistrationImpl.java
> package simple.dc.impl;
> import org.oasisopen.sca.annotation.Service;
> import simple.dc.Registration;
> import simple.dc.model.Conference;
> @Service(Registration.class)
> public class RegistrationImpl implements Registration {
>   @Override
>   public int register(Conference conference) {
> System.out.println("Registering for conference: " + 
> conference.getTopic());
> return 1234; //confirmation number
>   }
> }
> // ---
> // The composite: SimpleWS.composite
> 
> http://docs.oasis-open.org/ns/opencsa/sca/200912";
>   xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1";
>   name="SimpleWSComposite"
>   targetNamespace="http://dc.simple";>
>   
> 
> 
>http://localhost:8090/Registration"/>
> 
>   
>  
> 
> No errors or warnings during compilation. I am using Gradle with the 
> following dependencies:
> compile group: 'org.apac

[jira] [Closed] (TUSCANY-2735) Testing case where interface extends other that use Generics

[Simon Laws (Closed) (JIRA)]

 [ 
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-4016) NodeImpl startComposite forgets about a composite if there is a failure on start

[Simon Laws (Closed) (JIRA)]

 [ 
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-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite

[Simon Laws (Closed) (JIRA)]

 [ 
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();
> }
>   
>
>   
>remotable="true"/>
>uri="http://localhost:8085/VegetableCatalog"; />
> 
>
> 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

[Simon Laws]

On Mon, Feb 20, 2012 at 10:19 AM, Simon Nash  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 > <mailto:simonsl...@googlemail.com>> wrote:
>>
>>    On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
>>    mailto:luckbr1...@gmail.com>> wrote:
>>     > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
>>    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:
>>     >>
>>     >>    
>>     >>        
>>     >>        
>>     >>           >    remotable="true"/>
>>     >>           http://binding.ws/>>
>>
>>     >>        
>>     >>    
>>     >>
>>     >> 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;
>>     >>        }
>>     >>        List 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.ap

[jira] [Assigned] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start

[Simon Laws (Assigned) (JIRA)]

 [ 
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

[jira] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4017) Tuscany needs to process profile intents as in OSOA

[Simon Laws (Assigned) (JIRA)]

 [ 
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

Re: Overriding remotable

[Simon Laws]

On Sat, Feb 18, 2012 at 7:25 PM, 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).
>
> Thanks,
> Raymond
>
>
> On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws 
> wrote:
>>
>> On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende 
>> wrote:
>> > On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws 
>> > wrote:
>> >> In the OASIS spec you can override the remotable status of an
>> >> interface using the remotable flag on the interface element:
>> >>
>> >>    
>> >>        
>> >>        
>> >>           > >> remotable="true"/>
>> >>           
>> >>        
>> >>    
>> >>
>> >> 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;
>> >>        }
>> >>        List 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

Re: Overriding remotable

[Simon Laws]

On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende  wrote:
> On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws  wrote:
>> In the OASIS spec you can override the remotable status of an
>> interface using the remotable flag on the interface element:
>>
>>    
>>        
>>        
>>           
>>           
>>        
>>    
>>
>> 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;
>>        }
>>        List 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

[jira] [Updated] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite

[Simon Laws (Updated) (JIRA)]

 [ 
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();
> }
>   
>
>   
>remotable="true"/>
>uri="http://localhost:8085/VegetableCatalog"; />
> 
>
> 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

Overriding remotable

[Simon Laws]

In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:




   
   



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;
}
List 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

Re: Question about wsdl.service and SOAP intent

[Simon Laws]

On Thu, Feb 16, 2012 at 4:00 AM, Greg Dritschler
 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 
> wrote:
>>
>> On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler
>>  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

[jira] [Created] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start

[Simon Laws (Created) (JIRA)]

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

Re: Question about wsdl.service and SOAP intent

[Simon Laws]

On Wed, Feb 15, 2012 at 4:58 PM, Greg Dritschler
 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-4015) JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name

[Simon Laws (Closed) (JIRA)]

 [ 
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

[jira] [Assigned] (TUSCANY-4015) JMSBindingProcessor's writeActivationSpecProperties uses wrong attribute name

[Simon Laws (Assigned) (JIRA)]

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

Simon Laws reassigned TUSCANY-4015:
---

Assignee: Simon Laws

> 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

[jira] [Created] (TUSCANY-4014) Tidy up the binding model hierarchy

[Simon Laws (Created) (JIRA)]

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-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-4013) Can't tell what binding URI the user provided in the SCDL after the builder has run as the BindingURIBuilder overwrites it

[Simon Laws (Created) (JIRA)]

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] [Closed] (TUSCANY-4011) Callback binding gets overriden and other issues

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Commented] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-3924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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

[jira] [Created] (TUSCANY-4012) Callback performance improvement

[Simon Laws (Created) (JIRA)]

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

[jira] [Closed] (TUSCANY-3932) Callbacks don't work in the distributed domain

[Simon Laws (Closed) (JIRA)]

 [ 
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-4011) Callback binding gets overriden and other issues

[Simon Laws (Created) (JIRA)]

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

Re: Tuscany board report is due

[Simon Laws]

On Tue, Feb 7, 2012 at 11:44 AM, ant elder  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

Re: Another 2.x beta release

[Simon Laws]

On Mon, Feb 6, 2012 at 3:05 PM, ant elder  wrote:
> On Mon, Feb 6, 2012 at 2:58 PM, Simon Laws  wrote:
>> On Mon, Feb 6, 2012 at 9:21 AM, ant elder  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: Another 2.x beta release

[Simon Laws]

On Mon, Feb 6, 2012 at 9:21 AM, ant elder  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: [NOTICE] Jennifer Thompson voted as a Tuscany Committer

[Simon Laws]

On Fri, Feb 3, 2012 at 11:32 PM, Raymond Feng  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

[Simon Laws]

On Fri, Feb 3, 2012 at 1:17 AM, Apache Jenkins Server
 wrote:
> See 
>
>

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

[Simon Laws (Closed) (JIRA)]

 [ 
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.
> 
> 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  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] [Assigned] (TUSCANY-4005) Ambiguous wire target is not reported as an error

[Simon Laws (Assigned) (JIRA)]

 [ 
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.
> 
> 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  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

[Simon Laws (Updated) (JIRA)]

 [ 
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

Multiple binding.sca delegations

[Simon Laws]

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] [Updated] (TUSCANY-4007) Mutliple delegations for binding.sca

[Simon Laws (Updated) (JIRA)]

 [ 
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

[jira] [Created] (TUSCANY-4007) Mutliple delegations for binding.sca

[Simon Laws (Created) (JIRA)]

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] [Assigned] (TUSCANY-4006) Intent transactedOneWay with an interface that has both one-way and two-way methods should be allowed

[Simon Laws (Assigned) (JIRA)]

 [ 
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-3924) Inherited fields in service impl classes are treated as Properties

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Reopened] (TUSCANY-3924) Inherited fields in service impl classes are treated as Properties

[Simon Laws (Reopened) (JIRA)]

 [ 
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-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Closed] (TUSCANY-4004) WSDL import handling creates definitions where the URI is set to the location which is different from the top level models

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Closed] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Assigned] (TUSCANY-3910) Ensure that JAX-WS wrapper generation occurs before databinding introspection to avoid need for @RequestWrapper, etc. to set databinding

[Simon Laws (Assigned) (JIRA)]

 [ 
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] [Commented] (TUSCANY-3932) Callbacks don't work in the distributed domain

[Simon Laws (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (TUSCANY-4003) Allow ResourceHost to be specified

[Simon Laws (Closed) (JIRA)]

 [ 
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] [Closed] (TUSCANY-4000) WS binding: ClassCastException: org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLInterfaceImpl incompatible with org.apache.tuscany.sca.interfacedef.java.JavaInterface

[Simon Laws (Closed) (JIRA)]

 [ 
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,
> 
> 
> 
>  interface="http://www.mybank.com/account#wsdl.interface(MyService)" 
>   
> callbackInterface="http://www.mybank.com/account#wsdl.interface(MyServiceCallback)"
>  />
>   
>   
> wsdlElement="http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)"
>/>
>
>   
>
> 
> 
> 
>   
>   
>interface="http://www.mybank.com/account#wsdl.interface(MyService)" 
>   
> callbackInterface="http://www.mybank.com/account#wsdl.interface(MyServiceCallback)"
>  />
>  
>  wsdlElement="http://www.mybank.com/account#wsdl.port(MyService/MyServicePort)"
>  />
>  
>   wsdlElement="http://www.mybank.com/account#wsdl.binding(MyServiceCallback)"/>
>  
>   
> 

--
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