I think this is a misunderstanding of what this is for, I'm not trying
to implement a new domain manger type of thing, so using the module
name domain is likely confusing things. I'll move this somewhere else
and continue it there.
...ant
On Sun, Jun 6, 2010 at 5:52 PM, Raymond Feng wrote:
>
In our binding.sca support (and tests [1]) we allow/expect a uri in
the binding to determine the location of the protocol endpoint.
ASM90005 means that we can't do this and the tests report errors. I
couldn't find a JIRA with a quick look but I haven't worked recently
on the binding.sca delegation
On Wed, Jun 9, 2010 at 11:19 AM, Simon Laws wrote:
> In our binding.sca support (and tests [1]) we allow/expect a uri in
> the binding to determine the location of the protocol endpoint.
> ASM90005 means that we can't do this and the tests report errors. I
> couldn't find a JIRA with a quick look
>
> Right now it only really works well when using the Hazelcast based SCA
> binding (ie by including tuscany-binding-hazelcast-runtime). That uses
> the configuration that is being used for the endpoint registry so the
> SCA binding "just works". The problem with using other bindings for
> the SCA
On Wed, Jun 9, 2010 at 12:44 PM, Simon Laws wrote:
>>
>> Right now it only really works well when using the Hazelcast based SCA
>> binding (ie by including tuscany-binding-hazelcast-runtime). That uses
>> the configuration that is being used for the endpoint registry so the
>> SCA binding "just wo
>
> Yep i agree with what you're saying about the existing tests, and even
> with other non-SCA bindings too you shouldn't generally specify an
> absolute uri on a service.
>
> I think there are likely problems with the endpoint information that
> goes into the registry for the different bindings,
Per the assembly spec, cannot have @uri at the service side.
First of all, there is already a structural URI for the binding, such as
component1/Service1/scaBinding. This is what is needed by the reference binding
side as the "target". When we map binding.sca to a concrete binding such as
bind
On Wed, Jun 9, 2010 at 5:25 PM, Raymond Feng wrote:
> Per the assembly spec, cannot have @uri at the service side.
> First of all, there is already a structural URI for the binding, such as
> component1/Service1/scaBinding. This is what is needed by the reference
> binding side as the "target". W
OSGi remote services samples fail in 2.0-M5
---
Key: TUSCANY-3590
URL: https://issues.apache.org/jira/browse/TUSCANY-3590
Project: Tuscany
Issue Type: Bug
Components: Java SCA OSGi Integratio
[
https://issues.apache.org/jira/browse/TUSCANY-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877254#action_12877254
]
Raymond Feng commented on TUSCANY-3590:
---
The OSGi import of javax.xml.namespace is
[
https://issues.apache.org/jira/browse/TUSCANY-3590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-3590.
---
Resolution: Fixed
> OSGi remote services samples fail in 2.0-M5
> -
Sorry, you have been talking about section 10 of the SCA assembly spec.
IMO, the names don't matter too much here. Having a layer that handles domain
level deployment is good in addition to the node that is used to execute the
components out of the domain.
Thanks,
Raymond
Hi,
I have fixed an issue to get the OSGi remote services sample working. See
https://issues.apache.org/jira/browse/TUSCANY-3590.
If possible, please include it for M5. The code has been checked in under both
m5 branch and trunk.
Thanks,
Raymond
13 matches
Mail list logo
