date:20080516


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

Simon Laws closed TUSCANY-1534.
---

Resolution: Fixed

Done as part of the latest round of reference/binding/endpoint changes. 

 Refactor wireable binding support to make it applicable to all bindings
 ---

 Key: TUSCANY-1534
 URL: https://issues.apache.org/jira/browse/TUSCANY-1534
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core Runtime
 Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
 Fix For: Java-SCA-Next


 Extracted from the now closed 
 https://issues.apache.org/jira/browse/TUSCANY-1526
 There is consensus that all bindings are potentially wireable and that the 
 current WireableBinding interface should either be removed or applied to all 
 bindings. Hence the following should be a valid configuration.
  component name=CalculatorServiceComponent
implementation.java class=calculator.CalculatorServiceImpl/
 reference name=addService target=AddServiceComponent /
 reference name=subtractService target=SubtractServiceComponent /
 reference name=multiplyService target=MultiplyServiceComponent
 interface.java interface=calculator.MultiplyService /
 binding.ws 
 wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/
 /reference
 reference name=divideService target=DivideServiceComponent /
 /component
 component name=MultiplyServiceComponent
 implementation.java class=calculator.MultiplyServiceImpl /
 service
 interface.java interface=calculator.MultiplyService /
 binding.ws 
 wsdlElement=http://calculator#wsdl.binding(MultiplySoapBinding)/
 /service
 /component 
 There is further discussion in the mail thread associated with TUSCANY-1526 
 (http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21448.html)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

2008-05-16 Thread Mark Combellack

This problem has now been fixed in SVN revision r657009


Thanks,

Mark

 -Original Message-
 From: Mark Combellack [mailto:[EMAIL PROTECTED]
 Sent: 16 May 2008 11:26
 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
 Subject: RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed
 operation and extension implementations - was: Re: Request to propogate
 the value of a references target= attribute on its associated bindings
 model object
 
 Hi,
 
 
 
 I've just tried building the latest trunk of Tuscany and I'm getting a
 compile failure in the new endpoint module. The error I am getting is:
 
 
 
 [INFO]
 
 
 [INFO] Error for project: Apache Tuscany SCA Default Endpoint
 Implementation
 (during install)
 
 [INFO]
 
 
 [INFO] Compilation failure
 
 
 
 /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc
 an
 y/sca/binding/sca/EndpointTestCase.java:[109,32] package
 org.apache.xml.serialize does not exist
 
 
 
 /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc
 an
 y/sca/binding/sca/EndpointTestCase.java:[110,32] package
 org.apache.xml.serialize does not exist
 
 
 
 
 
 Is anyone else seeing this issue or is it just me?
 
 
 
 Thanks,
 
 
 
 Mark
 
 
 
  -Original Message-
 
  From: Simon Laws [mailto:[EMAIL PROTECTED]
 
  Sent: 16 May 2008 09:26
 
  To: tuscany-dev@ws.apache.org
 
  Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed
 
  operation and extension implementations - was: Re: Request to propogate
 
  the value of a references target= attribute on its associated bindings
 
  model object
 
 
 
  ...snip
 
 
 
  
 
   The two sets of SPIs could co-exist for a while with BindingProviders
 
   working with bindings and ServiceProviders (I just made up that name)
 
  with
 
   service endpoints.
 
   --
 
   Jean-Sebastien
 
 
 
 
 
  At r656959 I've just enabled some changes to take a step toward using an
 
  Endpoint representation in the model as an alternative to using cloned
 
  bindings as the representation of valid reference targets. It's not
 
  replacing the cloned binding approach just yet, to avoid breaking
 
  anything,
 
  but is the first step on the road. This is what I have done.
 
 
 
  Made a new Endpoint model type
 
  Created a separate factory for it (separate as I though the model may
 need
 
  to be pluggable as some point)
 
  Created a new EndpointProvider type and associated factory.
 
  Created an Endpoint module to provide a provider implementation.
 
  Created an Endpoint wire to trap attempted calls over unresolved
 endpoints
 
  Separated off the Endpoint builder code into a new builder class. Same
 
  code
 
  but easier to identify.
 
  Added an endpoint collection to references
 
  Used the Endpoint in the wire builder in place of the old internal
 target
 
  structure. The logic is weaved in to the existing logic as follows.
 
For references with no target, put the binding into reference binding
 as
 
  before
 
Create an Endpoint for all explicit reference targets
 
For resolved endpoints (Endpoints where the target is resolved) put
 the
 
  binding into reference bindings, i.e. the same as before
 
For unresolved endpoints create an endpoint provider and a wire. We
 
  don't
 
  have unresolved targets in tuscany (except in the sca binding test) so
 
  should not happen. If you do put a target name in that can't be matched
 
  with
 
  a service you'll get a warning.
 
 
 
  If there is no Endpoint module on the classpath it will not create a
 
  provider or a wire hence disabling any Endpoint based processing. The
 
  Endpoint model will still be used though
 
 
 
  As part of this change I've updated the logic that looks for target
 names
 
  in
 
  binding uri. It's now applied to all binding types which I believe is
 what
 
  the spec says, There is though an issue here. I'll raise a separate
 
  thread.
 
 
 
  There are also a couple of thoughts I had.
 
 
 
  Can we make the CompositeBuilderImpl have just one constructor?
 
  Should builders be pluggable?
 
  I've used some of the CompoisteActivator functions in the EndpointWire
 
  that
 
  could do with moving into the activator interface.
 
 
 
  Simon
 
   _

Re: Small OSGi sample for the main build?

2008-05-16 Thread Graham Charters

Hi,

Regarding Mike's build breaking comment, one of the reasons for
including this in the main build is to have it break to flag when new
dependencies are being introduced.  This will help us focus on
improving Tuscany modularity, but also help us preserve the support
for running in OSGi.  It will also give us a place to focus on keeping
the core small.

I now have what I think is the smallest subset of modules, based on
current dependencies.  My previous attempt took the approach of
cutting down a distribution, but the latest was created by adding to
the dependencies of the basic Calculator.  The net result is 47
bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes
about 2.5 mins to build and run which does not seem like a big delta
over and above the time taken to do a full Tuscany build and run all
the samples.

The sca modules which are installed are:

tuscany-assembly-2.0-incubating-SNAPSHOT.jar
tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar
tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar
tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar
tuscany-core-2.0-incubating-SNAPSHOT.jar
tuscany-core-spi-2.0-incubating-SNAPSHOT.jar
tuscany-databinding-2.0-incubating-SNAPSHOT.jar
tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar
tuscany-definitions-2.0-incubating-SNAPSHOT.jar
tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar
tuscany-domain-2.0-incubating-SNAPSHOT.jar
tuscany-domain-api-2.0-incubating-SNAPSHOT.jar
tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar
tuscany-extensibility-2.0-incubating-SNAPSHOT.jar
tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar
tuscany-host-http-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar
tuscany-interface-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar
tuscany-monitor-2.0-incubating-SNAPSHOT.jar
tuscany-node-2.0-incubating-SNAPSHOT.jar
tuscany-node-api-2.0-incubating-SNAPSHOT.jar
tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar
tuscany-policy-2.0-incubating-SNAPSHOT.jar
tuscany-policy-security-2.0-incubating-SNAPSHOT.jar
tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar
tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar
tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar
tuscany-sca-api-2.0-incubating-SNAPSHOT.jar

The third-party jars (currently installed in a single bundle) are:

activation-1.1.jar
addressing-1.3.mar
annogen-0.1.0.jar
avalon-framework-4.1.3.jar
axiom-api-1.2.5.jar
axiom-dom-1.2.5.jar
axiom-impl-1.2.5.jar
axis2-adb-1.3.jar
axis2-adb-codegen-1.3.jar
axis2-codegen-1.3.jar
axis2-java2wsdl-1.3.jar
axis2-kernel-1.3.jar
axis2-mtompolicy-1.3.jar
backport-util-concurrent-2.2.jar
bcprov-jdk15-132.jar
cglib-nodep-2.1_3.jar
commons-codec-1.3.jar
commons-collections-3.1.jar
commons-discovery-0.2.jar
commons-fileupload-1.1.1.jar
commons-httpclient-3.0.1.jar
commons-io-1.2.jar
commons-logging-1.1.jar
geronimo-activation_1.1_spec-1.0-M1.jar
geronimo-commonj_1.1_spec-1.0.jar
geronimo-javamail_1.4_spec-1.0-M1.jar
geronimo-jms_1.1_spec-1.1.jar
httpcore-4.0-alpha5.jar
httpcore-nio-4.0-alpha5.jar
httpcore-niossl-4.0-alpha5.jar
jaxb-api-2.1.jar
jaxb-impl-2.1.6.jar
jaxb2-reflection-2.1.4.jar
jaxen-1.1-beta-9.jar
jaxws-api-2.1.jar
jettison-1.0.jar
json-rpc-1.0.jar
jsr181-api-1.0-MR1.jar
jsr250-api-1.0.jar
junit-4.2.jar
log4j-1.2.12.jar
logkit-1.0.1.jar
mail-1.4.jar
neethi-2.0.2.jar
opensaml-1.1.jar
org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar
org.apache.felix.framework-1.1.0-SNAPSHOT.jar
org.apache.felix.main-1.1.0-SNAPSHOT.jar
org.apache.felix.shell-1.1.0-SNAPSHOT.jar
org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar
org.osgi.core-1.0.0.jar
rampart-core-1.3.jar
rampart-policy-1.3.jar
rampart-trust-1.3.jar
saaj-api-1.3.jar
servlet-api-2.4.jar
stax-api-1.0-2.jar
stax-api-1.0.1.jar
woden-1.0-incubating-M7b.jar
wsdl4j-1.6.2.jar
wss4j-1.5.3.jar
wstx-asl-3.2.1.jar
xalan-2.7.0.jar
xercesImpl-2.8.1.jar
xml-apis-1.3.03.jar
XmlSchema-1.3.2.jar
xmlsec-1.4.0.jar

Let me know what you think?

Regards,

Graham.


2008/5/15 Mike Edwards [EMAIL PROTECTED]:
 Graham Charters wrote:

 Hi,

 I've been working on a small sample to act as an OSGi sniff test for
 Tuscany running in OSGi.  It's

Re: Small OSGi sample for the main build?

2008-05-16 Thread Simon Laws

On Fri, May 16, 2008 at 12:44 PM, Graham Charters [EMAIL PROTECTED]
wrote:

 Hi,

 Regarding Mike's build breaking comment, one of the reasons for
 including this in the main build is to have it break to flag when new
 dependencies are being introduced.  This will help us focus on
 improving Tuscany modularity, but also help us preserve the support
 for running in OSGi.  It will also give us a place to focus on keeping
 the core small.

 I now have what I think is the smallest subset of modules, based on
 current dependencies.  My previous attempt took the approach of
 cutting down a distribution, but the latest was created by adding to
 the dependencies of the basic Calculator.  The net result is 47
 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes
 about 2.5 mins to build and run which does not seem like a big delta
 over and above the time taken to do a full Tuscany build and run all
 the samples.

 The sca modules which are installed are:

 tuscany-assembly-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar
 tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-core-2.0-incubating-SNAPSHOT.jar
 tuscany-core-spi-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-api-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-extensibility-2.0-incubating-SNAPSHOT.jar
 tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar
 tuscany-host-http-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-monitor-2.0-incubating-SNAPSHOT.jar
 tuscany-node-2.0-incubating-SNAPSHOT.jar
 tuscany-node-api-2.0-incubating-SNAPSHOT.jar
 tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-sca-api-2.0-incubating-SNAPSHOT.jar

 The third-party jars (currently installed in a single bundle) are:

 activation-1.1.jar
 addressing-1.3.mar
 annogen-0.1.0.jar
 avalon-framework-4.1.3.jar
 axiom-api-1.2.5.jar
 axiom-dom-1.2.5.jar
 axiom-impl-1.2.5.jar
 axis2-adb-1.3.jar
 axis2-adb-codegen-1.3.jar
 axis2-codegen-1.3.jar
 axis2-java2wsdl-1.3.jar
 axis2-kernel-1.3.jar
 axis2-mtompolicy-1.3.jar
 backport-util-concurrent-2.2.jar
 bcprov-jdk15-132.jar
 cglib-nodep-2.1_3.jar
 commons-codec-1.3.jar
 commons-collections-3.1.jar
 commons-discovery-0.2.jar
 commons-fileupload-1.1.1.jar
 commons-httpclient-3.0.1.jar
 commons-io-1.2.jar
 commons-logging-1.1.jar
 geronimo-activation_1.1_spec-1.0-M1.jar
 geronimo-commonj_1.1_spec-1.0.jar
 geronimo-javamail_1.4_spec-1.0-M1.jar
 geronimo-jms_1.1_spec-1.1.jar
 httpcore-4.0-alpha5.jar
 httpcore-nio-4.0-alpha5.jar
 httpcore-niossl-4.0-alpha5.jar
 jaxb-api-2.1.jar
 jaxb-impl-2.1.6.jar
 jaxb2-reflection-2.1.4.jar
 jaxen-1.1-beta-9.jar
 jaxws-api-2.1.jar
 jettison-1.0.jar
 json-rpc-1.0.jar
 jsr181-api-1.0-MR1.jar
 jsr250-api-1.0.jar
 junit-4.2.jar
 log4j-1.2.12.jar
 logkit-1.0.1.jar
 mail-1.4.jar
 neethi-2.0.2.jar
 opensaml-1.1.jar
 org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar
 org.apache.felix.framework-1.1.0-SNAPSHOT.jar
 org.apache.felix.main-1.1.0-SNAPSHOT.jar
 org.apache.felix.shell-1.1.0-SNAPSHOT.jar
 org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar
 org.osgi.core-1.0.0.jar
 rampart-core-1.3.jar
 rampart-policy-1.3.jar
 rampart-trust-1.3.jar
 saaj-api-1.3.jar
 servlet-api-2.4.jar
 stax-api-1.0-2.jar
 stax-api-1.0.1.jar
 woden-1.0-incubating-M7b.jar
 wsdl4j-1.6.2.jar
 wss4j-1.5.3.jar
 wstx-asl-3.2.1.jar
 xalan-2.7.0.jar
 xercesImpl-2.8.1.jar
 xml-apis-1.3.03.jar
 XmlSchema-1.3.2.jar
 xmlsec-1.4.0.jar

 Let me know what you

Re: Small OSGi sample for the main build?

2008-05-16 Thread Simon Laws

On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED]
wrote:



 On Fri, May 16, 2008 at 12:44 PM, Graham Charters 
 [EMAIL PROTECTED] wrote:

 Hi,

 Regarding Mike's build breaking comment, one of the reasons for
 including this in the main build is to have it break to flag when new
 dependencies are being introduced.  This will help us focus on
 improving Tuscany modularity, but also help us preserve the support
 for running in OSGi.  It will also give us a place to focus on keeping
 the core small.

 I now have what I think is the smallest subset of modules, based on
 current dependencies.  My previous attempt took the approach of
 cutting down a distribution, but the latest was created by adding to
 the dependencies of the basic Calculator.  The net result is 47
 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes
 about 2.5 mins to build and run which does not seem like a big delta
 over and above the time taken to do a full Tuscany build and run all
 the samples.

 The sca modules which are installed are:

 tuscany-assembly-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar
 tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-core-2.0-incubating-SNAPSHOT.jar
 tuscany-core-spi-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-api-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-extensibility-2.0-incubating-SNAPSHOT.jar
 tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar
 tuscany-host-http-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-monitor-2.0-incubating-SNAPSHOT.jar
 tuscany-node-2.0-incubating-SNAPSHOT.jar
 tuscany-node-api-2.0-incubating-SNAPSHOT.jar
 tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-sca-api-2.0-incubating-SNAPSHOT.jar

 The third-party jars (currently installed in a single bundle) are:

 activation-1.1.jar
 addressing-1.3.mar
 annogen-0.1.0.jar
 avalon-framework-4.1.3.jar
 axiom-api-1.2.5.jar
 axiom-dom-1.2.5.jar
 axiom-impl-1.2.5.jar
 axis2-adb-1.3.jar
 axis2-adb-codegen-1.3.jar
 axis2-codegen-1.3.jar
 axis2-java2wsdl-1.3.jar
 axis2-kernel-1.3.jar
 axis2-mtompolicy-1.3.jar
 backport-util-concurrent-2.2.jar
 bcprov-jdk15-132.jar
 cglib-nodep-2.1_3.jar
 commons-codec-1.3.jar
 commons-collections-3.1.jar
 commons-discovery-0.2.jar
 commons-fileupload-1.1.1.jar
 commons-httpclient-3.0.1.jar
 commons-io-1.2.jar
 commons-logging-1.1.jar
 geronimo-activation_1.1_spec-1.0-M1.jar
 geronimo-commonj_1.1_spec-1.0.jar
 geronimo-javamail_1.4_spec-1.0-M1.jar
 geronimo-jms_1.1_spec-1.1.jar
 httpcore-4.0-alpha5.jar
 httpcore-nio-4.0-alpha5.jar
 httpcore-niossl-4.0-alpha5.jar
 jaxb-api-2.1.jar
 jaxb-impl-2.1.6.jar
 jaxb2-reflection-2.1.4.jar
 jaxen-1.1-beta-9.jar
 jaxws-api-2.1.jar
 jettison-1.0.jar
 json-rpc-1.0.jar
 jsr181-api-1.0-MR1.jar
 jsr250-api-1.0.jar
 junit-4.2.jar
 log4j-1.2.12.jar
 logkit-1.0.1.jar
 mail-1.4.jar
 neethi-2.0.2.jar
 opensaml-1.1.jar
 org.apache.felix.bundlerepository-1.1.0-SNAPSHOT.jar
 org.apache.felix.framework-1.1.0-SNAPSHOT.jar
 org.apache.felix.main-1.1.0-SNAPSHOT.jar
 org.apache.felix.shell-1.1.0-SNAPSHOT.jar
 org.apache.felix.shell.tui-1.1.0-SNAPSHOT.jar
 org.osgi.core-1.0.0.jar
 rampart-core-1.3.jar
 rampart-policy-1.3.jar
 rampart-trust-1.3.jar
 saaj-api-1.3.jar
 servlet-api-2.4.jar
 stax-api-1.0-2.jar
 stax-api-1.0.1.jar
 woden-1.0-incubating-M7b.jar
 wsdl4j-1.6.2.jar
 wss4j-1.5.3.jar
 wstx-asl-3.2.1.jar
 xalan-2.7.0.jar
 xercesImpl-2.8.1.jar

[jira] Assigned: (TUSCANY-2277) Standardization of registering msg with monitor


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

Simon Laws reassigned TUSCANY-2277:
---

Assignee: Simon Laws  (was: Ramkumar Ramalingam)

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Small OSGi sample for the main build?

2008-05-16 Thread Graham Charters

Below are a couple of runs, one taking 2 mins 50s and the second
taking 1 min 8s.  Both were done after mvn cleans so the difference is
maybe due to my machine being under spec and paging.

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for
Calculator Sample  SUCCESS [1:06.859s]
[INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator
Sample  SUCCESS [31.297s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS
[1:07.594s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [4.687s]
[INFO] 

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for
Calculator Sample  SUCCESS [35.406s]
[INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator
Sample  SUCCESS [7.281s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [24.172s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [0.969s]
[INFO] 


2008/5/16 Simon Laws [EMAIL PROTECTED]:
 On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED]
 wrote:



 On Fri, May 16, 2008 at 12:44 PM, Graham Charters 
 [EMAIL PROTECTED] wrote:

 Hi,

 Regarding Mike's build breaking comment, one of the reasons for
 including this in the main build is to have it break to flag when new
 dependencies are being introduced.  This will help us focus on
 improving Tuscany modularity, but also help us preserve the support
 for running in OSGi.  It will also give us a place to focus on keeping
 the core small.

 I now have what I think is the smallest subset of modules, based on
 current dependencies.  My previous attempt took the approach of
 cutting down a distribution, but the latest was created by adding to
 the dependencies of the basic Calculator.  The net result is 47
 bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes
 about 2.5 mins to build and run which does not seem like a big delta
 over and above the time taken to do a full Tuscany build and run all
 the samples.

 The sca modules which are installed are:

 tuscany-assembly-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar
 tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar
 tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-core-2.0-incubating-SNAPSHOT.jar
 tuscany-core-spi-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-2.0-incubating-SNAPSHOT.jar
 tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-2.0-incubating-SNAPSHOT.jar
 tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-api-2.0-incubating-SNAPSHOT.jar
 tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-extensibility-2.0-incubating-SNAPSHOT.jar
 tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar
 tuscany-host-http-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar
 tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-monitor-2.0-incubating-SNAPSHOT.jar
 tuscany-node-2.0-incubating-SNAPSHOT.jar
 tuscany-node-api-2.0-incubating-SNAPSHOT.jar
 tuscany-node-impl-2.0-incubating-SNAPSHOT.jar
 tuscany-osgi-runtime-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-security-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-2.0-incubating-SNAPSHOT.jar
 tuscany-policy-xml-ws-2.0-incubating-SNAPSHOT.jar
 tuscany-sca-api-2.0-incubating-SNAPSHOT.jar

 The third-party jars (currently installed in a single bundle) are:

 activation-1.1.jar
 addressing-1.3.mar
 annogen-0.1.0.jar
 avalon-framework-4.1.3.jar
 axiom-api-1.2.5.jar
 axiom-dom-1.2.5.jar

[jira] Commented: (TUSCANY-2277) Standardization of registering msg with monitor

[
https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597473#action_12597473
]

Simon Laws commented on TUSCANY-2277:
-

Hi Ram

Was just trying to apply these patches and am having a few problems. What tool
did you use to generate them? I'm guessing Msftedit from the header. Can you
regenerate them using a diff tool. Let me know if you need some help.

The issues I'm having are

- has a strange Msft header (I can libe with this as I can remove it nmanually)
- the file dirs are absolute (I can live with this as I can go in and edit)
- there are some escaped charaters in there, e.g. \tab, \par, \{, \} which mess
it up. (I can't get round this as fixing manually messes up the formatting and
the patch tool can't then match the patch against the original code)

Thanks

Simon

Standardization of registering msg with monitor
---

Key: TUSCANY-2277
URL: https://issues.apache.org/jira/browse/TUSCANY-2277
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
Fix For: Java-SCA-Next

Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch,
TUSCANY-2277-Part3.patch

Lokking at the monitors that are being hooked up with different parts of the
code, found that we have some inconsistency interms of raising warning
errors. In some places we throw exceptions and in other places we raise a
warning.

Here are some examples for the inconsistency...

BaseConfigurationBuilderImpl.java
Here we raise only a warning for URISyntaxException, should we not throw an
exception too?

BaseWireBuilderImpl.java
Here we throw exceptions for IncompatibleInterfaceContractException, don't
you think we also need to register this message in our monitor?
In the same class, we raise a warning message for the PolicyRelated
Exceptions, should we also throw an exception here?

CompositeProcessor.java
There are instances where we throw new ContributionReadException, i believe
registering this msg with a monitor is also required as this is caused by
incorrect user input.
From Simon's comments on how we can go ahead with handling such instance, we
will fix the issue as discussed
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Small OSGi sample for the main build?


Graham Charters wrote:

Below are a couple of runs, one taking 2 mins 50s and the second
taking 1 min 8s.  Both were done after mvn cleans so the difference is
maybe due to my machine being under spec and paging.

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for
Calculator Sample  SUCCESS [1:06.859s]
[INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator
Sample  SUCCESS [31.297s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS
[1:07.594s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [4.687s]
[INFO] 

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Tuscany OSGi - Tuscany 3rdParty Manifest Bundle for
Calculator Sample  SUCCESS [35.406s]
[INFO] Apache Tuscany OSGi - Tuscany Manifest Bundle for Calculator
Sample  SUCCESS [7.281s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [24.172s]
[INFO] Calculator Sample Running in an OSGi Framework  SUCCESS [0.969s]
[INFO] 


From the above, it seems that the major time cost is the building of
the manifest bundles.  Graham's earlier note said that the third-party
manifest bundle consumes 17.5MB of disk space.

Could the time and space overheads be reduced by building virtual
bundles (or a single virtual bundle) for the third-party libraries?
As I understand it, this would save 17.5MB of disk space (as the
third party libraries are already in my maven repo), and it would
presumably take less time as nothing would need to be written to disk.

  Simon



2008/5/16 Simon Laws [EMAIL PROTECTED]:

On Fri, May 16, 2008 at 1:05 PM, Simon Laws [EMAIL PROTECTED]
wrote:



On Fri, May 16, 2008 at 12:44 PM, Graham Charters 
[EMAIL PROTECTED] wrote:


Hi,

Regarding Mike's build breaking comment, one of the reasons for
including this in the main build is to have it break to flag when new
dependencies are being introduced.  This will help us focus on
improving Tuscany modularity, but also help us preserve the support
for running in OSGi.  It will also give us a place to focus on keeping
the core small.

I now have what I think is the smallest subset of modules, based on
current dependencies.  My previous attempt took the approach of
cutting down a distribution, but the latest was created by adding to
the dependencies of the basic Calculator.  The net result is 47
bundles, 49MB (33MB felix cache and 16MB third-party jars) and takes
about 2.5 mins to build and run which does not seem like a big delta
over and above the time taken to do a full Tuscany build and run all
the samples.

The sca modules which are installed are:

tuscany-assembly-2.0-incubating-SNAPSHOT.jar
tuscany-assembly-xml-2.0-incubating-SNAPSHOT.jar
tuscany-assembly-xsd-2.0-incubating-SNAPSHOT.jar
tuscany-binding-sca-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-impl-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-java-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-namespace-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-osgi-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-resource-2.0-incubating-SNAPSHOT.jar
tuscany-contribution-xml-2.0-incubating-SNAPSHOT.jar
tuscany-core-2.0-incubating-SNAPSHOT.jar
tuscany-core-spi-2.0-incubating-SNAPSHOT.jar
tuscany-databinding-2.0-incubating-SNAPSHOT.jar
tuscany-databinding-json-2.0-incubating-SNAPSHOT.jar
tuscany-definitions-2.0-incubating-SNAPSHOT.jar
tuscany-definitions-xml-2.0-incubating-SNAPSHOT.jar
tuscany-domain-2.0-incubating-SNAPSHOT.jar
tuscany-domain-api-2.0-incubating-SNAPSHOT.jar
tuscany-domain-impl-2.0-incubating-SNAPSHOT.jar
tuscany-extensibility-2.0-incubating-SNAPSHOT.jar
tuscany-host-embedded-2.0-incubating-SNAPSHOT.jar
tuscany-host-http-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-runtime-2.0-incubating-SNAPSHOT.jar
tuscany-implementation-java-xml-2.0-incubating-SNAPSHOT.jar
tuscany-interface-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-jaxws-2.0-incubating-SNAPSHOT.jar
tuscany-interface-java-xml-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-java2wsdl-2.0-incubating-SNAPSHOT.jar
tuscany-interface-wsdl-xml-2.0-incubating-SNAPSHOT.jar
tuscany-monitor-2.0-incubating-SNAPSHOT.jar
tuscany-node-2.0-incubating-SNAPSHOT.jar
tuscany-node-api-2.0-incubating-SNAPSHOT.jar
tuscany-node-impl-2.0-incubating-SNAPSHOT.jar

Re: Conversational semantics using xml in SCDLs

2008-05-16 Thread Mike Edwards


Simon Nash wrote:

I am surprised to hear that.  I would expect a different interface
object to be created for each different interface element appearing
in the SCDL.



Hmm, my experience recently with the BPEL code shows that the handling of interfaces within Tuscany 
is not so clean.


I'll continue my investigations and report my findings when I understand it all 
better.

I agree that different interface elements SHOULD be used.  It just doesn't happen in all the cases 
that I've experienced.



Yours,  Mike.

Re: SCA 1.2.1 release

2008-05-16 Thread Mike Edwards

For my 1 cent on this point.

The BPEL code is still raw at this stage and I feel it could do with a few more tweaks before it is
really ready for prime time - I certainly still have a lot of trouble getting it to work - and I'm
working on it!!

Yours, Mike.

Luciano Resende wrote:

In the past, there has been various requests for this feature in the
user/dev list, and unfortunately I couldn't get it ready by 1.2.
It seems like a reasonable time to add it now that we are going to
make this 1.2.1 release. BTW, the changes are localized and not so
big.

On Thu, May 15, 2008 at 3:07 PM, Simon Nash [EMAIL PROTECTED] wrote:

Luciano Resende wrote:

Any chance I could add the bpel reference support as part of this
release ? The changes are localized and won't affect other areas.

Is there a user requesting this support? Remembering the 1.0.1
experience, I think we should keep this release as small and focused
as possible.

Simon

On Thu, May 15, 2008 at 2:10 AM, ant elder [EMAIL PROTECTED] wrote:

I've had a request to do an official release that includes the fix for
TUSCANY-2304. I think this is reasonable so would like to do this, it
shouldn't be too hard as its a small fix so its just copying the 1.2
release
tag, applying the fix, spinning the new release artifacts and voting. I
know
we tried this before with 1.0.1 but that ended up with so much new
function
it made it harder to get out, if 1.2.1 is kept really focused I hope it
would be easier. I'd like to start this off tomorrow if no one has any
objections, WDYT?

There was also a suggestion that maybe a fix for TUSCANY-2251 could get
into
this, is that likely to be small and ready?

...ant

[jira] Commented: (TUSCANY-2247) vtest content for Java API spec - Conversation/Async

2008-05-16 Thread Kevin Williams (JIRA)


[ 
https://issues.apache.org/jira/browse/TUSCANY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597491#action_12597491
 ] 

Kevin Williams commented on TUSCANY-2247:
-

Leaving this open until resolution of TUSCANY-2312 at which point I will add 
testing for section 1.6.7.5 which will complete conversation testing.

 vtest content for Java API spec - Conversation/Async 
 -

 Key: TUSCANY-2247
 URL: https://issues.apache.org/jira/browse/TUSCANY-2247
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Kevin Williams
 Fix For: Java-SCA-Next


 Add vtest content for Java API/Annotation Spec section 1.6 - Conversations 
 and Async

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener


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

Simon Laws reassigned TUSCANY-2092:
---

Assignee: Simon Laws  (was: Ramkumar Ramalingam)

 ConcurrentModificationException in ExtensibleContributionListener
 -

 Key: TUSCANY-2092
 URL: https://issues.apache.org/jira/browse/TUSCANY-2092
 Project: Tuscany
  Issue Type: Bug
Reporter: Greg Dritschler
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: JIRA-2092.patch, TUSCANY-2092.patch


 java.util.ConcurrentModificationException
   at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
   at 
 org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
   at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
   at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
 The problem occurs if two threads try to add a contribution simultaneously.
 DefaultContributionListenerExtensionPoint does not synchronize the list of 
 listeners.  In particular loadListeners does not prevent multiple threads 
 from trying to load the list of listeners.  One thread completes first while 
 the other is still loading.  This leads to the exception shown above when a 
 thread tries to iterate the listener list.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener

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

Simon Laws closed TUSCANY-2092.
---

Resolution: Fixed

Thanks for the patch Ram. Committed at 657093

ConcurrentModificationException in ExtensibleContributionListener
-

Key: TUSCANY-2092
URL: https://issues.apache.org/jira/browse/TUSCANY-2092
Project: Tuscany
Issue Type: Bug
Reporter: Greg Dritschler
Assignee: Simon Laws
Fix For: Java-SCA-Next

Attachments: JIRA-2092.patch, TUSCANY-2092.patch

java.util.ConcurrentModificationException
at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
at
org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
at
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
The problem occurs if two threads try to add a contribution simultaneously.
DefaultContributionListenerExtensionPoint does not synchronize the list of
listeners. In particular loadListeners does not prevent multiple threads
from trying to load the list of listeners. One thread completes first while
the other is still loading. This leads to the exception shown above when a
thread tries to iterate the listener list.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (TUSCANY-2283) Conversation should end due to non-business exception


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

Simon Laws reassigned TUSCANY-2283:
---

Assignee: Simon Laws

 Conversation should end due to non-business exception
 -

 Key: TUSCANY-2283
 URL: https://issues.apache.org/jira/browse/TUSCANY-2283
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Kevin Williams
Assignee: Simon Laws
 Fix For: Java-SCA-Next


 The Java APIs and Annotations spec states:
 487 A conversation ends, and any state associated with the conversation 
 is freed up, when:
 ...
 492 • Any non-business exception is thrown by a conversational operation
 This is not happening as illustrated by the vtest:
   
 org.apache.tuscany.sca.vtest.javaapi.conversation.lifetime.LifetimeTestCase.lifetime11
 It is currently @Ignore(d)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Webapp-based Tuscany/Geronimo integration in Tuscany SCA Java 1.2 release

2008-05-16 Thread Kevan Miller

Hi Raymond,
One minor netiquette comment... Looks like you used a Reply To
button when generating your note (then changed the subject line). Some
mail readers will still group your email in the previous email thread
(one example is Mac OS X Mail). This can cause emails to be lost/cause
confusion. So, it's best to avoid...

More below.

On May 15, 2008, at 1:52 PM, Raymond Feng wrote:

Hi,

In the recently released Tuscany SCA Java 1.2 [1], we produce a
whitepaper [2] to describe webapp-based Tuscany/Geronimo
integration. We would like to share the information here and hope it
can trigger more interests from both Geronimo and Tuscany community
to bring more values into these areas collaboratively.

Thanks!

Developing SOA based solutions can be very complex and expensive.
Apache Tuscany provides a lightweight infrastructure which enables
users to easily implement SOA based solutions or to use
their existing assets and align them with SOA principles which would
support a business model that can extend and expand as business
needs change.

Apache Tuscany implements SCA specifications that is being
standardized at OASIS. Tuscany provides the capabilities to
construct, assemble and deploy composite applications using SCA.

This white paper explains how Tuscany integrates with Apache
Geronimo, a fully certified Java EE 5 application server runtime, to
provide added value to users wanting to develop SOA solutions using
Geronimo as a platform. The added values include:

* Extensibility of component implementation technologies
* Extensibility of transport and protocol abstractions
* A notion of cross-application/cross-network assembly and
configuration

* Integration of SCA with existing or new EJB based applications

The following are a set of usage scenarios that both JEE and SCA
developers could be interested in.

* Access SCA composites from Java EE components using JEE
programming model

* Access session beans from SCA service components
* Expose SCA services as session beans or web services
* Include Session Beans in a single SCA composition by providing an
SCA implementation for session beans.

* Inject SCA service references to web components to enable Web 2.0
* Expose enterprise applications into an SCA domain
* Use recursive SCA assembly in enterprise applications

[1] http://incubator.apache.org/tuscany/sca-java-releases.html
[2]
http://cwiki.apache.org/TUSCANYWIKI/tuscany-web-application-based-integration-with-geronimo.html

Is there interest in tighter integration between Tuscany/Geronimo?
Would there be interest in generating a Tuscany Plugin for Geronimo?
Running Tuscany as a service?

--kevan

Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected

2008-05-16 Thread Scott Kurz

Why do we need to be so strict in comparing interfaces?

Can't we argue essentially the same point in the case with we have a Java
client w/ reference w/ Java intf with a binding.ws?

So, following this logic, it's suggested that the NS calculated per-JAXWS
for the Java intf must match the portType on the WS binding.

So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL
of an existing WS w/ wsimport, embedding a
@WebService(name = ..., targetNamespace =  ...)in the Java.   Now
the WS evolves and we take the new WSDL w/ portType
in a new NS. Maybe a new operation is added but we don't care about it
from our existing client.   Why should we have to re-gen the Java to reflect
the new TNS?

Also, someone using an older W2J tool may have an option to select a
non-standard pkg when generating Java from WSDL, but the tool doesn't
reflect this in the @WebService(... targetNamespace...).  Do we really need
to break them?

Would people agree this is essentially the same case as the overridden,
promoted intf, or is the argument that this specific case is a bit different
?

I mean, I can certainly see how it simplifies the runtime authors' lives to
be strict about NS's when doing intf mapping...   but do we really have a
good reason to?What use case can we just not handle that would make us
need this restriction?

Scott



On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng [EMAIL PROTECTED] wrote:

 +1 on Simon's proposal to add the getNamespace() on Interface from another
 perspective: converting/mapping between IDLs.

 Thanks,
 Raymond
 --
 From: Simon Laws [EMAIL PROTECTED]
 Sent: Thursday, April 17, 2008 6:32 AM
 To: tuscany-dev@ws.apache.org
 Subject: Re: [jira] Commented: (TUSCANY-2109) Conflicts between component
 reference interface and promoted composite reference interface are not
 detected


  On Thu, Apr 10, 2008 at 10:14 PM, Simon Laws [EMAIL PROTECTED]
 wrote:

  Hi Mike

 Some comments in line

 Simon

 
  
   Folks,
  
   It is right to be concerned over the interface matching, but let's 
  not
   lose sight of the context here.
  
   In general, there are two scenarios to consider:
  
   a) the reference is to a service which is defined within the SCA
   domain and SCA means are used to wire it
   b) the reference is to a service which is outside the SCA domain and
   wiring is through configuration of a specific binding and target  
 endpoint
 
 
 This JIRA covers a very specific scenario which adds another twist where
 there is a different between the interface definition of a composite
 level
 reference that promotes a component level reference.

 
  
   In case a) it is possible that a Java interface as used by the client
   in its reference is exactly the same (file) as is being used by the 
  provider
   in the service interface.  If this is so, then in general, even if 
  WSDL is
   generated, the reference and the target service are going to match, 
  assuming
   that the same rules are followed at both ends for generating WSDL. 
  (They
   should be following JAX-WS according to the specs).
 
 
 It is certainly possible. Maybe even likely. But not guaranteed.

 
  
   In case b), the normal situation would be for the client to be
   constructed using a Java interface derived from the target WSDL using
   the
   WSDL2JAVA tooling.  While the reference targets the original service
   from
   which the WSDL came, there should be no problem, even if the  
 reference
   itself is typed in terms of the Java interface.
  
   Things get interesting if the target service gets changed - and if 
  the
   WSDL describing the interface changes.  Now, to first order, you  
 might say
   that if the WSDL is different, how do you know that the new service 
  is
   compatible with the old one?  Even if the operation names match and 
  the
   input and output messages have the same structure, if the namespaces
   differ,
   there is no guarantee that the two services are actually compatible.
 
  This proposed change is intended to at least raise a warning that there
 is something amiss.

 
  
   This is an area where ESB style mediations come into play.  Let's
   assume that the target service does use a different namespace, but 
  that the
   operations and messages otherwise map.  There is still a mediation
   necessary, since the transmitted messages will use the wrong  
 namespace -
   the mediation simply has to remap the namespace when sending and  
 receiving
   messages.  More complex mediations are possible, where perhaps the 
  operation
   names and message names don't match, although the structure and  
 semantics do
   match.
  
   The question for us folks in SCA-land is whether we want to model
   mediations of this type as explicit components, with services and  
 references
   that match the reference and endpoint that they are trying to  
 mediate, or
   whether we want to extend our bindings definition to allow

Re: Webapp-based Tuscany/Geronimo integration in Tuscany SCA Java 1.2 release

2008-05-16 Thread ant elder

On Fri, May 16, 2008 at 4:45 PM, Kevan Miller [EMAIL PROTECTED]
wrote:

snip


 Is there interest in tighter integration between Tuscany/Geronimo? Would
 there be interest in generating a Tuscany Plugin for Geronimo? Running
 Tuscany as a service?

 --kevan


Yes! I think that would be really useful. Right now we've some ongoing work
getting Tomcat and the new Tuscany distributed domain stuff working together
so having Geronimo also able to do something similar would be ideal. We've
also a Google Summer of Code student working on better Tuscany/SCA
management in the Geronimo admin console so that would be helped by this as
well.

  ...ant

[jira] Updated: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)

2008-05-16 Thread Dan Becker (JIRA)


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

Dan Becker updated TUSCANY-2290:


Attachment: TUSCANY-2290.1.patch

New patch generated based on comments in Tuscany dev group. Summary is that 
security fixes should not be applied to samples to keep them simple.

 Java 2 Security enablement for Tuscany sample (part 1)
 --

 Key: TUSCANY-2290
 URL: https://issues.apache.org/jira/browse/TUSCANY-2290
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-1.2
 Environment: Windows, Java 1.5
Reporter: Dan Becker
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2290.1.patch


 Fix security issues that arise in Tuscany samples when Java 2 security is 
 turned on via 
 -java.security.manager  -Djava.security.policy=tuscany.policy 
 -Dpolicy.allowSystemProperty=true
 A typical exception might be for sample helloworld sdo ws 
 Problems trying to access System properties: 
 java.security.AccessControlException: access denied 
 (java.util.PropertyPermission java.specification.version read)
 java.lang.NoClassDefFoundError
   at 
 org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202)
   at 
 org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116)
   at 
 org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58)
   at 
 org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113)
   at 
 org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48)
   at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159)
   at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90)
   at 
 org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72)
   at 
 org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
   at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152)
   at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63)
 ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2290) Java 2 Security enablement for Tuscany sample (part 1)

2008-05-16 Thread Dan Becker (JIRA)


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

Dan Becker updated TUSCANY-2290:


Attachment: (was: TUSCANY-2290.patch)

 Java 2 Security enablement for Tuscany sample (part 1)
 --

 Key: TUSCANY-2290
 URL: https://issues.apache.org/jira/browse/TUSCANY-2290
 Project: Tuscany
  Issue Type: Bug
Affects Versions: Java-SCA-1.2
 Environment: Windows, Java 1.5
Reporter: Dan Becker
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2290.1.patch


 Fix security issues that arise in Tuscany samples when Java 2 security is 
 turned on via 
 -java.security.manager  -Djava.security.policy=tuscany.policy 
 -Dpolicy.allowSystemProperty=true
 A typical exception might be for sample helloworld sdo ws 
 Problems trying to access System properties: 
 java.security.AccessControlException: access denied 
 (java.util.PropertyPermission java.specification.version read)
 java.lang.NoClassDefFoundError
   at 
 org.apache.tuscany.sca.databinding.sdo.SDODataBinding.introspect(SDODataBinding.java:61)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint$LazyDataBinding.introspect(DefaultDataBindingExtensionPoint.java:191)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:246)
   at 
 org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:202)
   at 
 org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.processInterface(DataBindingJavaInterfaceProcessor.java:116)
   at 
 org.apache.tuscany.sca.core.databinding.processor.DataBindingJavaInterfaceProcessor.visitInterface(DataBindingJavaInterfaceProcessor.java:58)
   at 
 org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:113)
   at 
 org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:48)
   at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createService(ServiceProcessor.java:159)
   at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitClass(ServiceProcessor.java:90)
   at 
 org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:72)
   at 
 org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
   at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:152)
   at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:63)
 ...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: More Java security fixes on the way

2008-05-16 Thread Dan Becker


Jean-Sebastien Delfino wrote:

I'd like to suggest the following:
- Keep the Java2 security blocks in test case classes
- Don't put them in sample program classes

Hmmm but looking at these test cases, could you help me understand why 
we need these technical API calls to the jmsBroker at all?


Isn't SCA supposed to shield me from having to deal with that kind of 
calls?


Based on the several opinions, I've regenerated the patch so that 
samples are keep simple and do not have security code in them.


Jean-Sebastien, I can't comment on why several of the samples have 
explicit JMS broker starts and stops in their JUnit tests as I am not 
the original author. It seems like the author wanted to ensure the 
broker was running before running the unit test. However, commenting out 
the startBroker call in sample-helloworld-ws-service-jms, the JUnit test 
still ran and passed.


--
Thanks, Dan Becker

Re: SCA 1.2.1 release


Mike Edwards wrote:

For my 1 cent on this point.

The BPEL code is still raw at this stage and I feel it could do with a 
few more tweaks before it is really ready for prime time - I certainly 
still have a lot of trouble getting it to work - and I'm working on it!!



I'm not familiar with the BPEL code but I do remember what happened
with 1.0.1 and I don't think we should repeat that experience.

If there are broken things causing serious impact to users for which
we already have a fix that's relatively small and localized, these
could be considered.  I'd expect there to be a very small list of
JIRAs falling into this category.

For new features, or bugs that are not causing serious user impact,
or things that need extensive code changes, or things that are not
fully ready and tested yet, I think we should defer them to the
next full release.

  Simon



Yours,  Mike.

Luciano Resende wrote:

In the past, there has been various requests for this feature in the
user/dev list, and unfortunately I couldn't get it ready by 1.2.
It seems like a reasonable time to add it now that we are going to
make this 1.2.1 release. BTW, the changes are localized and not so
big.

On Thu, May 15, 2008 at 3:07 PM, Simon Nash [EMAIL PROTECTED] wrote:

Luciano Resende wrote:

Any chance I could add the bpel reference support as part of this
release ? The changes are localized and won't affect other areas.


Is there a user requesting this support?  Remembering the 1.0.1
experience, I think we should keep this release as small and focused
as possible.

 Simon


On Thu, May 15, 2008 at 2:10 AM, ant elder [EMAIL PROTECTED] wrote:

I've had a request to do an official release that includes the fix for
TUSCANY-2304. I think this is reasonable so would like to do this, it
shouldn't be too hard as its a small fix so its just copying the 1.2
release
tag, applying the fix, spinning the new release artifacts and 
voting. I

know
we tried this before with 1.0.1 but that ended up with so much new
 function
it made it harder to get out, if 1.2.1 is kept really focused I 
hope it
would be easier.  I'd like to start this off tomorrow if no one has 
any

objections, WDYT?

There was also a suggestion that maybe a fix for TUSCANY-2251 could 
get

into
this, is that likely to be small and ready?

 ...ant

[jira] Commented: (TUSCANY-2277) Standardization of registering msg with monitor


[ 
https://issues.apache.org/jira/browse/TUSCANY-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597544#action_12597544
 ] 

Ramkumar Ramalingam commented on TUSCANY-2277:
--

Hi Simon,
The issue seems to be due to subeclipse. I did not realize that such characters 
would crop up due to subeclipse. I apologies for the inconvenience. I am just 
uploading a new set of patch for the same fixes.

Thanks,
Ramkumar R

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: TUSCANY-2277-Part1-New.rtf

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: (was: TUSCANY-2277-Part1-New.rtf)

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: TUSCANY-2277-Part1-New.patch

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, 
 TUSCANY-2277-Part2.patch, TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected


Scott Kurz wrote:

Why do we need to be so strict in comparing interfaces?

Can't we argue essentially the same point in the case with we have a Java
client w/ reference w/ Java intf with a binding.ws?

So, following this logic, it's suggested that the NS calculated per-JAXWS
for the Java intf must match the portType on the WS binding.

So, in the case (2) that Mike presented, say the Java is gen'd from the WSDL
of an existing WS w/ wsimport, embedding a
@WebService(name = ..., targetNamespace =  ...)in the Java.   Now
the WS evolves and we take the new WSDL w/ portType
in a new NS. Maybe a new operation is added but we don't care about it
from our existing client.   Why should we have to re-gen the Java to reflect
the new TNS?


Adding a new operation would be a compatible change to the interface
and should not result in the interface's TNS changing.


Also, someone using an older W2J tool may have an option to select a
non-standard pkg when generating Java from WSDL, but the tool doesn't
reflect this in the @WebService(... targetNamespace...).  Do we really need
to break them?


This is easy to deal with by configuring the reference binding to
refer to the WSDL binding that the client code is actually using
to make the invocation.  If the reference binding.ws doesn't specify
any WSDL binding, the binding.ws's interface contract should be
generated from the reference's interface.java.


Would people agree this is essentially the same case as the overridden,
promoted intf, or is the argument that this specific case is a bit different
?


It seems pretty similar to me.


I mean, I can certainly see how it simplifies the runtime authors' lives to
be strict about NS's when doing intf mapping...   but do we really have a
good reason to?What use case can we just not handle that would make us
need this restriction?


The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an
incorrect namespace was sent on the wire because SCA did not detect
the reference/service mismatch.

This problem is caused by a mismatch in the WSDL binding rather
than a mismatch in the Java interface.  However, the specs say that
the WSDL binding (including its namespace) is generated by applying
the JAX-WS Java2WSDL mapping to the Java interface.  If this
algorithm doesn't produce the same namespace that's used by the
service, the reference won't be able to interoperate with it.

  Simon


Scott



On Thu, Apr 17, 2008 at 12:09 PM, Raymond Feng [EMAIL PROTECTED] wrote:


+1 on Simon's proposal to add the getNamespace() on Interface from another
perspective: converting/mapping between IDLs.

Thanks,
Raymond
--
From: Simon Laws [EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 6:32 AM
To: tuscany-dev@ws.apache.org
Subject: Re: [jira] Commented: (TUSCANY-2109) Conflicts between component
reference interface and promoted composite reference interface are not
detected


 On Thu, Apr 10, 2008 at 10:14 PM, Simon Laws [EMAIL PROTECTED]

wrote:

 Hi Mike

Some comments in line

Simon


Folks,

It is right to be concerned over the interface matching, but let's 

not

lose sight of the context here.

In general, there are two scenarios to consider:

a) the reference is to a service which is defined within the SCA
domain and SCA means are used to wire it
b) the reference is to a service which is outside the SCA domain and
wiring is through configuration of a specific binding and target  

endpoint



This JIRA covers a very specific scenario which adds another twist where
there is a different between the interface definition of a composite
level
reference that promotes a component level reference.


In case a) it is possible that a Java interface as used by the client
in its reference is exactly the same (file) as is being used by the 

provider

in the service interface.  If this is so, then in general, even if 

WSDL is

generated, the reference and the target service are going to match, 

assuming

that the same rules are followed at both ends for generating WSDL. 

(They

should be following JAX-WS according to the specs).



It is certainly possible. Maybe even likely. But not guaranteed.


In case b), the normal situation would be for the client to be
constructed using a Java interface derived from the target WSDL using
the
WSDL2JAVA tooling.  While the reference targets the original service
from
which the WSDL came, there should be no problem, even if the  

reference

itself is typed in terms of the Java interface.

Things get interesting if the target service gets changed - and if 

the

WSDL describing the interface changes.  Now, to first order, you  

might say

that if the WSDL is different, how do you know that the new service 

is

compatible with the old one?  Even if the operation names match and 

the

input and output messages have the same structure, if the namespaces
differ,
there is no guarantee that the two services are actually compatible.

This proposed

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: (was: TUSCANY-2277-Part1-New.patch)

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

2008-05-16 Thread Raymond Feng

Please see my comments below.

Thanks,
Raymond

--
From: Simon Laws [EMAIL PROTECTED]
Sent: Friday, May 16, 2008 1:26 AM
To: tuscany-dev@ws.apache.org
Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed 
operation and extension implementations - was: Re: Request to propogate the 
value of a references target= attribute on its associated bindings model 
object

...snip

The two sets of SPIs could co-exist for a while with BindingProviders
working with bindings and ServiceProviders (I just made up that name) 
with

service endpoints.
--
Jean-Sebastien

At r656959 I've just enabled some changes to take a step toward using an
Endpoint representation in the model as an alternative to using cloned
bindings as the representation of valid reference targets. It's not
replacing the cloned binding approach just yet, to avoid breaking 
anything,

but is the first step on the road. This is what I have done.

Made a new Endpoint model type

+100. The schema kind of mixes the binding/endpoint concept together. I 
think it's much cleaner to add the endpoint model to represent the 
outbound/inbound addresses.

Created a separate factory for it (separate as I though the model may need
to be pluggable as some point)

Would it be possible to just add the create method the AssemblyFactory?

Created a new EndpointProvider type and associated factory.

I assume the EndpointProvider is a system utility that match/resolve the 
endpoints based on the reference/service binding configurations. If so, I 
suggest that name it differently such as EndpointResolver and we can just 
have the interface and default impl (no factory is required). We use the 
term Provider for binding/implementation extensions to provide their 
specific logic into Tuscany.

Created an Endpoint module to provide a provider implementation.
Created an Endpoint wire to trap attempted calls over unresolved endpoints
Separated off the Endpoint builder code into a new builder class. Same 
code

but easier to identify.
Added an endpoint collection to references
Used the Endpoint in the wire builder in place of the old internal target
structure. The logic is weaved in to the existing logic as follows.
 For references with no target, put the binding into reference binding as
before

I think it would be better to create an endpoint for the reference without 
target. There could be two cases, autowiring and binding with explicit URI 
to external services.

A few examples will help, for example:

reference name=myRef target=C1/S1
   binding.x/
   binding.y/
/reference

reference name=myRef target=C1/S1 C2/S1
   binding.x/
   binding.y/
/reference

reference name=myRef
   binding.x/
   binding.y/
/reference

reference name=myRef
   binding.x uri=http://x/
   binding.y uri=http://y/
/reference

 Create an Endpoint for all explicit reference targets
 For resolved endpoints (Endpoints where the target is resolved) put the
binding into reference bindings, i.e. the same as before
 For unresolved endpoints create an endpoint provider and a wire. We don't
have unresolved targets in tuscany (except in the sca binding test) so
should not happen. If you do put a target name in that can't be matched 
with

a service you'll get a warning.

If there is no Endpoint module on the classpath it will not create a
provider or a wire hence disabling any Endpoint based processing. The
Endpoint model will still be used though

As part of this change I've updated the logic that looks for target names 
in

binding uri. It's now applied to all binding types which I believe is what
the spec says, There is though an issue here. I'll raise a separate 
thread.

There are also a couple of thoughts I had.

Can we make the CompositeBuilderImpl have just one constructor?
Should builders be pluggable?
I've used some of the CompoisteActivator functions in the EndpointWire 
that

could do with moving into the activator interface.

Simon

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: TUSCANY-2277-Part2-New.patch

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, 
 TUSCANY-2277-Part2-New.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3-New.patch, TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TUSCANY-2277) Standardization of registering msg with monitor


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

Ramkumar Ramalingam updated TUSCANY-2277:
-

Attachment: TUSCANY-2277-Part3-New.patch

 Standardization of registering msg with monitor
 ---

 Key: TUSCANY-2277
 URL: https://issues.apache.org/jira/browse/TUSCANY-2277
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Assembly Model
Affects Versions: Java-SCA-Next
 Environment: Windows XP
Reporter: Ramkumar Ramalingam
Assignee: Simon Laws
 Fix For: Java-SCA-Next

 Attachments: TUSCANY-2277-Part1-New.patch, TUSCANY-2277-Part1.patch, 
 TUSCANY-2277-Part2-New.patch, TUSCANY-2277-Part2.patch, 
 TUSCANY-2277-Part3-New.patch, TUSCANY-2277-Part3.patch


 Lokking at the monitors that are being hooked up with different parts of the 
 code, found  that we have some inconsistency interms of raising warning  
 errors. In some places we throw exceptions and in other places we raise a 
 warning. 
  
 Here are some examples for the inconsistency...
  
 BaseConfigurationBuilderImpl.java
 Here we raise only a warning for URISyntaxException, should we not throw an 
 exception too?
  
 BaseWireBuilderImpl.java
 Here we throw exceptions for IncompatibleInterfaceContractException, don't 
 you think we also need to register this message in our monitor?
 In the same class, we raise a warning message for the PolicyRelated 
 Exceptions, should we also throw an exception here?
  
 CompositeProcessor.java
 There are instances where we throw new ContributionReadException, i believe 
 registering this msg with a monitor is also required as this is caused by 
 incorrect user input.
 From Simon's comments on how we can go ahead with handling such instance, we 
 will fix the issue as discussed
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30994.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tomcat deploy of samples fails

2008-05-16 Thread Raymond Feng


Hi,

Which version of Tuscany are you trying? It seems that something went wrong 
in the bootstrap (we need to dig out the root cause of the exception). Can 
you also try on Tomcat 6.x?


Thanks,
Raymond
--
From: Magnus Stoveland [EMAIL PROTECTED]
Sent: Friday, May 16, 2008 7:04 AM
To: tuscany-dev@ws.apache.org
Subject: Tomcat deploy of samples fails

I've successfully compiled the sample helloworld-ws-sdo-webapp into 
sample-helloworld-ws-sdo-webapp.war. But when I try to deply the .war to 
Tomcat 5.5.26, I get the following error: FAIL - Application at context 
path /sample-helloworld-ws-sdo-webapp could not be started.


From the log:

- Exception starting filter tuscany
javax.servlet.ServletException: 
org.apache.tuscany.sca.implementation.node.webapp.NodeWebAppServletHost
   at 
org.apache.tuscany.sca.node.launcher.NodeServletFilter.init(NodeServletFilter.java:85)
   at 
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221)
   at 
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:302)
   at 
org.apache.catalina.core.ApplicationFilterConfig.init(ApplicationFilterConfig.java:78)
   at 
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3635)
   at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4222)
   at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:760)
   at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:740)
   at 
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544)
   at 
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831)
   at 
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:720)
   at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)

   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
   at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
   at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1022)

   at org.apache.catalina.core.StandardHost.start(StandardHost.java:736)
   at 
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014)
   at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
   at 
org.apache.catalina.core.StandardService.start(StandardService.java:448)
   at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:700)

   at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
- Error filterStart

Do I need any special configuration/setup to get the Tuscany Servlet 
Filter running properly?


Magnus

Re: Tuscany support for Axis 1.4

2008-05-16 Thread Raymond Feng


Hi,

I'm starting to look into the performance improvements in the JAXB/AXIOM 
data transformation. It seems that the Axis2 1.4 has done a lot of good work 
there. If possible, I would like to leverage the latest AXIOM and Axis2 code 
base ASAP. The dependency might be only AXIOM but mixing the versions of 
AXIOM could be very risky.


Thanks,
Raymond

--
From: ant elder [EMAIL PROTECTED]
Sent: Thursday, May 15, 2008 3:00 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany support for Axis 1.4


On Wed, May 14, 2008 at 2:33 PM, Mike Edwards
[EMAIL PROTECTED] wrote:

Lou Amodeo wrote:


Is there a plan for Tuscany to support Axis2 1.4?


Lou,

Any particular goodies that we can expect to get by moving up to Axis 
1.4?


Yours,  Mike.



Not sure if there are new functions that we need in 1.4 but the
release does include _lots_ of bug fixes so i think it would be worth
moving up. The main issues right now is I've just noticed there isn't
a corresponding Apache Rampart release for 1.4 yet which is what we
need for WS-Security, looks like its coming so guess we'll just have
to wait a bit.

  ...ant

Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected

2008-05-16 Thread Scott Kurz

On Fri, May 16, 2008 at 1:04 PM, Simon Nash [EMAIL PROTECTED] wrote:

 Scott Kurz wrote:

 Why do we need to be so strict in comparing interfaces?

 Can't we argue essentially the same point in the case with we have a Java
 client w/ reference w/ Java intf with a binding.ws?

 So, following this logic, it's suggested that the NS calculated per-JAXWS
 for the Java intf must match the portType on the WS binding.

 So, in the case (2) that Mike presented, say the Java is gen'd from the
 WSDL
 of an existing WS w/ wsimport, embedding a
 @WebService(name = ..., targetNamespace =  ...)in the Java.   Now
 the WS evolves and we take the new WSDL w/ portType
 in a new NS. Maybe a new operation is added but we don't care about it
 from our existing client.   Why should we have to re-gen the Java to
 reflect
 the new TNS?

  Adding a new operation would be a compatible change to the interface
 and should not result in the interface's TNS changing.


I'm imagining an organization rolls out a whole new deployment of some
service, and changes the TNS
in various WSDL/XSDs to reflect that this is version 2.0, or whatever, of
the deployment.   They wouldn't have
to change the TNS, but they might want to, right?



  Also, someone using an older W2J tool may have an option to select a
 non-standard pkg when generating Java from WSDL, but the tool doesn't
 reflect this in the @WebService(... targetNamespace...).  Do we really
 need
 to break them?

  This is easy to deal with by configuring the reference binding to
 refer to the WSDL binding that the client code is actually using
 to make the invocation.  If the reference binding.ws doesn't specify
 any WSDL binding, the binding.ws's interface contract should be
 generated from the reference's interface.java.


Maybe I'm reading into the discussion too much but I was assuming that being
proposed was doing
a similar sort of interface compatibility testing between the Java client's
intf.java and the binding.ws
WSDL intf contract.   In other words, I thought we were getting at the point
that, in Tuscany across the board, IDLs would
only be considered as matching if they matched namespaces (the IDL-neutral
equiv. of TNS, Java pkg, etc.).

If this is not what others had in mind, then wrt to the interface
compatibility testing being proposed,
this case does differ from the promoted ref intf case and will be treated
separately.  That's one of the
questions I was asking.




  Would people agree this is essentially the same case as the overridden,
 promoted intf, or is the argument that this specific case is a bit
 different
 ?

  It seems pretty similar to me.

  I mean, I can certainly see how it simplifies the runtime authors' lives
 to
 be strict about NS's when doing intf mapping...   but do we really have a
 good reason to?What use case can we just not handle that would make us
 need this restriction?

  The use case that triggered TUSCANY-2033 and TUSCANY-2109, where an
 incorrect namespace was sent on the wire because SCA did not detect
 the reference/service mismatch.

 This problem is caused by a mismatch in the WSDL binding rather
 than a mismatch in the Java interface.  However, the specs say that
 the WSDL binding (including its namespace) is generated by applying
 the JAX-WS Java2WSDL mapping to the Java interface.  If this
 algorithm doesn't produce the same namespace that's used by the
 service, the reference won't be able to interoperate with it.

  Simon


There's another angle to view this from in which the error is not caused by
a mismatch, per se, but rather
by the fact that the intf.wsdl used to configure the promoted reference is
not honored.

Why is the Java2WSDL done at all, when the user has described the interface
with a WSDL?So why does it
matter that the Java2WSDL we would have done doesn't match the WSDL we have
in hand?

Scott

Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected