Greg Dritschler wrote:
The WirePostProcessor is passed a Wire from which it can find the
source and
target contract and the source and target URI. If it needs context
from the
SCDL that is not in the contracts, is the processor expected to look
up the
URIs in the component manager? That seems
Greg Dritschler wrote:
This is a bit of a nit. It appears that the
SCARuntime.getComponentContextdoes not work if the given component is
implemented by another composite.
For example SCARuntime.getComponentContext("CalculatorServiceComponent")
returns null when CalculatorServiceComponent has a co
Luciano Resende wrote:
You might be having a problem described by Greg in [1]
I'm not sure that the problem described here is related to [1]. [1]
talks about getting a null when trying to get a ComponentContext for a
component implemented by a composite.
Let me try answering some of your
Luciano Resende wrote:
A few thoughts:
- You need the URI of an artifact inside the SCA contribution.
- I indicated before that I needed input/outputStreams as well.
- I think it's useful to have the URL of the contribution to have a base
URL to load artifacts (for example for WSDLs and XSDs if t
Ignacio Silva-Lepe wrote:
I am curious about these samples. In particular, helloworld-ws
defines a HelloWorldServer class with a main method that
seems to be invocable as standalone.
Yes, it is invocable as standalone, it's a simple Java program with a
main method.
Also, the pom uses
the mv
Kevin Williams wrote:
I am looking at the tests in itest/spec-api and wonder why there is a
ComponentTestCase as well as a CompositeTestCase. It looks like
CompositeTestCase is just a subset of ComponentTestCase. Am I missing
something?
Thanks,
--Kevin
Kevin,
If I understand these tests co
A few thoughts:
- You need the URI of an artifact inside the SCA contribution.
- I indicated before that I needed input/outputStreams as well.
- I think it's useful to have the URL of the contribution to have a base
URL to load artifacts (for example for WSDLs and XSDs if they do ).
So I sugges
I guess this is the question about what should we call the next release - M3
or beta1 or something else? See:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
...ant
On 4/29/07, 王洪伟 <[EMAIL PROTECTED]> wrote:
why not with a sign --M3 ?
like this :
tuscan
On 4/29/07, ant elder <[EMAIL PROTECTED]> wrote:
What do we want the Tuscany SCA distribution to look like for the next
release? I'll suggest the following straw man as start, please suggest
changes. I'm using the name 'beta1' here till we decide on the real name.
All the artifacts in the defau
why not with a sign --M3 ?
like this :
tuscany-sca-1.0-M3-beta1.zip
tuscany-sca-1.0-M3-beta1.tar.gz
tuscany-sca-1.0-M3-beta1-src.zip
tuscany-sca-1.0-M3-beta1-src.tar.gz
2007/4/29, ant elder <[EMAIL PROTECTED]>:
What do we want the Tuscany SCA distribution to look like for the next
release? I'l
On 4/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: jsdelfino
Date: Sat Apr 28 16:52:22 2007
New Revision: 533445
URL: http://svn.apache.org/viewvc?view=rev&rev=533445
Log:
Changes to make sure that model factories can be switched and the that the
runtime does not assume specific f
What do we want the Tuscany SCA distribution to look like for the next
release? I'll suggest the following straw man as start, please suggest
changes. I'm using the name 'beta1' here till we decide on the real name.
All the artifacts in the default build would be published to the maven
repository
12 matches
Mail list logo
