Intermittent failures when building scripting modules
I see the following error quite frequently when building samples/calculator-script. I have also seen a similar exception when building the implementation-script module. Has anyone else seen this? Any ideas as to the cause? Simon Running calculator.CalculatorTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.568 sec FA ILURE! testCalculator(calculator.CalculatorTestCase) Time elapsed: 2.523 sec ERRO R! java.lang.NoSuchMethodError: javax.script.Bindings.put(Ljava/lang/String;Ljava/l ang/Object;)Ljava/lang/Object; at org.apache.tuscany.sca.implementation.script.engines.TuscanyJRubyScri ptEngine$3.defineReadonly(TuscanyJRubyScriptEngine.java:299) at org.jruby.Ruby.defineReadonlyVariable(Ruby.java:1016) at org.jruby.RubyClassPathVariable.createClassPathVariable(RubyClassPath Variable.java:44) at org.jruby.Ruby$1.load(Ruby.java:659) at org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:307) at org.jruby.runtime.load.LoadService.require(LoadService.java:333) at org.jruby.RubyKernel$1.load(RubyKernel.java:245) at org.jruby.runtime.load.LoadService.autoload(LoadService.java:355) at org.jruby.RubyModule.getConstantAt(RubyModule.java:887) at org.jruby.Ruby.getModule(Ruby.java:459) at org.jruby.javasupport.JavaSupport.getJavaModule(JavaSupport.java:175) at org.jruby.javasupport.JavaSupport.getJavaObjectClass(JavaSupport.java :189) at org.jruby.javasupport.JavaObject.init(JavaObject.java:62) at org.jruby.javasupport.JavaObject.wrap(JavaObject.java:72) at org.jruby.javasupport.Java.primitive_to_java(Java.java:764) at org.jruby.javasupport.Java.ruby_to_java(Java.java:796) at org.apache.tuscany.sca.implementation.script.engines.TuscanyJRubyScri ptEngine.rubyToJava(TuscanyJRubyScriptEngine.java:221) at org.apache.tuscany.sca.implementation.script.engines.TuscanyJRubyScri ptEngine.rubyToJava(TuscanyJRubyScriptEngine.java:217) at org.apache.tuscany.sca.implementation.script.engines.TuscanyJRubyScri ptEngine.evalNode(TuscanyJRubyScriptEngine.java:420) at org.apache.tuscany.sca.implementation.script.engines.TuscanyJRubyScri ptEngine.eval(TuscanyJRubyScriptEngine.java:193) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:62) at org.apache.tuscany.sca.implementation.script.ScriptInvokerFactory.ini t(ScriptInvokerFactory.java:111) at org.apache.tuscany.sca.implementation.script.ScriptInvokerFactory.cre ateInvoker(ScriptInvokerFactory.java:83) at org.apache.tuscany.sca.extension.helper.impl.ImplementationImplementa tionProvider$InvokerProxy.init(ImplementationImplementationProvider.java:95) at org.apache.tuscany.sca.extension.helper.impl.ImplementationImplementa tionProvider$InvokerProxy.invoke(ImplementationImplementationProvider.java:89) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCAB indingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java:287) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java:154) at $Proxy5.subtract(Unknown Source) at calculator.CalculatorServiceImpl.subtract(CalculatorServiceImpl.java: 58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementat ionInvoker.invoke(JavaImplementationInvoker.java:132) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCAB indingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java:287) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JD KInvocationHandler.java:154) at $Proxy4.subtract(Unknown Source) at calculator.CalculatorTestCase.testCalculator(CalculatorTestCase.java: 47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124)
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Raymond Feng wrote: Hi, Mike. It's a very good summary. The different perspectives are now well separated and they should be discussed on different threads to avoid further confusions :-). Please see some more comments inline. I added a couple of responses on specific points below. Simon Thanks, Raymond -- From: Mike Edwards [EMAIL PROTECTED] Sent: Friday, June 13, 2008 2:08 PM To: tuscany-dev@ws.apache.org Subject: Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes Simon Nash wrote: Actually this isn't quite what I was saying. (Sorry that I wasn't clear.) I'm talking about the lowest level components that we distribute as binaries, not about larger groupings that are created from these components to provide convenient aggregations of functionality. These groupings might be useful as well, as you are suggesting here and Graham suggested in his recent post. So back to the basic components. I see no value at this level in breaking things down any lower than a unit of functionality that might be included or excluded as a whole from some valid scenario. To give an example, I wouldn't put everything related to Web services in a single basic component, because some users might want to create a minimal Web services configuration without Web services security and/or Web services policy. I also wouldn't put assembly and core in the same basic component, because some users might just want the Tuscany model without the Tuscany runtime. But I would put interface and assembly together in the same basic component, because there are no cases where one would be used without the other, and I would put core, core-databinding and databinding together in the same basic component for the same reason. Simon Simon, I'm not clear what components you are talking about here. It seems to me that we have things are different granularities, for different purposes and for different users, something like this (starting at the smallest): a) Basic modules, as we have today. These are largely for Tuscany developers, but they should represent a level of development independence. Some folk (including me) believe that it is these modules that should be OSGi bundles. If there really is NO reason to separate functionality, then we should merge modules at this level. I don't think that is necessary at present. +1. The OSGi bundles are the basic units to constitute the tuscany runtime and they formally defines the SPI contracts across the modules. Maven modules are the static/structural reflection of the same idea. There could reasons why a developer would want to separate functionality into multiple modules even though these modules are never separated when assembling the larger aggregrations at the b) and c) level. I see a few ways to handle this situation: 1) Optimize the module split around developer convenience and let the basic module structure reflect this. This could create finer-grained modules than are needed by the b) and c) levels. 2) Optimize the module split around the granularity that is needed by the b) and c) levels. This could create coarser-grained modules than are ideal from a developer perspective. 3) Create an additional level in the hierarchy between the a) and b) levels as defined here. This creates confusion and complexity. I have been arguing for some combination of 2) and 3). As a result of this discussion, I'd like to explore the alternative of using 1) in combination with a strengthened role for the b) level. This might provide the advantages of 2) and 3) without their disadvantages. So I'd like to suggest that we try to make progress at the b) level first and come back to the a) level when we know what the b) level looks like. b) A variety of functional components, that represent sets of coherent functions. Each consists of a series of the basic modules, aggregated together. Their function in life is to assist developers of applications that embed some level of Tuscany capability (including tools, Tuscany itself and so on) These are probably not agreed by folk today - we have work to do here to define these. You demonstrate the problem in your example above - you want Basic Web Services separate from Web Services Security - but for an end user, the step from using the first to using the second is a trivial addition of @required=integrity to the SCDL. Anyone care to have a go at defining these compoennts? What physical representations of this layer? A library/collection of bundles like Eclispe feature? c) A small number of large packages aimed at supporting end users in a series of environments and with a specific set of functionality Frankly, the average end user would prefer as few of these as possible. 1 is ideal. However, I recognise that we are likely to have
[jira] Assigned: (TUSCANY-2298) Incorrect service endpoint when wsdl.service is used with Service webservice binding
[
https://issues.apache.org/jira/browse/TUSCANY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash reassigned TUSCANY-2298:
---
Assignee: Simon Nash
Incorrect service endpoint when wsdl.service is used with Service webservice
binding
Key: TUSCANY-2298
URL: https://issues.apache.org/jira/browse/TUSCANY-2298
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension, Java SCA Tomcat
Integration
Affects Versions: Java-SCA-1.2
Reporter: Vamsavardhana Reddy
Assignee: Simon Nash
Fix For: Java-SCA-Next
Web Service Binding Specification Spec v1.00 - Sec 2.1 - lines 38 to 41:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
When wsdlElement is of 'Service' type, service must be available on all ports
corresponding to the service. The following is the wsdl I am using for
'AService':
{code}
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/;
xmlns:ns0=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/;
xmlns:http=http://schemas.xmlsoap.org/wsdl/http/;
xmlns:ns1=http://org.apache.axis2/xsd;
xmlns:wsaw=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:ns=http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element name=getGreetings
xs:complexType
xs:sequence
xs:element minOccurs=0 name=param0
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getGreetingsResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings
/wsdl:part
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse
/wsdl:part
/wsdl:message
wsdl:portType name=AServicePortType
wsdl:operation name=getGreetings
wsdl:input message=ns0:getGreetingsRequest
wsaw:Action=urn:getGreetings
/wsdl:input
wsdl:output message=ns0:getGreetingsResponse
wsaw:Action=urn:getGreetingsResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType
soap12:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap12:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap12:body use=literal/
/wsdl:input
wsdl:output
soap12:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType
http:binding verb=POST/
wsdl:operation name=getGreetings
http:operation location=AService/getGreetings/
wsdl:input
mime:content part=getGreetings type=text/xml/
/wsdl:input
wsdl:output
mime:content part=getGreetings type=text/xml/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
Re: Branching for Release 1.3 was: Re: Release 1.3?
Simon Laws wrote: On Sat, Jun 14, 2008 at 12:11 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'm done with the JSR 250 issues, and got a clean build from latest svn revision. On Fri, Jun 13, 2008 at 1:34 PM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Jun 13, 2008 at 9:32 PM, Raymond Feng [EMAIL PROTECTED] wrote: I just checked in some improvements in the databinding area after a full clean build. Now I will stay away from the code :-). Thanks, Raymond -- From: Simon Laws [EMAIL PROTECTED] Sent: Friday, June 13, 2008 11:16 AM To: tuscany-dev@ws.apache.org Subject: Branching for Release 1.3 was: Re: Release 1.3? I'm just trying to finish up the changes required to unhook the old domain modules from the runtime, tests and samples. Then I'm pretty much done with things I want to do before cutting the R1.3 branch. I'm planning on doing this first thing tomorrow morning UK time. Can you let me know if there are changes you are working on that you want to finish before I cut the branch. Also if there are changes you have that don't need to go in the branch can you hold back for a little while as I get this done. Obviously I'd like to keep the trunk as stable as possible for the next 12 hours so if people have time to give the code a spin and do a build that would be great. Particularly after I've checked in the build changes related to domain. I'll post when I'm done. Regards Simon Great, thanks Raymond. I'll do an update and another build. Could you do the same to try the domain removal changes I checked in? Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ OK, thanks everyone. I've now taken the branch for 1.3 so feel free to do as you will with trunk. I'll start the process of tidying release, removing the dead modules etc. shortly. I've created a Java-SCA-1.3 category in JIRA so any new issues for the branch in there please. Thanks Simon I checked in a fix for TUSCANY-2298 as r668020. I did a full build before and after applying the patch, and everything was OK. Simon
[jira] Resolved: (TUSCANY-2298) Incorrect service endpoint when wsdl.service is used with Service webservice binding
[
https://issues.apache.org/jira/browse/TUSCANY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash resolved TUSCANY-2298.
-
Resolution: Fixed
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.3
Fixed under r668025 in trunk, and r668020 in the 1.3 branch.
Incorrect service endpoint when wsdl.service is used with Service webservice
binding
Key: TUSCANY-2298
URL: https://issues.apache.org/jira/browse/TUSCANY-2298
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension, Java SCA Tomcat
Integration
Affects Versions: Java-SCA-1.2
Reporter: Vamsavardhana Reddy
Assignee: Simon Nash
Fix For: Java-SCA-1.3
Web Service Binding Specification Spec v1.00 - Sec 2.1 - lines 38 to 41:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
When wsdlElement is of 'Service' type, service must be available on all ports
corresponding to the service. The following is the wsdl I am using for
'AService':
{code}
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/;
xmlns:ns0=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/;
xmlns:http=http://schemas.xmlsoap.org/wsdl/http/;
xmlns:ns1=http://org.apache.axis2/xsd;
xmlns:wsaw=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:ns=http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element name=getGreetings
xs:complexType
xs:sequence
xs:element minOccurs=0 name=param0
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getGreetingsResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings
/wsdl:part
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse
/wsdl:part
/wsdl:message
wsdl:portType name=AServicePortType
wsdl:operation name=getGreetings
wsdl:input message=ns0:getGreetingsRequest
wsaw:Action=urn:getGreetings
/wsdl:input
wsdl:output message=ns0:getGreetingsResponse
wsaw:Action=urn:getGreetingsResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType
soap12:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap12:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap12:body use=literal/
/wsdl:input
wsdl:output
soap12:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType
http:binding verb=POST/
wsdl:operation name=getGreetings
http:operation location=AService/getGreetings/
wsdl:input
mime:content part=getGreetings type=text/xml/
/wsdl:input
wsdl:output
mime:content part=getGreetings type=text/xml/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap:body use
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Graham Charters wrote: +1 from me also. We shouldn't confuse modularity purely with versioning or whether something can be used on its own. It's also about being able to make different combinations of modules to fit different deployment profiles. I agree with that, and this should be considered as part of the use cases that would determine the granularity of the bundles. If there is no possible deployment profile that can include A and not B, or vice versa, then I don't see a case for having A and B as separate bundles. I think it was Ant who first brought up the distinction between what make sense in terms of modularity and what makes sense from a user's perspective. I think having 1 bundle per Tuscany module and third-party jar is fine so long as we provide some way of aggregating those in ways that make sense for how users will consume them. For example, I as a user might want to think in terms of a core runtime + implementation type X and binding Y. That's three concepts to me, not 123 bundles. This might be valuable as well as a higher-level grouping of bundles into different functional profiles. But it doesn't change the fundamental question of what is the minimum independently aggregatable unit of functionality that is encapsulated in a single bundle. Simon Hope this make sense. Regards, Graham. 2008/6/12 Jean-Sebastien Delfino [EMAIL PROTECTED]: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! -- Jean-Sebastien
Re: Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
Simon Nash wrote: Raymond Feng wrote: Hi, Do any of you see this failure too? Yes, I see it. It appears the test is wrong, and this is now showing up because of my recent check-in r666738 in which I fixed a problem where the conversation object was incorrectly being returned as null even though there is an active conversation. This test appears to be checking for the incorrect behaviour. The call b.testNullConversation() creates a conversation, since the BComponent interface is @Conversational and BComponentImpl has @Scope(CONVERSATION). Calling RequestContext.getConversation() while this method is active should return non-null, not null. I fixed this test case under r667036. Simon Simon Thanks, Raymond org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation() java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:69) at org.junit.Assert.assertTrue(Assert.java:32) at org.junit.Assert.assertNull(Assert.java:256) at org.junit.Assert.assertNull(Assert.java:265) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy14.testNullConversation(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Re: Build issues...
Simon Laws wrote:
I'm trying to apply the patches on TUSCANY-2347 so these issues here may be
caused by these changes however
The first problem I see is that I get a NPE in samples/helloworld-bpel.
Caused by: java.lang.NullPointerException
at
org.apache.tuscany.sca.implementation.bpel.xml.BPELPartnerLinkElement.getRolePortType(BPELPartnerLinkElement.java:82)
at
org.apache.tuscany.sca.implementation.bpel.xml.BPELPartnerLinkElement.getMyRolePortType(BPELPartnerLinkElement.java:73)
at
org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor.generateComponentType(BPELImplementationProcessor.java:228)
at
org.apache.tuscany.sca.implementation.bpel.impl.BPELImplementationProcessor.resolve(BPELImplementationProcessor.java:152)
I just did a clean checkout and build and I'm not seeing this problem.
Simon
The failure is because in
private PortType getRolePortType( String theRole ) {
if( theRole == null ) return null;
if ( theRole.equals( pLinkType.getRole1Name() ) ) {
pLinkType is null. The only place that my IDE tells me that this is set is
during BPELDocumentProcessor.resolve()
However there is a line at the top of BPELDocumentProcessor.resolve() which
jumps out if the model is already resolved
if (model == null || !model.isUnresolved())
return;
As far as I can tell the model will always be resolved because
BPELDocumentProcessor.read() does.
processDefinition = indexRead2(artifactURL);
processDefinition.setURI(artifactURI);
processDefinition.setUnresolved(false);
Now this code hasn't changed in the last few days so this must work somehow.
So I'm just putting this out there so that someone can point out the error
of my ways while I investigate;-)
Simon
Re: SVN build process.
Simon Laws wrote: On Thu, Jun 12, 2008 at 10:22 AM, ant elder [EMAIL PROTECTED] wrote: 20 minutes! what sort of super machine do you have, its approaching an hour on my machine! I do agree with the principal though. I think one of the problems is its just getting so big we try to take short cuts by not always building everything, in the restructuring of future releases thats being talked about on other threads maybe we should try to break up the build somehow so some parts can be more independent parts of the build somehow to make it a bit smaller and faster. ...ant On Thu, Jun 12, 2008 at 10:15 AM, Giorgio Zoppi [EMAIL PROTECTED] wrote: Hi, i've a proposal for current svn. We could make most of our effort to make the svn compile. I suggest to trying a fresh build before committing meaniful things and after committing. It's matter of 20 minutes but it saves us more times. If doens't compile, you might fix or disable what it doens't compile. For example yesterday the corba tests module didn't work from a fresh build. Ciao, Giorgio. --- Venceremos adelante, o victoria o muerte! I agree with Giorgio. We've seen a few breaks recently. I'm sure I'm to blame for some of them (i need to say that as I'm sure I'll cause one later having said this). Building the whole thing is getting really onerous but until we reorg the build we have to do it. We won't address this for 1.3 but I would like to see this high on the agenda for post 1.3. +1 for this. I would like to help make this reorg happen. The good news is that the full build is running OK now, after my recent commit to correct a bad test case that started failing yesterday when I fixed a bug. Apologies to those who have been inconvenienced by this. Simon
Re: Versioning of Tuscany
some assumption about the future compatibility of the 3rd party library. Without a crystal ball, this will be hard to get right every time. This is why I am suggesting a more conservative approach. [current.version, next.major.version) gives the best starting point IMO. In past notes about multiple extensions in Tuscany running with different versions of a 3rd party lib, I am not sure if the examples involved different major versions of a 3rd party lib. I would really like to understand real scenarios: 1. Why do we want two Tuscany extensions to use two different versions of a 3rd party library? Would these ever involve two minor versions at the same major version level? If so, couldn't both extensions just work with the higher of those two - do we really want to force one of them to work with the lower version? This could happen if the Tuscany extensions are using the same 3rd party library in different ways, such that one extension can't tolerate the upgrade to a higher level of the library but the other can tolerate it. 2. Why would an end user want to run Tuscany and an application with two different versions of a 3rd party library? Would these ever involve two minor versions at the same major version level? If so, what stops both from using the higher of the two? If the user is developing the application herself, that should not occur. If it's developed by someone else, this situation could apply. The user might need Tuscany level X and Other Application level Y. These might have different version dependencies on the same 3rd party library. Simon 2. You asked if we should be able to work with bundles from other projects (e.g. ServiceMix, SpringSource Application Platform). I wonder if we're able to learn from these projects to seed our versioning. The SpringSource repository, for example, seems to allow this, although I'm no legal expert [2]. Regards, Graham. [1] http://commons.apache.org/releases/versioning.html [2] http://www.springsource.com/repository/app/faq;jsessionid=3F9467729AC282FE4E08199FDCE40863#q6 2008/6/11 Rajini Sivaram [EMAIL PROTECTED]: Following on from the discussion on OSGi-enabling third party libraries ( http://markmail.org/message/snltdk2yovr6maq5), this thread addresses the options for versioning Tuscany bundles and 3rd party libraries distributed with Tuscany and the implications of choosing these options. I have put together some notes on the wiki ( http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Versioning) There were two outstanding questions from Simon Nash in the previous discussion which I will summarize here to ensure that they are not lost in this discussion. 1. Why can't we generate import constraints which will suit all applications? 2. *I'm concerned by the assumption here that Tuscany's versions of 3rd party bundles will be used both by Tuscany and by applications. An application may be using other software as well as Tuscany, and this other software may include its own versions of bundles for javax.servlet or jaxb. If Tuscany requires its versions of these bundles to be used, and the other software requires its versions to be used, this requires the application developer to understand how to resolve any conflicts.* The answer to 1) relates to how broad (or narrow) version ranges in imports are. Broad ranges prevent isolation and reduce scope for side-by-side execution, narrow ranges prevent class sharing and upgrading to newer versions. There is more detail with examples on the wiki. Question 2) is addressed first on the wiki (Figure 1 and Figure 2 show these scenarios). I would personally like to follow OSGi best practice and enable maximum sharing. There are some cases where we have no choice but to share (eg. SDO). I don't believe we can eliminate conflicts altogether - but following standard practice will make it less complicated for OSGi developers to resolve conflicts. Thoughts? Thank you... Regards, Rajini
Re: Tuscany support for Axis 1.4
Simon Laws wrote: On Thu, Jun 12, 2008 at 8:59 AM, ant elder [EMAIL PROTECTED] wrote: On Mon, Jun 9, 2008 at 10:17 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 14, 2008 at 1:12 PM, Lou Amodeo [EMAIL PROTECTED] wrote: Is there a plan for Tuscany to support Axis2 1.4? Axis2 1.4 and the associated wss4j and rampart releases for 1.4 are all out and available in the Maven repositories now. I've still a couple of issues to resolve to get everything in the build working with 1.4 but hope to have those fixed in the next day or 2 so would like to move up to 1.4 then This isn't going so well so I'm wondering if it would be better to NOT move up to Axis2 1.4 for the SCA 1.3 release. The are still some minor issues that are more of an inconvenience eg the way our soap/jms support is configured causes a big ugly stacktrace in samples that don't incude the JMS API now, but the main problem is with ws-security not working yet and when that is fixed a bug in WSS4J we'll like hit which may need a new release to fix [1]. How would people feel about staying on Axis2 1.3 for now, i know there's a dessire to get the latest versions of XmlSchema and AXIOM but will it break anything in our 1.3 release if we don't do that? ...ant [1] http://apache.markmail.org/message/2t7kdnf2tw33sphg Hi I would err on the side of caution with this. I don't think it's a blocker for cutting the branch for 1.3 and it sounds like we are still dependent on the 3rd party WSS4J 1.5.5 release which could take weeks. If this comes out and we are happy with it in trunk we can consider patching it into the 1.3 branch but I think we should go without it for now. Regards Simon I agree with the cautious approach. Simon
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Thu, Jun 12, 2008 at 10:50 AM, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Raymond Feng wrote: Hi, There are a few patterns we use to determine if a maven module is required. Let's take the contribution stuff as an example. 1) contribution contains the interfaces for the contribution model and default implementation classes, SPIs and extension points 2) contribution-xml deals with the reading/writing the xml document for the sca-contribution.xml 3) contribution-java, contribution-namspace, contribution-resource deal with a specific perspective of the contribution, for example, namespace, java, resource 4) contribution-osgi, contribution-groovy support specific packaging schemes of the SCA contributions. Please note there is a tree-like dependency graph. I don't think it makes sense to merge the siblings into one module. Since an ancestor (for example contribution) are shared by mulitple children (-xml, -osgi, etc), it also not desirable to merge the common ancestor with other modules. For databinding related modules, we have a similar strcuture: 1) databinding: The base model, SPIs and transformers for various XML technologies 2) databinding-jaxb, databinding-sdo, databinding-axiom, ... The individual databinding technologies 3) core-databinding: A set of hook code that leverage the databinding framework in the invocation chains (data transformation interceptors) We can use 1 as the data transformation utility in binding/implementation or even 3rd party code without 3. We can also pick one or more modules from 2. What I'm trying to point out is that our maven module structure reflects the nature of the feature units and dependencies fairly well. IMO, each module maps well into an OSGi bundle. IMHO, both the maven module and OSGi bundle follow the same principles and the results should be consistent. Thanks, Raymond +1 to all that, makes a lot of sense to me! Sorry, but it doesn't make sense to me. If there is no user scenario that can pull in contribution-java but not contribution-resource, or vice versa, I don't see why we would choose to expose these in our distro as separate bundles. For the databindings, there are user scenarios in which a subset would be needed by different users, so things like databinding-jaxb and databinding-sdo should be in separate bundles. However, core-databinding and databinding would always be used together, so should be in the same bundle. There might be a reason for keeping these modules separate in the maven build, to reflect an internal functional split. This internal structure is not relevant to Tuscany users and should not be exposed to them. I think our distro should have a bundle for a minimal basic core and bunldes for additional optional components that can be used in different combinations. The granularity of these bundles should be determined by what possible combinations make sense for people using the binary distro. Simon I do also agree with this despite what i just posted about how if we use the launcher approach then the actual module jars don't matter to users :) One group of users we want for Tuscany are those embedding Tuscany in other products, so having some aggregated jars that group modules by functionality would make it easier for them - eg an aggregated jar that contains the minimal Tuscany core runtime modules, another jar with all the web services related modules etc. Its really hard for an outsider (or even insider for that mater) working out what modules are needed for what, look at the tuscany-geronimo integration code which has never managed to keep up with Tuscany changes. I think we could do both, if we go for a new launcher approach and OSGi'ify everything then it might even make it easier to get the aggregated jars working well and its not so much overhead for us to maintain both sets of jars and use which ever are appropriate depending on the circumstances. The key thing will be to get _consensus_ on it so we're all working together instead of what we have now which seems to be we each focus on the bits we're interested in sometimes to the detriment of what other are trying to do. Actually this isn't quite what I was saying. (Sorry that I wasn't clear.) I'm talking about the lowest level components that we distribute as binaries, not about larger groupings that are created from these components to provide convenient aggregations of functionality. These groupings might be useful as well, as you are suggesting here and Graham suggested in his recent post. So back to the basic components. I see no value at this level in breaking things down any lower than a unit of functionality that might be included or excluded as a whole from some valid scenario. To give an example, I wouldn't put everything related to Web services in a single basic component, because some users might want to create a minimal Web services configuration without Web services security
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I wonder if some of this debate is due to us not all talking about they same thing so maybe it would help to go back to this proposal: Here's what I'd like to see as a user: - a short list of API JARs that I can add to my dev compile/build path - a single small launcher or bootstrap JAR that takes care of bootstrapping the Tuscany runtime - the launcher should detect the presence of installed extensions in a particular Tuscany installation - as a user / app developer I should not have to know the list of JARs from all these extensions. This is a fundamentally different approach from what we do today where we have all the Tuscany jars and dependencies on the application classpath. One of the main reasons for having jars of aggregated modules is to make it easier for users but if we change to have a runtime launcher which handles the all the module jars instead of the user then that reason goes away. To make this clear, today if a user has an Ant build script for their application that build script needs to hardcode each Tuscany module jar and dependency jar name so the build script breaks every time we change things. The tuscany-all and manifest jars help some but as has been pointed they have other problems. If we change to use the launcher approach then the Ant build script just needs to hardcode the Tuscany API and launcher bootstrap jar names and the location of the Tuscany install, and those few names should not change much over Tuscany releses so the user application doesn't get broken when we change Tuscany internal things. It doesn't really matter to the user if the actual Tuscany install folder has 10 jars or 200 jars all the they care about is the install location and the launcher handles it all for them. This is similar to developing webapps for Tomcat, to the user all they care about is the servlet-api jar and where Tomcat is installed, they don't care whats in the Tomcat server lib directory. One place where the number of jars definitely does show through is when retrieving these artifacts from the maven repos. Also, as discussed in your other email on this thread, when embedding and packaging Tuscany in other environments, it will be necessary to deal with the physical distributed artifacts. We did use this launcher approach back in M2 and we changed in 0.90 as a launcher makes things harder for Tuscany developers, for example when debugging Tuscany internals, but maybe _now_ it would be better to change back to a launcher approach as it makes things easier for users. I can see the advantages, and I'm OK with this as long as we can make the launcher and registry work conveniently in all the embedded scenarios where Tuscany might be used. I'm not quite clear on how 3rd party libraries would be handled using the registry approach. Would these continue to be taken from the classpath, or would they be loaded from the registry? For ease of integration with user/application code that uses some of the same libraries, I think it's best to take these from the classpath, except when running in an OSGi environment. Simon ...ant
[jira] Assigned: (TUSCANY-2312) Runtime ignores custom callback when using setCallback()
[ https://issues.apache.org/jira/browse/TUSCANY-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-2312: --- Assignee: Simon Nash Runtime ignores custom callback when using setCallback() Key: TUSCANY-2312 URL: https://issues.apache.org/jira/browse/TUSCANY-2312 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec states: /** * Lines 728-732 * p * By default, the client component of a service is assumed to be the * callback service for the bidirectional service. However, it is possible * to change the callback by using the ServiceReference.setCallback() * method. The object passed as the callback should implement the interface * defined for the callback, including any additional SCA semantics on that * interface such as its scope and whether or not it is remotable. */ I am getting the following error when I try to provide a custom callback using ServiceReference.setCallback(). I appears that the runtime has injected the client service as the callback rather then the user provided callback resulting in the following exception: java.lang.IllegalArgumentException: java.lang.NoSuchMethodException: No matching method for operation callBack is found on class org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:148) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:315) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:184) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:197) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy27.callBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.BServiceImpl.testCallBack(BServiceImpl.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.CallbackInterfaceInterceptor.invoke(CallbackInterfaceInterceptor.java:43) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy26.testCallBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl.testCallback(AServiceImpl.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64
[jira] Resolved: (TUSCANY-2312) Runtime ignores custom callback when using setCallback()
[ https://issues.apache.org/jira/browse/TUSCANY-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2312. - Resolution: Fixed Fixed in r666738 and r666740. The commit for r666738 also includes a fix for a problem where a conversational service implementation that calls RequestContext.getServiceReference() was getting a CallableReference without a conversation object attached. Runtime ignores custom callback when using setCallback() Key: TUSCANY-2312 URL: https://issues.apache.org/jira/browse/TUSCANY-2312 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec states: /** * Lines 728-732 * p * By default, the client component of a service is assumed to be the * callback service for the bidirectional service. However, it is possible * to change the callback by using the ServiceReference.setCallback() * method. The object passed as the callback should implement the interface * defined for the callback, including any additional SCA semantics on that * interface such as its scope and whether or not it is remotable. */ I am getting the following error when I try to provide a custom callback using ServiceReference.setCallback(). I appears that the runtime has injected the client service as the callback rather then the user provided callback resulting in the following exception: java.lang.IllegalArgumentException: java.lang.NoSuchMethodException: No matching method for operation callBack is found on class org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.AServiceImpl at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInvoker(JavaImplementationProvider.java:148) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addImplementationInterceptor(RuntimeWireImpl.java:315) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:188) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:115) at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:120) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:184) at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:197) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:228) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:167) at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:109) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:243) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:91) at $Proxy27.callBack(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.conversation.callback.custom.impl.BServiceImpl.testCallBack(BServiceImpl.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.CallbackInterfaceInterceptor.invoke(CallbackInterfaceInterceptor.java:43) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy26.testCallBack(Unknown Source
[jira] Commented: (TUSCANY-2247) vtest content for Java API spec - Conversation/Async
[ https://issues.apache.org/jira/browse/TUSCANY-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604274#action_12604274 ] Simon Nash commented on TUSCANY-2247: - I have fixed TUSCANY-2312 now. 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.
Re: Tracking Tuscany extensions, was: Distribution zips and what they contain, was: SCA runtimes
Comments inline. Simon Rajini Sivaram wrote: On 6/10/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On Tue, Jun 10, 2008 at 5:37 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Nash wrote: ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. Huh, Yes sure, we'd enforce OSGi rules when running in an OSGi environment... What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. We've already rehashed this (and disagreed on this) in several other threads, where I've already given my opinion: - 1 bundle per module - clean API/SPI imports/exports By 1 bundle per module do you mean any sort bundled jar combining multiple of our tuscany/java/sca/module jars is not worth pursuing? ...ant I think that the right design is one bundle per maven module. From an OSGi point of view I would like to ensure that we will continue to have one bundle per 3rd party jar and that these will not be aggregated regardless of how the distribution is zipped up. As for one bundle per maven module, I think there are pros and cons for finely grained and coarsely grained bundles, and it is really just a matter of preference. Since we anyway have nearly 150 3rd party bundles/jars anyway, I personally dont see any problem with one bundle per module. I have a different view on this. See below. I don't think that aggregating multiple modules into a single bundle makes much sense, or they should be aggregated in a single Maven module in the first place. IMHO modularizing Tuscany is about code quality and maintenance - something internal benefitting Tuscany developers. So we have 100 modules based on the developer's view of Tuscany internals. That does not necessarily mean that end users have to deal with 100 bundles. If 20 core modules are very tightly coupled together and will only operate with each other, as far as an end user is concerned, this could as well be one bundle. Can a Tuscany user combine assembly-xml version 1.3.0 with assembly version 1.3.1? Or even implementation-java with implementation-java-runtime
Re: Test failure: org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation()
Raymond Feng wrote: Hi, Do any of you see this failure too? Yes, I see it. It appears the test is wrong, and this is now showing up because of my recent check-in r666738 in which I fixed a problem where the conversation object was incorrectly being returned as null even though there is an active conversation. This test appears to be checking for the incorrect behaviour. The call b.testNullConversation() creates a conversation, since the BComponent interface is @Conversational and BComponentImpl has @Scope(CONVERSATION). Calling RequestContext.getConversation() while this method is active should return non-null, not null. Simon Thanks, Raymond org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation() java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:69) at org.junit.Assert.assertTrue(Assert.java:32) at org.junit.Assert.assertNull(Assert.java:256) at org.junit.Assert.assertNull(Assert.java:265) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.impl.BComponentImpl.testNullConversation(BComponentImpl.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:133) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy14.testNullConversation(Unknown Source) at org.apache.tuscany.sca.vtest.javaapi.apis.callablereference.CallableReferenceTestCase.testGetConversation(CallableReferenceTestCase.java:103) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Re: Test failure: CallBackSetCallbackConvTestCase
Raymond Feng wrote: There are some mismatching in the exceptions. I fixed it under r666812. Thanks for fixing this. There are also some deeper problems with various wrong paths being taken through this test case. I am investigating and I will check in a further update when I am confident that my changes are OK, probably tomorrow. Simon Thanks, Raymond -- From: Raymond Feng [EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 11:54 AM To: tuscany-dev@ws.apache.org Subject: Test failure: CallBackSetCallbackConvTestCase Hi, Simon Nash. I'm seeing the following failure after I refreshed from r666738 (your fix for TUSCANY-2312). Thanks, Raymond --- T E S T S --- Running org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase CallBackSetCallbackConvServiceImpl message received: Knock Knock Entering CallBackSetCallbackObjectCallback callBackMessage: Who's There Entering callback increment: This should do it CallBackSetCallbackConvServiceImpl response sent CallBackSetCallbackConvServiceImpl message received: Knock Knock java.lang.reflect.UndeclaredThrowableException at $Proxy12.callBackMessage(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvServiceImpl.knockKnock(CallBackSetCallbackConvServiceImpl.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy11.knockKnock(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.test8(CallBackSetCallbackConvClientImpl.java:108) at org.apache.tuscany.sca.test.CallBackSetCallbackConvClientImpl.run(CallBackSetCallbackConvClientImpl.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:128) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy10.run(Unknown Source) at org.apache.tuscany.sca.test.CallBackSetCallbackConvTestCase.testCallBackSetCallback(CallBackSetCallbackConvTestCase.java:31) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125
Re: Release 1.3?
Mike Edwards wrote: Simon Laws wrote: It's been a little while now since we did our 1.2 release. Since then there has been lots of activity and of course we have graduated. It feels like the right time to do a 1.3 release. Looking back at the mail list over the last couple of months there are quite a few candidates for inclusion that I can see; Better BPEL support Improvements to the domain manager app Improved runtime Java2WSDL processing Support for validation monitoring Databinding improvements Performance improvements JSR250 annotation support OSGi support improvements and a simple OSGi runtime test Java 2 security enablement Quite a few more tests for various parts of the runtime Lots of JIRA fixes. and of course we can remove the incubating assignment and drum up a bit of publicity for our TLP graduation I'd also like to have a bit of a tidy up for this release and remove the old domain modules we are no longer using (I'll post on this separately) What else has been added or changed? I think the things I would like to get done can be closed off next week ready to cut a branch. Thoughts? Simon Yes, I give a +1. BPEL is looking a lot better now. I'd like to add a couple of more sophisticated itests/samples as well and the release will be a good spur. Yours, Mike. I think this is a good time to do a 1.3 release. This would make the new runtime Java2WSDL generation available to Tuscany users, and resolve a number of issues with the previous code generation that used Axis2. The other improvements listed are valuable as well. Simon
Tuscany overriding of Axis2 code
I just committed r666041 which removes the copied processListService() code from TuscanyListingAgent, and instead uses an override of extractServiceName() to get the necessary Tuscany-specific behaviour. This was needed because the TuscanyListingAgent.processListService() code was older than the base code in Axis2 1.3 that it was overriding, and this was causing problems with ?wsdl for WSDL files that used wsdl:import. When we move up to Axis2 1.4, it would be a good idea to check all the Tuscany overrides of Axis2 code to make sure there aren't any other similar cases. Simon
WSDL generation when binding.ws specifies a WSDL file
The SCA Web Service binding spec says that a WSDL document should be generated for a service that uses binding.ws. This applies whether or not the binding.ws element specifies an existing WSDL document. If the binding.ws element specifies an existing WSDL document, the generated WSDL document contains wsdl:import statements referring to the existing WSDL document. Currently Tuscany does not do this, but reuses the existing WSDL document and may augment it with additional service, port, or binding information. This can cause problems, such as the problem described in TUSCANY-2323 where the existing document is lacking one of the prefixes required by the elements that are added. It also leads to a confusing mix of user-written code and generated code within the same document, and prevents Tuscany from using the target namespaces for WSDL services, ports and bindings that are specified by SCA. I would like to fix TUSCANY-2323, as well as these other issues, by implementing the mechanism described in the spec for generating a new WSDL document in all cases. So far I have prototyped a simple case of this and got it working. If anyone has concerns about this approach, please indicate these before I get too much further down this path. Thanks, Simon
Re: Distribution zips and what they contain, was: SCA runtimes
ant elder wrote: On Tue, Jun 10, 2008 at 3:02 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: I'd like to discuss the following: What distro Zips are we building and what do they contain? I think we could improve our distro scheme to provide: - smaller packages - easier for people to find what they need I was thinking about the following binary distro zips: - tuscany-core.zip - The base that everybody needs. core assembly model and runtime Java APIs, Java components - tuscany-web.zip - For WS and Web developers WS binding, Web 2.0 bindings, Scripting components, Widget components - tuscany-jee.zip - For JEE app integration EJB, RMI and JMS bindings, Spring components - tuscany-process.zip - For process development BPEL and XQuery components - tuscany-all.zip - all of the above Note that I'm not trying to tackle release cycles and the potential for releasing the above zips independently in this discussion and I'm assuming that we release all of the above together. I'm also assuming that the relevant samples are included in each zip. This email was from 1/22/08, generated a lot of discussion for about 3 weeks, lots of opinions, no conclusion, no commits :) No commits as we haven't found much consensus yet. I still think the same as what I had posted then, plus additional ideas: - Use OSGi exports/imports to export clean SPIs, hide internals, and refine the contents of the distros and their dependencies. Disclaimer - Please don't get me wrong I'm not saying that one distro == one OSGi bundle, as I've already said several times on the list that the big-OSGi-bundle approach didn't make sense to me :) I just think that declaring and enforcing clean dependencies using OSGi will help us refine the contents of each distro. The term enforcing seems to suggest that there might be an OSGi dependency for the Tuscany runtime. I don't know if this was intended. I think the right approach is to have a Tuscany+OSGi runtime (as we are building in itest\osgi-tuscany) which would actually do enforcement, and a non-OSGi Tuscany runtime in which the exports/imports are present in the jars but not enforced. What would be the granularity of these OSGi bundles? If the bundles are the current maven modules, I think we will find a number of classes that need to be exported even though these classes are not considered part of the SPI or API that the module provides. To resolve this I see the following options: a) Export more than we really believe is correct. This leaves us in the current unsatisfactory position of exposing unwanted implementation internals. b) Combine multiple maven modules with a close implementation affinity into a single OSGi bundle, and only expose true APIs or SPIs from these bundles. c) Refactor the code to remove dependencies on internals of other modules, and create new SPIs or APIs when this isn't possible. I believe a combination of b) and c) is the best approach. - Instead of a tuscany-manifest JAR or tuscany-all JAR, use an extension registry mechanism (what we have now in Tuscany or better a combination of what we have now and the Eclipse Equinox registry for example) to detect which pieces are installed and activate their capabilities. Can you say a bit more about what an extension registry mechanism would look like? What the tuscany-all/manifest jar are trying to do is to have users not need to know about the internal makeup of Tuscany. So they can simply use tuscany-all and avoid needing to know about all the dozens of different Tuscany modules and their dependencies, and that should keep working over many Tuscany releases whereas as we keep adding/deleting/changing the modules we keep breaking user builds for each Tuscany release if they refer to the individual modules. Maybe the granularity isn't quite right yet and we need something in between the all jar and all the individual modules. Is there much agreement that avoiding users needing to know about the internal Tuscany modules is a Good Thing? Yes, I think this is important. Ideally the Tuscany core runtime would figure out which pieces are needed for the domain configuration and load these pieces automatically. Simon ...ant
[jira] Commented: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces
[ https://issues.apache.org/jira/browse/TUSCANY-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604079#action_12604079 ] Simon Nash commented on TUSCANY-2323: - This problem is caused by Tuscany not implementing the SCA Web Service binding specification correctly. This spec calls for the generation of a new WSDL document for an SCA service with a binding.ws element, even if this binding.ws element specifies an existing WSDL document. Any WSDL portType or binding specified in an existing WSDL document should be imported by the generated WSDL document. The contents of the generated WSDL document are entirely under Tuscany's control, and therefore Tuscany can ensure that it includes all necessary prefixes. Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces Key: TUSCANY-2323 URL: https://issues.apache.org/jira/browse/TUSCANY-2323 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2323-recreate.patch I am getting an error with generating wsdl using ?wsdl on the url for webservice when the original wsdl file used to specify the service interface does not use soap namespaces. The following is the wsdl file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://helloworld; xmlns:tns=http://helloworld; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=helloworld wsdl:types schema elementFormDefault=qualified targetNamespace=http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema; element name=getGreetings complexType sequence element name=name type=xsd:string/ /sequence /complexType /element element name=getGreetingsResponse complexType sequence element name=getGreetingsReturn type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetingsResponse name=parameters/ /wsdl:message wsdl:portType name=HelloWorld wsdl:operation name=getGreetings wsdl:input message=tns:getGreetingsRequest name=getGreetingsRequest/ wsdl:output message=tns:getGreetingsResponse name=getGreetingsResponse/ /wsdl:operation /wsdl:portType /wsdl:definitions The following is the composite: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite The error I am seeing is given below: May 16, 2008 12:13:52 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /HelloWorldService threw exception org.apache.axis2.AxisFault: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://schemas.xmlsoap.org/wsdl/soap/'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method. at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at org.apache.axis2.description.AxisService.printUserWSDL(AxisService.java:936) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1056) at org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:142) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter
[jira] Assigned: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces
[ https://issues.apache.org/jira/browse/TUSCANY-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-2323: --- Assignee: Simon Nash Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces Key: TUSCANY-2323 URL: https://issues.apache.org/jira/browse/TUSCANY-2323 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: TUSCANY-2323-recreate.patch I am getting an error with generating wsdl using ?wsdl on the url for webservice when the original wsdl file used to specify the service interface does not use soap namespaces. The following is the wsdl file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://helloworld; xmlns:tns=http://helloworld; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=helloworld wsdl:types schema elementFormDefault=qualified targetNamespace=http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema; element name=getGreetings complexType sequence element name=name type=xsd:string/ /sequence /complexType /element element name=getGreetingsResponse complexType sequence element name=getGreetingsReturn type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetingsResponse name=parameters/ /wsdl:message wsdl:portType name=HelloWorld wsdl:operation name=getGreetings wsdl:input message=tns:getGreetingsRequest name=getGreetingsRequest/ wsdl:output message=tns:getGreetingsResponse name=getGreetingsResponse/ /wsdl:operation /wsdl:portType /wsdl:definitions The following is the composite: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite The error I am seeing is given below: May 16, 2008 12:13:52 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /HelloWorldService threw exception org.apache.axis2.AxisFault: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://schemas.xmlsoap.org/wsdl/soap/'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method. at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at org.apache.axis2.description.AxisService.printUserWSDL(AxisService.java:936) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1056) at org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:142) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service
[jira] Commented: (TUSCANY-2323) Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces
[ https://issues.apache.org/jira/browse/TUSCANY-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604081#action_12604081 ] Simon Nash commented on TUSCANY-2323: - I checked in r666390 which fixes the symptoms reported. With this change, the patched test passes. I am leaving this JIRA as unresolved until I have committed an unpatched test. Error generating WSDL when the original wsdl file used to specify the service interface does not use soap namespaces Key: TUSCANY-2323 URL: https://issues.apache.org/jira/browse/TUSCANY-2323 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-1.2 Reporter: Vamsavardhana Reddy Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: TUSCANY-2323-recreate.patch I am getting an error with generating wsdl using ?wsdl on the url for webservice when the original wsdl file used to specify the service interface does not use soap namespaces. The following is the wsdl file: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace=http://helloworld; xmlns:tns=http://helloworld; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; name=helloworld wsdl:types schema elementFormDefault=qualified targetNamespace=http://helloworld; xmlns=http://www.w3.org/2001/XMLSchema; element name=getGreetings complexType sequence element name=name type=xsd:string/ /sequence /complexType /element element name=getGreetingsResponse complexType sequence element name=getGreetingsReturn type=xsd:string/ /sequence /complexType /element /schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part element=tns:getGreetings name=parameters/ /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part element=tns:getGreetingsResponse name=parameters/ /wsdl:message wsdl:portType name=HelloWorld wsdl:operation name=getGreetings wsdl:input message=tns:getGreetingsRequest name=getGreetingsRequest/ wsdl:output message=tns:getGreetingsResponse name=getGreetingsResponse/ /wsdl:operation /wsdl:portType /wsdl:definitions The following is the composite: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws uri=http://localhost:8085/HelloWorldService/ /service /component /composite The error I am seeing is given below: May 16, 2008 12:13:52 AM org.apache.catalina.core.StandardWrapperValve invoke SEVERE: Servlet.service() for servlet /HelloWorldService threw exception org.apache.axis2.AxisFault: WSDLException: faultCode=OTHER_ERROR: Can't find prefix for 'http://schemas.xmlsoap.org/wsdl/soap/'. Namespace prefixes must be set on the Definition object using the addNamespace(...) method. at org.apache.axis2.AxisFault.makeFault(AxisFault.java:417) at org.apache.axis2.description.AxisService.printUserWSDL(AxisService.java:936) at org.apache.axis2.description.AxisService.printWSDL(AxisService.java:1056) at org.apache.tuscany.sca.binding.ws.axis2.TuscanyListingAgent.processListService(TuscanyListingAgent.java:142) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2ServiceServlet.java:257) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128
Re: Build failure in helloworld-bpel sample
Matthieu Riou wrote:
I guess that would be me as the fix I did outlined another issue (as
described in the thread Luciano pointed at). So you guys expect to always
have all the tests passing on trunk all the time?
Yes, we do try to keep the tests passing. On the rare occasions where a
change breaks a test for some reason, and the problem can't be resolved
at the time the change is checked in, we would disable the test so
that a full build can still run cleanly, and post to the list or open
a JIRA to alert others to the issue.
Simon
Cheers,
Matthieu
On Thu, Jun 5, 2008 at 12:57 PM, Mike Edwards
[EMAIL PROTECTED] wrote:
Folks,
Someone has updated the code in SVN since this afternoon - so I am
investigating.
Yours, Mike.
Mike Edwards wrote:
Simon,
I did an SVN update and build of Tuscany earlier this afternoon and I did
not see this failure.
The code currently checked in to the Tuscany SVN was fixed up to avoid the
error listed by Luciano and certainly seems to work for me.
Is anyone else seeing the same problem that Simon is getting?
Yours, Mike.
Simon Nash wrote:
I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample. Are other people seeing this?
Any ideas?
Simon
Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org
}helloPartnerLink#hello
Creating invocation message:
args.: ?xml version=1.0 encoding=UTF-8?
hello xmlns=
http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdlmessageHello/message/hello
message..:?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello/message/hello/TestPart/message
Invocation status:RESPONSE
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 9.494 sec
ERRO
R!
junit.framework.ComparisonFailure: expected:Hello World but was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)
Results :
Tests in error:
testInvoke(helloworld.BPELHelloWorldTestCase)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
Re: [NOTICE] Scott Kurz voted as Tuscany committer
ant elder wrote: The Tuscany PMC has voted for Scott Kurz to become a Tuscany committer. Welcome Scott! ...ant Congratulations and welcome, Scott! Your many valuable contributions to Tuscany have been much appreciated. Simon
Re: Red Hat/JBoss involvement with Tuscany
ant elder wrote: On Fri, Jun 6, 2008 at 11:12 AM, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 10:57 AM, Mark Little [EMAIL PROTECTED] wrote: Hi, I just wanted to let people know officially that people from Red Hat/JBoss will be getting involved with Tuscany over the coming months as we look at the best way in which to provide SCA support for our SOA Platform users. We're very excited about helping on Tuscany and complimenting the work we're doing at OASIS. Mark. Mark Little [EMAIL PROTECTED] JBoss, a Division of Red Hat Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland). Hi Mark That's exciting news indeed. Welcome to you all! Regards SimonL Echoing that sentiment, this is really great news. I look forward to working with you all. ...ant I'm very pleased to hear this. It will be great to have you as part of the Tuscany community. This will also help move SCA forward as a widely accepted industry standard. Welcome! Simon
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Simon Laws wrote: On Fri, Jun 6, 2008 at 9:17 AM, Luciano Resende [EMAIL PROTECTED] wrote: How about 1.5-SNAPSHOT ? This would probably give us some room to have couple releases without the necessity to keep updating the trunk pom version. And this would probably make everybody happy :) On Fri, Jun 6, 2008 at 1:14 AM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:05 AM, Luciano Resende [EMAIL PROTECTED] wrote: I guess part of problem here is because a lot of people assume that the maven artifact version represents what is going to be our next release and then, if it's set as 2.0-SNAPSHOT, it means our next release would be 2.0. I agree, this is exactly the issue. But I'm not sure its that much of an unreasonable assumption, it does feel odd to me to have 2.0-SNAPSHOT as the trunk version before there has been any decision to start working on a 2.0 in trunk. ...ant -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ My feeling about this have been galvanized by our previous conversations about doing some development work at some point in the future to improve the APIs/SPIs in backwardly incompatible ways. We previously discussed this under the banner of a 2.0 code base which still sounds sensible. If we do that at some point in the future then we will have a 1.X code based which our existing users will rely on and a 2.X code base which our users may move to over time. I'd like it to be clear when working on a code base, making releases from a code base or just providing snapshots what flavour of Tuscany is involved. Releases take care of themselves but this is why I'd like to see some reference to version 1 in Trunk be maintained. We don't commit to a particular release number until the start discussing each release and cut the branch. Hence that's why I was happy with using 1.X. Regards Simon I also think 1.x is better than 1.5. Simon
Re: RuntimeException: no data binding for null with binding.ws when the service inteface uses generics
Vamsavardhana Reddy wrote: I have the following method in my service interface that uses binding.ws: T Bean1T getTypeUnbound(T[] anArray); I am getting the following exception in SCADomain.newInstance() Please open a JIRA for this, with a test case. Simon org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70) at org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) ... 16 more Caused by: org.apache.tuscany.sca.core.assembly.ActivationException: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237) ... 18 more Caused by: java.lang.RuntimeException: no data binding for null at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366) at org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142) at org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198) at org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.init(Axis2ReferenceBindingProvider.java:68) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47) at org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982) ... 19 more I get a similar exception when I add a method Object getNewObject(Object obj) to my service interface. IIRC, this used to work 10 days ago! ++Vamsi ++Vamsi
Re: Build failure in helloworld-bpel sample
Simon Nash wrote:
I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample. Are other people seeing this?
Any ideas?
Simon
I have committed a fix (or at least a workaround) for this build
break problem. The revision number is r663938.
I debugged the problem and it is caused by the BPELInvoker returning
an XML element for a part:
TestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
messageHello World/message/hello/TestPart
instead of returning an XML element for the wrapper inside the part:
hello
xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl;
messageHello World/message/hello
I modified the BPELInvoker to return the part's child element instead
of the part itself.
To avoid problems like this in future, please can folks run all the
samples and itests before doing a commit, to ensure their code change
doesn't cause problems for others. Thanks.
Simon
Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:
args.: ?xml version=1.0 encoding=UTF-8?
hello
xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdlmessageHello/message/hello
message..:?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello/message/hello/TestPart/message
Invocation status:RESPONSE
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512
sec FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 9.494 sec
ERRO
R!
junit.framework.ComparisonFailure: expected:Hello World but was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)
Results :
Tests in error:
testInvoke(helloworld.BPELHelloWorldTestCase)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
Re: Build failure in helloworld-bpel sample
Simon Laws wrote: On Fri, Jun 6, 2008 at 3:33 PM, ant elder [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 2:49 PM, Simon Nash [EMAIL PROTECTED] wrote: Simon Nash wrote: I did a recent svn update and rebuild and I'm seeing the following test error from the helloworld-bpel sample. Are other people seeing this? Any ideas? Simon I have committed a fix (or at least a workaround) for this build break problem. The revision number is r663938. Just to confirm, this has fixed the problem for me and the sample now builds ok. ...ant It fixed the problem for me but now itest/bpel fails. It didn't before this latest patch so it seems that it is expecting the extra layer of data wrapping for some reason. Simon I backed out this change and I also backed out commit r663685 from yesterday. With these two changes, both the sample and the itest build cleanly. Simon
Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
ant elder wrote: The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant Vamsi, Congratulations on this recognition of your excellent contributions. Welcome on board! Simon
Build failure in helloworld-bpel sample
I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample. Are other people seeing this?
Any ideas?
Simon
Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:
args.: ?xml version=1.0 encoding=UTF-8?
hello xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdlmessageHello/message/hello
message..:?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello/message/hello/TestPart/message
Invocation status:RESPONSE
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello World/message/hello/TestPart/messa
ge
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello World/message/hello/TestPart/messa
ge
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 9.494 sec ERRO
R!
junit.framework.ComparisonFailure: expected:Hello World but was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
java:35)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)
Results :
Tests in error:
testInvoke(helloworld.BPELHelloWorldTestCase)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT
Simon Laws wrote: On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi [EMAIL PROTECTED] wrote: 2008/6/4 ant elder [EMAIL PROTECTED]: Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to remove incubating at some point and as its not clear if the next release would be 2.0 or something else so i wondered if we should also remove the 2.0 giving a trunk version of simply SNAPSHOT? Any comments on that or the timeframe for doing the change? I'd like to do it nowish so we have some time to discover any problems before the next release. ...ant Hi ant, could you try a fresh build from svn? I've some problems with and I 'd go on with my work before we're arriving to 2.0. Ciao, Giorgio. --- Venceremos adelante, o victoria o muerte! I agree that it doesn't feel like the next release will be 2.0 I would prefer that we keep the trunk compatible with our 1.X level APIs for the time being as it feels like there is still a more 1.X releases to do If people are going to start making breaking changes in a branch (we discussed this under the 2.0 thread but it's not happening yet) then it would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so that I know by looking on my disc what I'm working with When (if?) the time comes down the line to break from our 1.X APIs we could then go to SNAPSHOT or 2.0 SNAPSHOT I think it's useful to have some version number. 1.x seems to clearly describe what we are currently developing in trunk, so my preference is for 1.x-SNAPSHOT. Simon
Re: Build failure in helloworld-bpel sample
Luciano Resende wrote:
I guess this might be related to this thread [1].
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg32278.html
Thakns. I saw this and I agree it could be related, but the error
message is different. I was getting the null local part message
from an earlier checkout, but my recent update changed the symptoms
to this new message.
Simon
On Thu, Jun 5, 2008 at 12:30 PM, Simon Nash [EMAIL PROTECTED] wrote:
I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample. Are other people seeing this?
Any ideas?
Simon
Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:
args.: ?xml version=1.0 encoding=UTF-8?
hello
xmlns=http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdlmessageHello/message/hello
message..:?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello/message/hello/TestPart/message
Invocation status:RESPONSE
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Response:
?xml version=1.0 encoding=UTF-8?
messageTestParthello
xmlns=http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdlmessageHello
World/message/hello/TestPart/messa
ge
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 9.494 sec
ERRO
R!
junit.framework.ComparisonFailure: expected:Hello World but was:
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.
java:35)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.
java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)
Results :
Tests in error:
testInvoke(helloworld.BPELHelloWorldTestCase)
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
Re: OSGi-enable 3rd party libraries in Tuscany
See comments inline. Simon Rajini Sivaram wrote: Simon, A few comments inline... On 5/29/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Rajini Sivaram wrote: There is no technical reason why we can't store 3rd party jars separately and merge them at runtime to create virtual bundles, rather than distribute real bundles containing these manifests. I think the issues are: 1. The build will be harder and messier since existing tools are not geared to do this 2. The distribution will be messier from an OSGi perspective Agreed. How about keeping things simple and clean?? 3. OSGi will continue to remain a peripheral feature of Tuscany, never properly integrated since this is not really mainstream. Agreed. 4. Real bundles provide more flexibility to OSGi users in terms of substituting 3rd party jars with newer or patched versions of these, as well as avoiding classloading conflicts resulting from version constraints. Good point too. My 2c: Generating bundles automatically from JARs is useless. If you want to leverage OSGi you need to make authoring / fine tuning your imports/exports a first class part of your development process. To clarify what I have been saying, I agree with this and I was expecting that virtual bundles would be constructed in this way. Even though we can technically generate the exact same manifest entry for virtual bundles as we would for real bundles, IMHO decoupling manifest entries which describe very fine grained information about a bundle like the exact versions of packages it imports from the 3rd party jar and storing it in the Tuscany distribution in a non-standard way is just the wrong thing to do. Like we have already shown with itest/osgi-tuscany, virtual bundles provide a quick and easy way for a large project to get up and running inside an OSGi runtime. But IMO, the virtual bundle approach has WORKAROUND written all over it. I understand this point and I agree that there is value in adopting an approach that provides the best experience for OSGi users, as long as this does not create issues in a non-OSGi environment. I'm starting to feel like a broken record, so I'm going to say it one last time, for the record. I think we should just follow a simple approach and add proper (authored) OSGi entries to our JARs and 3rd party dependency JARs. This doesn't multiply distros, doesn't duplicate JARs, does not complicate the build. It just makes simple sense IMHO, and other projects with experience with OSGi are on that path too. Think of this from a user's perspective. I am downloading Tuscany and it comes with 149 required dependent bundle-ized 3rd party jars, all at specific levels chosen by Tuscany, and with Tuscany-specific modifications. I would like to understand what you mean by Tuscany-specific modifications. IMO interoperating with 3rd party jars bundle-ized outside of Tuscany is not a nice-to-have, it is a must-have. When we bundle-ize a 3rd party jar, all we add are OSGi manifest entries. If we look at the entries that we add these include 1. Bundle symbolic name : 3rd party jars bundle-ized by Tuscany will use the name org.apache.tuscany.sca.xxx. Typically applications will never refer to this name, but in theory they can (eg. to force a bundle to only use imports from a specific bundle). Use of this name will be a deliberate act by an user, and hence we dont introduce any interoperability issues by using a different name. 2. Bundle version and versions of exported packages : Now this is the most crucial information inside a bundle. It is very crucial that we use the same versioning conventions as everyone else. Basically this means that jaxb-impl-2.1.6.jar will use bundle and package version 2.1.6 regardless of whether it was bundle-ized by Tuscany or anyone else. Regardless of whether we use virtual bundles or real bundles, this is an absolute must-have for sharing of classes between applications and Tuscany. 3. Import-Package, Dynamic-ImportPackage and uses statements in Export-Package: The actual packages imported are going to based on what is imported, and hence should be identical for a bundle regardless of who bundle-ized it. But there could be (and probably will be) differences in the constraints used in Import-Package and uses clauses in exports. These constraints are used to achieve sharing and isolation of classes. For Tuscany, we would probably look at scenarios and tune the constraints for the most common scenarios. But there is always going to be some application somewhere which wishes to use a different set of constraints to achieve a different kind of sharing/isolation. This again comes back to the point that we have to interoperate with bundles generated by other users. And we shouldn't make it too tedious for users to replace Tuscany's copies of 3rd party bundles with their own. IMO, real
Re: Incorrect wsdl generated with ?wsdl for a service operation with two dimensional String array parameter
Vamsavardhana Reddy wrote: I have a service operation String[][] getGreetingsArray2(String[][] names). I am using interface.java in my service element in the composite. When the service uses a webservice binding, I get the following wsdl using ?wsdl on the endpoint url. wsdl:definitions wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://jaxb.databindings.itest.sca.tuscany.apache.org/; xmlns:ns0=http://util.java/; xmlns:xs=http://www.w3.org/2001/XMLSchema; xs:element name=getGreetingsArray2 xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=arg0 nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsArray2Response xs:complexType xs:sequence xs:element maxOccurs=unbounded minOccurs=0 name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element ... /xs:schema /wsdl:types /wsdl:definitions Notice that the types correspond to String[] and not String[][]. I have added @WebMethod public String[][] getGreetingsArray2(String[][] names) to MyServiceImpl class in sca\modules\interface-java-jaxws and used jaxws-maven-plugin to generate the wsdl. MyServiceImplService.wsdl has types xsd:schema xsd:import namespace= http://jaxws.java.interfacedef.sca.tuscany.apache.org/; schemaLocation=MyServiceImplService_schema1.xsd/ /xsd:schema xsd:schema xsd:import namespace=http://jaxb.dev.java.net/array; schemaLocation=MyServiceImplService_schema2.xsd/ /xsd:schema /types MyServiceImplService_schema2.xsd has xs:complexType name=stringArray final=#all xs:sequence xs:element name=item type=xs:string minOccurs=0 maxOccurs=unbounded nillable=true/ /xs:sequence /xs:complexType MyServiceImplService_schema1.xsd has xs:complexType name=getGreetingsArray2 xs:sequence xs:element name=arg0 type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=getGreetingsArray2Response xs:sequence xs:element name=return type=ns1:stringArray nillable=true minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType In other words jaxws-maven-plugin seems to generate proper types for String[][]. There seems to be a problem with the code that generates wsdl when ?wsdl is used on the endpoint url. ++Vamsi This support is not yet implemented in the new runtime Java2WSDL mapping code. Please open a JIRA for this and I will look at it. Thanks. Simon
[jira] Commented: (TUSCANY-1713) The WSDL-less feature doesn't honor the XSD type information in the SDO parameter/return type
[ https://issues.apache.org/jira/browse/TUSCANY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600714#action_12600714 ] Simon Nash commented on TUSCANY-1713: - Please ignore the second part of the above comment. My test was using interface.wsdl on the service provider side, which explains the strange results (I thought it was interface.java). I retried this user error test with interface.java on the service provider side. The SOAP request was _ns_:createAccount xmlns:_ns_=http://accountdata.services.account.bigbank/;p0:arg0 xmlns:p0=http://accountdata.services.account.bigbank/; xmlns:p1=http://www.bigbank.com/account; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=p1:CustomerProfileDatafirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/p0:arg0arg1 xmlns=http://accountdata.services.account.bigbank/;false/arg1arg2 xmlns=http://accountdata.services.account.bigbank/;false/arg2/_ns_:createAccount and the response was _ns_:createAccountResponse xmlns:_ns_=http://accountdata.services.account.bigbank/;p0:return xmlns:p0=http://accountdata.services.account.bigbank/; xmlns:p1=http://www.bigbank.com/account; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=p1:CustomerProfileDatafirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/p0:return/_ns_:createAccountResponse Both of these look correct to me. The WSDL-less feature doesn't honor the XSD type information in the SDO parameter/return type -- Key: TUSCANY-1713 URL: https://issues.apache.org/jira/browse/TUSCANY-1713 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-Next In the itest-wsdless test case testClient1b2a3a4a, we use interface.java for the client side and interface.wsdl for the service side. Generated SDO are used for both the client and service side. But the current java2wsdl conversion creates a similar but not equivalent WSDL as the service side. As a result, the outbound call flows the non-comforming XML in the body of the SOAP message. We have to work around the unwrapping logic on the service side to tolerate the incoming data. _ns_:createAccount xmlns:_ns_=http://accountdata.services.account.bigbank;param0 xmlns=http://accountdata.services.account.bigbank; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:p0=commonj.sdo xmlns:p1=http://www.bigbank.com/account; xsi:type=p1:CustomerProfileDatafirstName xmlns=petra/firstNamelastName xmlns=A/lastNameaddress xmlns=home/addressemail xmlns=[EMAIL PROTECTED]/emailloginID xmlns=petra/loginIDpassword xmlns=ant/passwordid xmlns=1/id/param0_ns_:param1false/_ns_:param1_ns_:param2false/_ns_:param2/_ns_:createAccount Please note the wrapper and child elements hav On the response path, with the SDO -- OMElement transformation, it's legal to not generate xsi:type for the child elements. But it will cause problems on the client side as it has to take the response child element by position even if the QName doesn't match and there is no valid xsi:type to help the deserilization of SDO data. p0:createAccountResponse xmlns:p0=http://www.bigbank.com/account;customerProfile xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:_typens_=http://account.bigbank.com/xsd; xsi:type=_typens_:CustomerProfileDatafirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/customerProfile/p0:createAccountResponse Please note the xsi:type is not correct (if we try to derive it from the client side). The key issue here is that we don't honor the XSD types behind the complex parameter/return types even we know the XSD type from databinding introspections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GSoC Project - CORBA Support for Apache Tuscany
One comment inline. Simon Jean-Sebastien Delfino wrote: Raymond Feng wrote: Please see my comments inline. Thanks, Raymond -- From: Wojtek Janiszewski [EMAIL PROTECTED] Sent: Thursday, May 22, 2008 3:21 AM To: tuscany-dev@ws.apache.org Subject: Re: GSoC Project - CORBA Support for Apache Tuscany Hello Tuscany Community! I've spent last days considering project details and made some prototypes which were mainly verifying CORBA API in JDK. I'd like also to begin coding shortly - I'd like to start implementing reference binding implementation for CORBA objects. I've listed some assumptions/doubts: 1. Original time schedule was to start work with Implementation of interface-corba-idl module.. I was told to start with CORBA bindings, I just wanted to make sure that these modules implementation schedule can be swapped. I think the CORA IDL support can be a 2nd step. We can invoke/expose CORBA services using java interfaces. 2. I'll implement service/reference bindings using CORBA Dynamic Invocation Interface (DII) API. Standard JDK CORBA support *should* be enough, if no, there are other CORBA implementations, such as JacORB. Standard JDK APIs should be good enough. There is an Apache CORBA project at: http://cwiki.apache.org/YOKO/. 3. Where should parameters ORBInitialHost and ORBInitialPort be passed to application? They shouldn't be configured global for application, because every binding can use different ORB, so I assume it should be configured per binding. Which attributes for binding.corba shall I use? They should be configured at the binding.corba. 4. In CORBA we can register objects under unique name, or obtain remote objects as references from other CORBA objects. In binding configuration user should point remote objects name, which is registered in name service. Again, I think it should be configured per binding, so which attribute for binding.corba shall I use? That should be derived from the URI of the binding. 5. CORBA objects obtained from binding will be dynamically enhanced by, lets call it, DII Corba Invoker (DCI), and attached to matching Java interface, so Tuscany user can use it. DCI will be responsible for creating request, based on operation name, operation arguments and return type. Every other CORBA object, obtained in any way (from binding, as a result of any other CORBA objects operation) will be also enhanced/attached as above. Yes. The corba reference binding invoker is responsible to bridge the invocations between SCA and CORBA. 6. If CORBA objects operation argument is object reference, then user should provide object which was previously obtained from binding or other CORBA object. User cannot use users-side object as an argument. Yes. Let's don't worry object reference too much at this point. We are in the SOA world instead of distributed object :-). This is OK if we are exposing a SCA service via CORBA. If we are using SCA to invoke existing CORBA services that expect object references to be passed, we will need to come up with an approach for handling them. I'd suggest that we start first with exposing SCA services via CORBA as this seems to be the simplest and most useful form of integration. Simon I hope I described my thoughts clearly, I'll appreciate any comments, especially pointing out things I'm wrong or missing. Thanks, Wojtek I took a look at binding-corba/.../CorbaServiceBindingProvider in trunk. At the moment the ORB setup is in the start method of the provider (and there's no cleanup in the stop method). I'm not quite sure how this is going to work with multiple services sharing the same ORB. I'm thinking that we'll need the following to support multiple services: - A host-corba implementation (similar to host-ejb, host-rmi or host-http) to setup/tear the ORB when the Tuscany runtime starts/stops, independent of the registration of particular services with the ORB. - Logic in that host-corba to set up the ORB in a lazy fashion when the first Corba service is registered. - Only keep the ORB servant creation and naming bind/unbind in the service provider class. Makes sense?
Re: OSGi-enable 3rd party libraries in Tuscany
Rajini Sivaram wrote: Simon, A couple of comments inline... On 5/28/08, Simon Nash [EMAIL PROTECTED] wrote: Sorry for the long delay in responding. I have been deeply buried in implementing the new WSDL-less support, and I am only just surfacing to follow up on other threads. Comments inline. Simon Rajini Sivaram wrote: On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. It would be great to have some co-ordination between these projects so that they can share the same bundle-ized 3rd party jars rather than all creating their own copies and giving the user the problem of figuring out whose version of bundle-ized jaxb can be used with Tuscany, ServiceMix, Spring, etc. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. If the bundle-izing is only intended for use by the native OSGi Tuscany runtime, could we produce a separate distro that contains the native OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current binary distro is very large and it would not be good to have it contain a complete set of unmodified 3rd party jars and another complete set of the same jars in bundle-ized form. I would also not be keen to change the regular binary distro to only contain bundle-ized jars as I think this will be confusing for non-OSGi users of Tuscany, especially if they don't want to use the exact levels of the 3rd-party jars that Tuscany has decided to bundle-ize. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary distro by org.apache.tuscany.sca.jaxb.jar. If this is within the context of a separate OSGi-specific binary distro, I would be OK with including bundle-ized jars in that distro. But I
Re: OSGi-enable 3rd party libraries in Tuscany
Jean-Sebastien Delfino wrote: Rajini Sivaram wrote: There is no technical reason why we can't store 3rd party jars separately and merge them at runtime to create virtual bundles, rather than distribute real bundles containing these manifests. I think the issues are: 1. The build will be harder and messier since existing tools are not geared to do this 2. The distribution will be messier from an OSGi perspective Agreed. How about keeping things simple and clean?? 3. OSGi will continue to remain a peripheral feature of Tuscany, never properly integrated since this is not really mainstream. Agreed. 4. Real bundles provide more flexibility to OSGi users in terms of substituting 3rd party jars with newer or patched versions of these, as well as avoiding classloading conflicts resulting from version constraints. Good point too. My 2c: Generating bundles automatically from JARs is useless. If you want to leverage OSGi you need to make authoring / fine tuning your imports/exports a first class part of your development process. To clarify what I have been saying, I agree with this and I was expecting that virtual bundles would be constructed in this way. I'm starting to feel like a broken record, so I'm going to say it one last time, for the record. I think we should just follow a simple approach and add proper (authored) OSGi entries to our JARs and 3rd party dependency JARs. This doesn't multiply distros, doesn't duplicate JARs, does not complicate the build. It just makes simple sense IMHO, and other projects with experience with OSGi are on that path too. Think of this from a user's perspective. I am downloading Tuscany and it comes with 149 required dependent bundle-ized 3rd party jars, all at specific levels chosen by Tuscany, and with Tuscany-specific modifications. I can't easily apply the Tuscany modfications to other levels of the same software that I may need to use in place of the levels distributed by Tuscany. I also can't easily share the Tuscany versions of these bundles with my other software that has the same dependencies at identical or compatible levels. Does this make my life easy? I don't think it does. Simon
Re: OSGi-enable 3rd party libraries in Tuscany
Graham Charters wrote: FWIW, I agree with Sebastien and Rajini. I don't believe it's a coincidence that both SpringSource and ServiceMix went the route of adding manifests to the thirdparty jars. It keeps things simple and gives a better experience from an OSGi perspective. If we're serious about supporting OSGi we should try to do the right thing by the technology. See my recent response to Sebastien's post on this. There are clearly some different perspectives here about what is simple. It seems to me that this is only simple for people using Tuscany SCA out of the box together with its 149 dependencies at the specific levels distributed by Tuscany. For other combinations, I don't see how sinmplicity for the user is achieved. Please help me understand how this approach would solve the use case that I have in mind. Whilst not necessarily an argument against virtual bundles, I also agree that we should have properly authored dependencies. This view is supported by the discussion Rajini is having in Jira 2343. I know for a fact that SpringSource work very hard to ensure the version ranges on their dependencies are sensible (e.g. match the rules governing version increments for each project). Agreed. Simon I don't believe we can completely do away with virtual bundles in the short term, but we should only use them where necessary (e.g for signed jars and jars which require code extensions to function in OSGi). Regards, Graham. 2008/5/29 Jean-Sebastien Delfino [EMAIL PROTECTED]: Rajini Sivaram wrote: There is no technical reason why we can't store 3rd party jars separately and merge them at runtime to create virtual bundles, rather than distribute real bundles containing these manifests. I think the issues are: 1. The build will be harder and messier since existing tools are not geared to do this 2. The distribution will be messier from an OSGi perspective Agreed. How about keeping things simple and clean?? 3. OSGi will continue to remain a peripheral feature of Tuscany, never properly integrated since this is not really mainstream. Agreed. 4. Real bundles provide more flexibility to OSGi users in terms of substituting 3rd party jars with newer or patched versions of these, as well as avoiding classloading conflicts resulting from version constraints. Good point too. My 2c: Generating bundles automatically from JARs is useless. If you want to leverage OSGi you need to make authoring / fine tuning your imports/exports a first class part of your development process. I'm starting to feel like a broken record, so I'm going to say it one last time, for the record. I think we should just follow a simple approach and add proper (authored) OSGi entries to our JARs and 3rd party dependency JARs. This doesn't multiply distros, doesn't duplicate JARs, does not complicate the build. It just makes simple sense IMHO, and other projects with experience with OSGi are on that path too. -- Jean-Sebastien
Re: OSGi-enable 3rd party libraries in Tuscany
Sorry for the long delay in responding. I have been deeply buried in implementing the new WSDL-less support, and I am only just surfacing to follow up on other threads. Comments inline. Simon Rajini Sivaram wrote: On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle jars downloaded from elsewhere to work with Tuscany running under OSGi. If there is a requirement, we can support virtual bundles with naive manifests just for these cases. I am not sure that is reason enough for virtual bundles to be the only (or default) option. On the other hand, I would think that OSGi users of Tuscany may expect 3rd party bundle jars from other projects like ServiceMix to work with Tuscany running under OSGi. We can easily support that with bundle-ized jars. It would be great to have some co-ordination between these projects so that they can share the same bundle-ized 3rd party jars rather than all creating their own copies and giving the user the problem of figuring out whose version of bundle-ized jaxb can be used with Tuscany, ServiceMix, Spring, etc. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. For users who run Tuscany outside of OSGi, we can (and should) continue to support third party libraries downloaded from anywhere. I dont think bundle-izing 3rd party libraries will require any changes to the way extensions locate their third party dependencies. If the bundle-izing is only intended for use by the native OSGi Tuscany runtime, could we produce a separate distro that contains the native OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current binary distro is very large and it would not be good to have it contain a complete set of unmodified 3rd party jars and another complete set of the same jars in bundle-ized form. I would also not be keen to change the regular binary distro to only contain bundle-ized jars as I think this will be confusing for non-OSGi users of Tuscany, especially if they don't want to use the exact levels of the 3rd-party jars that Tuscany has decided to bundle-ize. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. If you install ServiceMix4 and Tuscany, at the moment you will have org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your disk. Using real bundles, we will replace Tuscany's jaxb.jar with org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the system. Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk space is where Tuscany's jaxb.jar is shared with other products running outside OSGi. As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary distro by org.apache.tuscany.sca.jaxb.jar. If this is within the context of a separate OSGi-specific binary distro, I would be OK with including bundle-ized jars in that distro. But I imagine disk space for jaxb.jar is not the issue. What we want to minimize is the number of jaxb bundles installed
Re: OSGi-enable 3rd party libraries in Tuscany
Rajini Sivaram wrote: Can we decide on a solution for OSGi-enabling 3rd party libs (either in the distribution or using virtual bundles), so that we can start tackling issues like versioning (https://issues.apache.org/jira/browse/TUSCANY-2343)? I just replied to your previous message on this. Sorry for the long delay in responding. I have been deeply buried in the WSDL-less support for the last couple of weeks. Simon On 5/16/08, Simon Nash [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Simon Nash wrote: ... snip I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Can you say why? At the moment we are redistributing these libraries as a convenience for people who want to run Tuscany out of the box. If people want to obtain these libraries in some other way (e.g., from a maven repo, by direct download from the third-party project, or as part of some other download), that's fine too. This change would alter that picture considerably. For people using Tuscany within OSGi, it would be necessary to use the modified libraries distributed by Tuscany. This might or might not be required outside the OSGi environment, depending on how we set up the distro and the way our extensions locate their third-party dependencies. I looked at ServiceMix4 and I see that it is doing something like this with the org.apache.servicemix.bundles.* files. For example, there's one of these that wraps the JAXB implementation in an OSGi bundle. If we do the same in Tuscany, anyone wanting to use Tuscany with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB implementation classes. Now add SpringSource and a few other projects into the mix and how many copies of the same JAXB code will the user need? Any number greater than one is the wrong answer. Another more minor point is that for Graham's minimal OSGi test that's going to be part of the main build, it will be necessary to build these wrapper bundles, increasing the disk space used by the build because of the need to duplicate the contents of all the third-party jars, which are already in my local maven repo. Simon May you could look at what other projects that have spent time working on OSGi are doing. Two examples: - servicemix 4 - springsource app platform There's probably more good examples out there.
[jira] Commented: (TUSCANY-2346) weaks in databinding-jaxb plug-in
[ https://issues.apache.org/jira/browse/TUSCANY-2346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600433#action_12600433 ] Simon Nash commented on TUSCANY-2346: - recently added code in JAXBTypeHelper that does something similar to this. It's used to create a JAXB context for use in Java to WSDL runtime schema generation. Ideally this code would be combined so that there's only one copy. I'd like to experiment with doing this. Can you attach a test case that demonstrates the current failure, so that I can verify that the combined code works OK in your scenario? weaks in databinding-jaxb plug-in - Key: TUSCANY-2346 URL: https://issues.apache.org/jira/browse/TUSCANY-2346 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime, Java SCA OSGi Integration Affects Versions: Java-SCA-1.2 Environment: databinding-jaxb, OSGi (but i think it should affects non-OSGi version too) Reporter: Ivan Churkin Attachments: JAXBDataBinding.java There is a JAXB feature to create JAXB context by specifying the whole array of all mapping classes. Tuscany databinding-jaxb plug-in unable to work with. As a result, when application uses SCA for transmitting objects created by specifying complex JAXB context it crashes. This plug-in (databinding-jaxb) creates context for marshalling on very simple way. It gets class of root object and asks for JAXB to create context by providing it. So it supports only simple/default JAXB contexts. Its suggested more sophisticated procedure. 1. try to use default/simple context 2. if it does not work, to collect all JAXB related classes used in instance object and its properties/subobjects by reflection and to create context by array. -- 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-2330) Calculator sample running in OSGi
Graham Charters wrote: I've been wondering whether we should make this an itest rather than a sample. We could keep it as a sample, but it relies on maven-dependency-plugin to work out the dependencies required to run the sample. Is a sample that only works with maven acceptable (I believe the other samples do not) or should I change this to be an itest? We do try hard to make the samples work with ant as well as maven. There have been cases where samples started out with maven support only and the ant support was added later. From your description, it doesn't sound lke this is likely to happen. I believe the main purpose of this sample is to act as a test for the Tuscany build rather than a sample for a user to copy and adapt. If this is correct, I think it should be changed to an itest. Simon Regards, Graham. 2008/5/23 Graham Charters (JIRA) tuscany-dev@ws.apache.org: [ https://issues.apache.org/jira/browse/TUSCANY-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12599389#action_12599389 ] Graham Charters commented on TUSCANY-2330: -- Hi Rajini, sorry for taking so long to respond. Please go ahead and check the code in with your update. Changing it to use Felix is fine by me. I tested it with both and there was little discernible difference in performance. Thanks, Graham. Calculator sample running in OSGi - Key: TUSCANY-2330 URL: https://issues.apache.org/jira/browse/TUSCANY-2330 Project: Tuscany Issue Type: Wish Components: Java SCA Samples Affects Versions: Java-SCA-Next Environment: All Reporter: Graham Charters Fix For: Java-SCA-Next Attachments: calculator-osgi-sample.patch Original Estimate: 2h Remaining Estimate: 2h It would help with preserving OSGi support if an OSGi sample were run as a matter of course, rather than only by a small number of developers. This wish is to add the smallest sample possible based on existing Tuscany module dependencies. -- 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-2343) OSGi bundle design leads to class loading issues
One comment inline. Simon Rajini Sivaram (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600437#action_12600437 ] Rajini Sivaram commented on TUSCANY-2343: - Georg, Thank you for the details on your scenario. It has been very helpful. For now, I think we have enough information to make progress. When we start introducing more versioning information in the jars, it will be very useful to run these against your scenario first. With tuscany-sca-osgi-installer.jar, 3rd party jars are installed with the actual jar versions. In the example you used of servlet api, the bundle installed will have: Bundle-SymbolicName: org.apache.tuscany.sca.3rdparty.servlet-api-2.5 Bundle-Version: 2.5 Import statements in Tuscany however do not specify a version range. So Tuscany can use a different version of javax.servlet installed by an application and share classes from javax.servlet. As long as the version range used by the application contains the version 2.5, Tuscany and the application will use the same definitions of javax/servlet (either from this bundle or the one installed by the application). If the application uses a version range (eg. version=2.6) which does not match Tuscany's, the application and Tuscany could end up using javax.servlet from different bundles - in this case the application will always use 2.6, but Tuscany may use 2.6 or 2.5 as chosen by the OSGi framework since it does not specify a version range in its import). The issues that we need to address for versioning import statements are: 1) Version ranges specified in import statements should be broad enough to enable sharing. eg. If Tuscany is able to work with versions between 2.4.8-2.6.2 of javax.servlet, the version range should include the entire range of those versions, enabling applications to choose the version. 2) Version ranges should be narrow enough to enable isolation when we want two versions to coexist. eg. If one Tuscany extensionA wants to use version 3.1 of foo.jar and another extensionB (or the application) wants to use 3.3 of the same jar, where classes of the jar are not required to be shared, we should be able to specify narrow ranges of versions in the import of org.foo, so that the extensions use different versions. It seems like this is coupling two things that are not the same: 1. whether or not the extensions need to share the same loaded classes 2. which version of the dependency the two extensions can tolerate (for their own compatibility needs) Simon 3) Versions introduced by tools like the maven-bundle-plugin cannot really provide us 1) and 2). So we will need to carefully analyse the usage of all 3rd party jars to introduce proper version ranges in imports. Hence scenarios like yours can be very useful to ensure that we get it right. Back to tuscany-sca-osgi-installer.jar - this is not built as part of the main build in Tuscany. So you need to run maven from itest/osgi-tuscany. You should then be able to install and start this bundle. You should see around 200 bundles installed when bundle.start() returns. You will need to modify the build script only if you want to disable the installation of a 3rdparty jar. 1) If the JAXB bundle you are using is the same version (eg. 2.6.1) as the one installed by Tuscany, you wont need to change anything. A single bundle will be chosen as exported by the framework. 2) If the JAXB bundle you are using is of a different version (eg. 2.6.2), and the application's import statements use a range which includes both 2.6.1 and 2.6.2, you dont need to change anything. The same export will be used for both application and Tuscany. 3) If the application uses a version range that is different (application requires 2.6.2), you should change the Tuscany installer build script to exclude version 2.6.1, to ensure that Tuscany does not pick that one. Hope this helps. OSGi bundle design leads to class loading issues Key: TUSCANY-2343 URL: https://issues.apache.org/jira/browse/TUSCANY-2343 Project: Tuscany Issue Type: Bug Reporter: Georg Schmidt Currently the design of the OSGi bundles leads to class loading exceptions. There seem to be several reasons for this behavior: * reexporting of all libraries without version numbers * imports without version numbers Please use distinct bundles for 3rd party libraries. That would lead to easier reusage of your bundles in a larger OSGi project. The current status leads to undefined system behaviour due to the OSGi class loading concept. Please tell if you see a way, how we could support you by achieving this goal. (If a solution is interesting for you) We are willing to contribute because its a critical project issue for us.
Build failure in StoreSupplierTestCase
I'm getting the following failure when building the tutorial. It seems to happen every time I do a full top-level build from a new checkout. Any ideas for solving it or debugging it further? Which service is returning the HTTP 500 response? Simon Running test.StoreSupplierTestCase 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ui/home/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ui/workspace/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ui/files/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ui/composite/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ui/cloud/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/workspace/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/contribution/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/feed/files/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/files/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/composite/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/composite-source/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/deployable/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/composite-generated/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/composite-resolved/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/cloud/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/cloud-source/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/composite-config/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/node-config/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/quickstart/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/processes/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/node/processes/* 28-May-2008 11:39:00 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:9990/ping/* 28-May-2008 11:39:00 org.apache.tuscany.sca.node.impl.NodeImpl init INFO: Creating node: http://localhost:9990/node-config/StoreSupplierNode 28-May-2008 11:39:02 org.apache.tuscany.sca.node.impl.NodeImpl configureNode INFO: Loading contribution: file:/F:/tuscany71/sca/tutorial/store-test/../assets /target/tutorial-assets.jar 28-May-2008 11:39:02 org.apache.tuscany.sca.node.impl.NodeImpl configureNode INFO: Loading contribution: file:/F:/tuscany71/sca/tutorial/store-test/../store- supplier/target/tutorial-store-supplier.jar 28-May-2008 11:39:02 org.apache.tuscany.sca.node.impl.NodeImpl configureNode INFO: Loading composite: http://localhost:9990/composite-resolved/composite:stor e-supplier;http://store;store-supplier 28-May-2008 11:39:05 org.apache.tuscany.sca.node.impl.NodeImpl start INFO: Starting node: http://localhost:9990/node-config/StoreSupplierNode 28-May-2008 11:39:06 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:8103/ui/* 28-May-2008 11:39:06 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:8103/StoreSupplierCatalog/* 28-May-2008 11:39:06 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping INFO: Added Servlet mapping: http://SouthRim:8103/StoreSupplierCatalog 28-May-2008 11:39:06 org.apache.tuscany.sca.http.jetty.JettyServer addServletMap ping
[jira] Commented: (TUSCANY-1713) The WSDL-less feature doesn't honor the XSD type information in the SDO parameter/return type
[ https://issues.apache.org/jira/browse/TUSCANY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600586#action_12600586 ] Simon Nash commented on TUSCANY-1713: - I tried this with the new runtime Java2WSDL generator. As part of the check-in to enable the new generator, I had fixed a problem in the test case where the namespace of the AccountDataService service endpoint interface (http://accountdata.services.account.bigbank;) did not match the namespace in the WSDL and the generated SDO wrapper classes (http://www.bigbank.com/account;). I fixed this by adding the annotation @WebService(targetNamespace=http://www.bigbank.com/account;) to the AccountDataService interface so that the namespaces are all consistent. With this namespace fix in the test case and the new Java2WSDL runtime generator (case 1), the SOAP request message is p0:createAccount xmlns:p0=http://www.bigbank.com/account;customerProfilefirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/customerProfile/p0:createAccount and the response message is p0:createAccountResponse xmlns:p0=http://www.bigbank.com/account;customerProfilefirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/customerProfile/p0:createAccountResponse which all looks clean and correct, and is marshalled and unmarshalled correctly by the runtime. If I remove the namespace fix from the test case (case 2), thus creating a user error situation with inconsistent namespaces, the SOAP request message changes to _ns_:createAccount xmlns:_ns_=http://accountdata.services.account.bigbank/;p0:arg0 xmlns:p0=http://accountdata.services.account.bigbank/; xmlns:p1=http://www.bigbank.com/account; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:type=p1:CustomerProfileDatafirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/p0:arg0arg1 xmlns=http://accountdata.services.account.bigbank/;false/arg1arg2 xmlns=http://accountdata.services.account.bigbank/;false/arg2/_ns_:createAccount and the response message remains as previously, i.e., p0:createAccountResponse xmlns:p0=http://www.bigbank.com/account;customerProfilefirstNamepetra/firstNamelastNameA/lastNameaddresshome/addressemail[EMAIL PROTECTED]/emailloginIDpetra/loginIDpasswordant/passwordid1/id/customerProfile/p0:createAccountResponse There is a problem/inconsistency here. The request message is using the namespace http://accountdata.services.account.bigbank/; for the request wrapper, so it is taking the namespace from the SEI and the generated WSDL. However, the response wrapper is using the namespace http://www.bigbank.com/account;, so it is taking the namespace from the SDO wrapper and not from the SEI or generated WSDL. The service is able to unmarshal the request, even though the SOAP namespace for the request wrapper doesn't match the SDO request wrapper class on the service side. However, the client isn't able to unmarshal the response correctly (it creates a generic dynamic SDO for customerProfile). It appears that a) request marshalling and unmarshalling is using the WSDL namespace for wrappers and ignoring SDO wrapper classes if they exist b) request marshalling and unmarshalling is using xsi:type to correctly identify the namespace and local name of the wrapped data type c) response marshalling is creating wrappers using SDO wrapper classes if they exist, even if these have a namespace that doesn't match the WSDL d) response marshalling is not using xsi:type to identify the wrapped data type, causing unmarshalling to fail The WSDL-less feature doesn't honor the XSD type information in the SDO parameter/return type -- Key: TUSCANY-1713 URL: https://issues.apache.org/jira/browse/TUSCANY-1713 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-Next In the itest-wsdless test case testClient1b2a3a4a, we use interface.java for the client side and interface.wsdl for the service side. Generated SDO are used for both the client and service side. But the current java2wsdl conversion creates a similar but not equivalent WSDL as the service side. As a result, the outbound call flows the non-comforming XML in the body of the SOAP message. We have to work around the unwrapping logic on the service side to tolerate the incoming data. _ns_:createAccount xmlns:_ns_=http://accountdata.services.account.bigbank;param0 xmlns=http
Re: SCA 1.2.1 release
Dave Sowerby wrote: Hi Simon, With regards to the 1.2.1 release you are correct that we have a patched version of tuscany-sca-all which would work, but this however leaves us in an awkward configuration position. We're currently preparing a software release based around Tuscany which is completely open to customers of our use of Tuscany, such that we document fully how to construct services independent of our software. As such, we do not ship any Tuscany artifacts and instead encourage our customers to utilise the published maven repository. Whilst requiring a patch version of one of the jars is possible; I don't feel that this is a good representation of Tuscany - either documenting a variant version or expecting a non-standard version of 1.2-incubating. These potential solutions are more likely to cause issues for customers that would undermine the image of Tuscany that we try to project. Is anyone adamantly opposed to this release? Do you feel Tuscany 1.2.1 is still an option? I'd hope that given the potential to damage our customer's perception of Tuscany would be enough to justify this minor release. Thanks for the clarifaction and explanation. It seems to me that because we distribute Tuscany via Maven repos, which can't be patched, this kind of situation will arise whenever a serious bug is found. We can use patches to isolate a problem and confirm the fix, but we generally won't be able to use them as an alternative to a release. In a situation like this, unless a new release is imminent, the best solution seems to be to produce a quick bug fix release without incurring the overhead of a full release and testing cycle. Ant has suggested that we could do this by applying a small set of carefully controlled changes to the previous 1.2 release tag. I think we need to be very strict about what changes go in, to avoid another experience like 1.0.1. Specifically, I would suggest only including the fix for TUSCANY-2304. What do others think of this? Simon Cheers, Dave. On Tue, May 20, 2008 at 12:00 PM, Simon Nash [EMAIL PROTECTED] wrote: Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require changes in other parts of the code. I'm preparing a (large) checkin to update the new generator code so that it handles most of the cases (perhaps 95%). This should be enough to get the full build to run with the new code. However, I wouldn't consider the new code to be ready to release at that point. It will need quite a bit of further testing and a few more updates to take care of the remaining 5% of cases. Some of these cases will require discussion on the list to agree how they should be handled. Also, the new code will need testing by people other than myself with their scenarios to make sure that it does not break cases that worked with the previous Java2WSDL generator. For all these reasons, I think it will take about another 3 weeks to get the new generator code to the state that I would be happy to see it enabled in a release. Regarding TUSCANY-2304, from other emails I see that Ant has sent you a patched version of tuscany-sca-all-1.2-incubating.jar that contains the fix for your problem. Can you explain why you need a new release in addition to this patch? Simon
Re: Tuscany Java2WSDL and WSDL2Java tools
ant elder wrote: On Wed, May 21, 2008 at 7:47 PM, Simon Nash [EMAIL PROTECTED] wrote: Scott Kurz wrote: That 'generate-sdo' only generates the Java types from the schema types, right? It's the WSDL2Java which maps portType operations t**o Java methods and (last I checked) our W2J is the only tool which knows how to do this with an SDO databinding. Are the Java Service Endpoint Interfaces generated from WSDL portTypes when using an SDO databinding different from what JAX-WS would produce when using a JAXB databinding? Or are the differences confined to the Java code that's generated for the XSD types referenced in the WSDL? If possible, it would be good if we could use standard tools to generate the Java SEIs, and SDO-specific tools for the XSD to Java static SDO translation. One extra thing an SCA specific tool does need to do is to add the org.osoa.sca.Remotable annotation to the SEI. Maybe that could be done with a simple post processor? ...ant According to the SCA Java spec, @WebService implies @Remotable (see chapter 9 of JavaCAA), so this may not be an issue. Simon
Re: Graduation
Matthieu Riou wrote: Special order 7B, Establish the Apache Tuscany Project, was approved by Unanimous Vote of the directors present. Congratulations guys! Matthieu Thanks for this excellent news. It has been great to be part of the Tuscany community in our journey towards full Apache-hood, and I have appreciated all the help from our mentors and the IPMC along the way. Simon
Re: Build failure in itest/contribution-classloader (monitor problem)
Rajini Sivaram wrote: Simon, Do we actually expect to always find a monitor implementation on the classpath? If so, I think we should throw an exception earlier on if no monitor implementation was found, rather than a NullPointerException masking the original exception when something does go wrong. But shouldn't we actually tolerate the absence of a monitor implementation, and use monitors with checks for null? monitor-logging is not a dependency on host-embedded at the moment. itest/contribution-classloader is the only test that fails because it is the only one which uses the exception code path. If we are going to write unguarded monitor calls then we need to be 100% certain that a monitor will always be present. It should be possible to ensure this by having a default do nothing monitor that is created at startup and can be overridden with a user-written implementation if one is found. I think that enforcing the 100% guarantee is better than writing null tests before every monitor call. Simon On 5/22/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 9:33 PM, Simon Nash [EMAIL PROTECTED] wrote: I just did a clean checkout and full build. It failed in itest/contribution-classloader with the following stack trace. The problem is caused by a null value in the monitor variable on line 124 of JavaInterfaceProcessor. This does not seem to happen for other tests. Any ideas? Simon Running org.apache.tuscany.sca.test.contribution.ContributionTestCase Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Customer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.retailer.JavaRetailerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.warehouse.JavaWarehouseComponentImpl using: java.net.URLClas [EMAIL PROTECTED] Created supplychain.shipper.JavaShipperComponentImpl using: java.net.URLClassLoa [EMAIL PROTECTED] Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled, shipped Created supplychain.illegal.JavaCustomerComponentImpl using: SCA contribution cl assloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributi on-test/target/contributions/IllegalCustomer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created a retailer from Customer supplychain.retailer.JavaRetailerComponentImpl@ 3fac1e22 Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/CompleteSupplyChain.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/CompleteSupplyChain.jar Work thread Thread[Thread-6,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CustomerImpl.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl
Re: Tuscany Java2WSDL and WSDL2Java tools
Scott Kurz wrote: That 'generate-sdo' only generates the Java types from the schema types, right? It's the WSDL2Java which maps portType operations t**o Java methods and (last I checked) our W2J is the only tool which knows how to do this with an SDO databinding. Are the Java Service Endpoint Interfaces generated from WSDL portTypes when using an SDO databinding different from what JAX-WS would produce when using a JAXB databinding? Or are the differences confined to the Java code that's generated for the XSD types referenced in the WSDL? If possible, it would be good if we could use standard tools to generate the Java SEIs, and SDO-specific tools for the XSD to Java static SDO translation. I'm not sure how useful the SDO-based J2W is, however. There are a lot of ways to generate a WSDL and as long as the work Simon Nash is doing to do a J2W at runtime can handle SDOs it would seem the tool-time code could be abandoned. I'd like to get the runtime part working properly before I start looking at what is needed to make the same functionality available from the tools. In principle this seems like the right approach, but it might be quite a lot of work depending on environmental differences and how much flexibility we want to enable through different codegen options. For example, the runtime code introspects the contribution to locate the XSDs that correspond to SDO static types. At tool time, there would need to be command-line options to say where to find the XSDs. Another difference is that the runtime code code works by introspecting Java classes loaded into the current VM. It is considered bad practice for tools (e.g., rmic) to work in this way, because of potential interference between the classes being processed and the tool's own runtime. As an example, think of what would happen if a loaded class ran a constructor that went into a loop, or called System.exit(). Instead, these tools read class files and generate a pure data in-memory representation of the class information that is then processed. I suspect there will be a number of such differences. None will be insoluble, but all will require effort to design and implement. Simon On Wed, May 21, 2008 at 10:05 AM, ant elder [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 2:53 PM, Mike Edwards [EMAIL PROTECTED] wrote: ant elder wrote: Do we really need these as they are today? Currently they contain copies of various Axis2 classes updated for Tuscany so its not a completely trivial upgrade to move to Axis2 1.4 and while looking at that I wondered what we really want them for. The Java2WSDL tool doesn't look like its actually used anywhere by any of the Tuscany samples or demos or anything. We have all the new runtime Java2WSDL code so ideally we'd move to that instead of using all the patched Java2WSDL classes. WSDL2Java is only used by one BPEL sample, the other samples needing that type of thing use the SDO tools directly to gen Java classes from XML schema. We've now changed all the runtime to use jaxb and jaxws so should we look at using the tools for those instead of the Axis2 WSDL2Java tool? Any one have any thoughts? ...ant Ant, Whoa there :-) One of the main points of having Tuscany tools in this area is to assist developers who are having to use WSDL and who want to use SDOs in their Java code. If we get rid of the Tuscany tools, how are developers supposed to handle this? Handle what exactly is what I'm asking. What are the use cases we want to support? Looking at the state of the code I'm not sure these tools actually are working properly today and its not that clear (to me) what it is we want them to do anyway. SDO has its own tools for dealing with WSDL which we use, eg, look at the bottom of the pom.xml in the wsdl itest [1]. ...ant [1] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/wsdl/pom.xml
Build failure in itest/contribution-classloader (monitor problem)
I just did a clean checkout and full build. It failed in itest/contribution-classloader with the following stack trace. The problem is caused by a null value in the monitor variable on line 124 of JavaInterfaceProcessor. This does not seem to happen for other tests. Any ideas? Simon Running org.apache.tuscany.sca.test.contribution.ContributionTestCase Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Customer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-2,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.retailer.JavaRetailerComponentImpl using: java.net.URLClassL [EMAIL PROTECTED] Created supplychain.warehouse.JavaWarehouseComponentImpl using: java.net.URLClas [EMAIL PROTECTED] Created supplychain.shipper.JavaShipperComponentImpl using: java.net.URLClassLoa [EMAIL PROTECTED] Work thread Thread[Thread-4,5,main] - Order, submitted, fulfilled, shipped Created supplychain.illegal.JavaCustomerComponentImpl using: SCA contribution cl assloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributi on-test/target/contributions/IllegalCustomer.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created a retailer from Customer supplychain.retailer.JavaRetailerComponentImpl@ 3fac1e22 Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CompleteSupplyChain.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/CompleteSupplyChain.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/CompleteSupplyChain.jar Work thread Thread[Thread-6,5,main] - Order, submitted, fulfilled, shipped Created supplychain.customer.JavaCustomerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/CustomerImpl.jar Created supplychain.retailer.JavaRetailerComponentImpl using: SCA contribution c lassloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contribut ion-test/target/contributions/Retailer.jar Created supplychain.warehouse.JavaWarehouseComponentImpl using: SCA contribution classloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contrib ution-test/target/contributions/Warehouse.jar Created supplychain.shipper.JavaShipperComponentImpl using: SCA contribution cla ssloader for : file:/F:/tuscany70/sca/itest/contribution-classloader/contributio n-test/target/contributions/Shipper.jar Work thread Thread[Thread-8,5,main] - Order, submitted, fulfilled, shipped Tests run: 9, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.581 sec FA ILURE! testIllegalStaticClassLoading1(org.apache.tuscany.sca.test.contribution.Contribu tionTestCase) Time elapsed: 0.219 sec ERROR! java.lang.NullPointerException at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolveJavaInterface(JavaInterfaceProcessor.java:124) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolve(JavaInterfaceProcessor.java:148) at org.apache.tuscany.sca.interfacedef.java.xml.JavaInterfaceProcessor.r esolve(JavaInterfaceProcessor.java:50) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProc essorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcess orExtensionPoint.java:320) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactP
Re: SCA 1.2.1 release
Nishant Joshi wrote: Hi All, I have raised TUSCANY-2304 which was actually blocking me to go further with SCA client. So It was given high priority to resolved and fortunately Ant has resolved it very fast, i appreciate his effortt, thanks alot Ant for this :). Another one was TUSCANY-2251 that was handled by Simon Nash and he has also done good progress on it (found from this list ). This problem came in eclipse generated web service client (please refer it for more detail) so this is also in high priority to get in next release. So i request to add TUSCANY-2304 in 1.2.1 and if possible TUSCANY-2251 also. One more thing, its very critical for us to get the next release 1.2.1 ASAP (with 2304 and if possbile 2251 also :) ). So I hope you can understand the effect of the TUSCANY-2304 for any tuscany SCA client user . Hi Nishant, The work to fix TUSCANY-2251 has turned out bigger than expected. It's one of those cases where the first 80%-90% can be done quite quickly but supporting the final 10%-20% of cases turns up many issues, some of which require changes in other parts of the code. I'm preparing a (large) checkin to update the new generator code so that it handles most of the cases (perhaps 95%). This should be enough to get the full build to run with the new code. However, I wouldn't consider the new code to be ready to release at that point. It will need quite a bit of further testing and a few more updates to take care of the remaining 5% of cases. Some of these cases will require discussion on the list to agree how they should be handled. Also, the new code will need testing by people other than myself with their scenarios to make sure that it does not break cases that worked with the previous Java2WSDL generator. For all these reasons, I think it will take about another 3 weeks to get the new generator code to the state that I would be happy to see it enabled in a release. Regarding TUSCANY-2304, from other emails I see that Ant has sent you a patched version of tuscany-sca-all-1.2-incubating.jar that contains the fix for your problem. Can you explain why you need a new release in addition to this patch? Simon
[jira] Commented: (TUSCANY-2324) InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding
[ https://issues.apache.org/jira/browse/TUSCANY-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597382#action_12597382 ] Simon Nash commented on TUSCANY-2324: - Disclaimer: I haven't yet looked at the code. I think the interface contract on the outer reference should be used for the WS binding. According to the spec rules, it must provide a compatible subset of operations on the interface for the inner reference. If the generated WSDL doesn't match the actual WSDL, this suggests that the interfaces are not compatible, which would violate the spec and should be diagnosed as an error. There's a JIRA (TUSCANY-2109) already open for what looks like a very similar problem caused by namespace conflicts between the two interfaces. It may be possible to close this JIRA as a duplicate of TUSCANY-2109. InterfaceContract is not pushed down to an inner, promoted component reference only with Axis2 binding --- Key: TUSCANY-2324 URL: https://issues.apache.org/jira/browse/TUSCANY-2324 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Scott Kurz Priority: Minor If we take the following example where an inner component reference is overridden in two ways by the outer component using the inner Composite as impl: 1) a binding.ws is added 2) a WSDL intf (compatible with the inner Java intf) is declared composite ... name=OuterComposite component name=OuterComponent implementation.composite name=blah:InnerComposite/ reference name=outerRef target=MyTarget interface.wsdl interface=http://blah#wsdl.interface(HelloWorld) / binding.ws/ /reference /component /composite composite name=InnerComposite component name=InnerComponent implementation.java .../ reference name=helloWorldService interface.java interface=test.sca.w2j.ws.statc.exc.helloworld.HelloWorld/ /reference /component reference name=outerRef promote=InnerComponent/helloWorldService/ /composite we have a problem. The CompositeActivatorImpl is going to start an Axis2ReferenceBindingProvider for the inner Composite ref. The WS binding is propagated down or inwards, you could say.But this WS binding has a null IC, so we're going to look at the component ref IC, but this will be the inner component ref IC, which is a Java IC. This kicks off a Java2WSDL and the new WSDL IC becomes the Axis2 ref binding IC. So the generated WSDL may not match the actual WSDL, which is a problem. Of course, if we had included a wsdlElement (e.g. wsdl.port ) on the outer component's binding.ws/ we would not have had a problem; it would have been propagated inwards along with the binding itself. -- 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: 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
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
Re: [jira] Commented: (TUSCANY-2109) Conflicts between component reference interface and promoted composite reference interface are not detected
Scott Kurz wrote: 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? If they do this when not necessary, they are accepting the need to also upgrade all the clients that talk to these services. 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.). OK, I think I understand now. You are talking about compatibilty checking between a reference's interface.java and the same reference's explicitly specified binding.ws WSDL binding. In this case, I think the namespace information should come from the reference's binding.ws WSDL binding and not from the interface.java, and should not be a problem if the interface.java has a different namespace. Applying the same reasoning to the promoted case, I think I was wrong when I said earlier that it's a problem if the namespace for the inner interface doesn't match the namespace for the outer interface. According to the rule proposed above, interface namespaces should always be ignored, so the interfaces would match. The binding.ws WSDL binding namespace would be derived from the outer interface, and any namespace information on the inner interface would not be used. 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. Yes, I agree with this now. See above. 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? In this case, no Java2WSDL should be done, as you say. Simon Scott
Re: Small OSGi sample for the main build?
Simon Laws wrote: On Thu, May 15, 2008 at 2:59 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: 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 basically a cut-down version of what Rajini has done in itest/osgi-tuscany and only runs the most basic Calculator sample. I still have some work to do to exclude all the things which aren't required and also perhaps move it to use the latest 1 manifest per 3rd party jar approach. Currently the sample takes ~3 mins to build and run and uses 56MB. The main space usage is 17.5MB for the third-party dependencies and 35MB for the Felix bundle cache (61 bundles in total). The full Tuscany (itest/osgi-tuscany) using the same third-party library approach is 151 bundles and 133MB total. I'd like to understand whether people feel this would be useful Yes it's useful IMO and whether it is approaching the kind of overhead that would be acceptable for it to be included in the main build? +1 from me to include it in the main build (assuming you meant main build = top-down build from java/sca with profile default) I'm +1 too to integrate the bigger itest/osgi-tuscany under another osgi profile. Thoughts? Regards, Graham. -- Jean-Sebastien Nice work Graham +1 from me to include this cut down sample in the main build. It's a great benchmark for how small we can get the minimum runtime and, for the subset that it represents, demonstrates that our OSGi support is working. I'm sure that you are right that we can cut it down further but that shouldn't prevent us getting it into the build. Simon Yes, I think it's useful. I am somewhat concerned about adding an extra 3 minutes to all my builds. How much do you think it will be possible to reduce this by eliminating things that aren't needed by the basic calculator sample? Could you post what you currently have (without enabling it in the main build yet) so that others can take a look at what it is doing, and what dependencies it pulls in? Simon
Re: SCA 1.2.1 release
ant elder 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 The 2251 fix is close but it won't be ready by tomorrow. It's also not very small. I am making steady progress with this every day, and I have been in the one last bug mode for the last few days. Experience tells me that I'll need a good portion of a wet weekend to get this completed. Saturday has rain in the forecast, so it's possible that I'll have something by Monday :-) Simon
Re: Conversational semantics using xml in SCDLs
Simon Laws wrote: On Thu, May 15, 2008 at 2:24 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi Mike, Thanks for the heads-up. Let us see whether the Assembly TC does the same this time too with the proposal to add a top level interface element. ++Vamsi On Thu, May 15, 2008 at 6:07 PM, Mike Edwards [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: snip For 1, 2, 3 and 5, I think it is a good idea to introduce a new interface definition as a top level element in SCDLs. This new interface definition could use any existing interface definition and add additional semantics. For example, something like interface.xxx name=myConversationalInterface interface=myNonConversationalInterface conversational=true operation name=method1 endsConversation=true/ /interface.xxx can yield a conversational interface myConversationalInterface from a non-conversational interface myNonConversationalInterface. This should work as if there were annotations on the original interface definition. With this new interface definition in place, we may not need conversational intent on service or reference and myConversationalInterface can be used whereever myNonConversationalInterface were to be used along with a conversational intent on the service or reference. Please comment if any of the above does not make sense or suggest any alternative ways to deal with these issues. ++Vamsi snip Vamsi, Simon has given a good comprehensive response to your main points - I would like to focus on this final suggestion. You will meet some substantial opposition in the spec group to the idea of creating a new SCDL-based interface definition language. The group has rejected such suggestions more than once in the past. The argument is that there are already very good interface definition languages available - and that where SCA extensions are necessary, they can be added as extension annotations to those existing languages. Providing yet another parallel interface definition language simply adds to the complexity of SCA without a corresponding benefit. I believe that all the issues you raise are already covered by the specs - or there are open issues awaiting resolution. You are welcome to make suggestions to the SCA specification group, of course, but I thought it useful to give you a heads-up on the likely reaction. Yours, Mike. I think we need to be clear about our expectations of adding a conversational intent to the SCDL. From reading the notes here let me try and articulate when it could be useful. A 3rd party interface is provided which knows nothing of SCA and doesn't specific @Conversational A user builds a component implementation that inherits direction from this 3rd party interface This component implementation is conversational in that it either - stores instance based conversational data - uses the SCA conversation ID (via the @ConversationId annotation for example) to locate conversation data The user writes a SCDL component to exploit this implementation and has to add the intent conversational to tell SCA to treat this as a conversational service An SCA client service can now hold a conversation with this service BUT it must end the conversation using the conversation.end() call rather than relying on an annotated method at the service. Hence the only thing that appears in the SCDL is the conversational intent. This seems to put some constraints on the client. I.e. it must know that it has to do special conversation processing. It is holding a conversation over a reference whose interface is not annotated as being conversational. The writer has to be be aware of this. Does this help? Simon Yes, it does. It helps me to see how unlikely it is that this will ever happen in real life. I think the first point is the most telling. If the third party interface wasn't designed with SCA-style conversation semantics in mind, the chances of successfully applying and exploiting these semantics after the fact are very small. Simon
Re: Conversational semantics using xml in SCDLs
Vamsavardhana Reddy wrote: On Thu, May 15, 2008 at 2:32 PM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: Right now all the conversation related things we have in Tuscany seem to use annotations in Java code. The assembly schema does not seem to be good enough to specify the equivalents through SCDLs. Here are some of the issues, taking the java annotations as a reference point, that are coming in the way of conversational semantics using SCDLs. I would like to hear from others before I take up these with OASIS SCA Assembly TC. So, please provide your input and also suggest any aspects that I may be missing to see. 1. Designating an interface as conversational: JAVA: The @Conversational annotation used to designate a Java interface as conversational. Wherever the interface is used, it is seen as conversational interface consistently. ASSEMBLY: I do not see a way to designate an interface (just the interface definition) as conversational through SCDLs. This was resolved by http://www.osoa.org/jira/browse/ASSEMBLY-47. Either the interface can be annotated as conversational, or the service or reference using the interface can be annotated as converational. By designating just the interface as conversational, I meant it should be considered as conversational wherever it appears in the SCDLs without having to specify anything additional. I think with ASSEMBLY-47 only the service or reference under which the interface element appears will be considered as conversational and it does not affect the other occurrences of the same interface elsewhere in the composite. For example in: component name=c1 ... service name=Service1 interface.java interface=MyService requires=conversational operation name=method1 endsConversation=true/ /interface.java /service /component component name=c2 ... service name=Service1 interface.java interface=MyService/ /service /component The MyService interface is conversational only in component c1 but not in c2. Yes, this can happen, and I don't think it's a problem. 2. Designating a method in a conversational interface as ends conversation. JAVA: The @EndsConversation annotation on a method designates the method as ends conversation. ASSEMBLY: Right now there is no way to do this through SCDLs. http://www.osoa.org/jira/browse/ASSEMBLY-47 seem to talk about a similar issue but in the context of interfaces defined in WSDLs. Problem: Even if an operation element is introduced under interface element, it is not possible to guarantee consistency across all the occurrences of the interface in the SCDLs. For example, the interface used under a service element in component1 may designate method1 as ends conversation where as a different component using the same interface need not necessarily designate method1 as ends conversation. If the two components involved are being wired together using this interface, but have inconsistent definitions for which methods are ends conversation, this is an error in the SCDL assembly and should be detected by the SCA runtime. It is not necessary that both the components are wired together. The two components could be using the interface element under service element. How does this cause a problem? Can you give more specific details of the problem scenario? 3. Designating a service is a conversational service: JAVA: A service whose interface is decorated with @Conversational annotation is a conversational service. ASSEMBLY: A conversational intent can be specified on the component service whose java interface is not decorated with @Conversational. Problem: We can not guarantee that all components that provide a service with a particular interface use the conversational intent on the service consistently. For e.g, component1 may use conversational intent on the service1, whereas component2 that provides a service2 with the same interface as service1 need not use conversational intent. Why is this a problem? From SCA's perspective, the conversational and non-conversational forms would be different interfaces. Unless they are wired together, this does not cause any problems. Tuscany seems to use the same interface object wherever an interface features. Perhaps it should clone the interface object so that additional intents can be set as required without affecting all occurrences of the interface. 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. 4. Specifying Conversation attributes: JAVA: The @ConversationAttributes annotation used on the implementation class enables specifying conversation attributes applicable to the conversational interfaces of services and references of the class. ASSEMBLY: Right now there is no way to specify conversation attributes through SCDLs. http://www.osoa.org/jira/browse/JAVA-14 seems to refer to the same problem. Yes it does
Re: OSGi-enable 3rd party libraries in Tuscany
One comment inline. Simon Jean-Sebastien Delfino wrote: Rajini Sivaram wrote: Hello, Following on from the discussion in thread [1], and based on Sebastien's comments [2], we need to make a decision on the best way forward to OSGi-enable third party libraries used by Tuscany. The options we have are: 1. Add OSGi manifest entries to all 3rd party jars in the Tuscany distribution. Existing OSGi tools like maven-bundle-plugin and maven-pax-plugin can be used to generate these bundles. The new manifest entries will not have any impact when Tuscany is run outside OSGi. For signed jars and jars with license restrictions, it may be necessary to generate a bundle with the jar embedded into it, resulting in separate jars for OSGi and non-OSGi. But these should hopefully be small in number. 2. Use non-OSGi mechanism to enable Tuscany bundles running inside OSGi to refer to jars outside OSGi. 3. Create virtual bundles on the fly for 3rd party jars. At the moment, itest/osgi-tuscany does this using auto-generated naive manifests. If we are to use virtual bundles going forward, manifest entries for the virtual bundles should be created at build time, and stored in one of the Tuscany jars. I believe that if we are serious about making OSGi-enablement of Tuscany a first class option, we should consider doing 1). For the longer term to support versioning of 3rd party jars, 1) will provide a standard OSGi mechanism. As more and more 3rd-party libraries are being OSGi-enabled, this can be seen as an intermediate step which enables users of Tuscany to install Tuscany in the same standard OSGi way, into an OSGi runtime. I agree and think we should do (1) everywhere we can. I don't think Tuscany should modify third-party jars that we are redistributing as part of Tuscany. I think we should use some variant of (3) for all third-party jars that aren't already OSGi-enabled. Simon 3) works, and looks easier to roll out, but I would imagine that OSGi users of Tuscany would end up creating their own variants of 1) if we support only 3). And it feels like a wrapper (or rather it is a wrapper), with manifests and their matching 3rd party libs stored separately. How about an interim variation of (3) for the 3rd party JARs that we initially can't cover with (1): For each 3rd party foo.jar, a foo-osgi.jar containing the bundle manifest that'll turn foo.jar into an OSGi virtual bundle, and I mean a proper bundle manifest with actual specific imports / exports instead of the naive *. I'm just throwing this up in the air to see any reactions from OSGi-skilled people in the group :) Maybe it's a stupid idea? but that would provide the level of modularity that we're expecting from OSGi, instead of mashing everything up in a central tuscany- manifest.jar which pretty much kills the benefits of using OSGi IMO. Thoughts? [1] http://markmail.org/message/tybuyxoaddjjrpbx [2] http://markmail.org/message/wbuixok3x3hazjqq Thank you... Regards, Rajini
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: I was thinking about a branch to make it clear that it was shared and that this work was open to all, but I'm also happy to see that work start in shared sandboxes. I guess from whats been said so far then I'd favour using sandboxes for now for specific work that really can't be done in trunk, and where ever possible continue to use trunk to do what can be done there (looking at that list of examples i think we could find ways to do a lot in trunk). I also think that many of these could be done in trunk. It would be good to talk about each of these and come to a conclusion on what the options are for a solution, and whether or not these proposed options can be implemented in trunk. Simon
Re: Our Incubator report must be due
ant elder wrote: There hasn't been any reminders sent out yet but according to the schedule today is when our Incubator report is due. I've made a rough start, feel free update: http://wiki.apache.org/incubator/May2008 ...ant The charter words were out of date (still referring to SDO). I have updated them to match what's in the graduation proposal. Simon
Re: SCA 2.0, was Re: Next SCA release
ant elder wrote: On Tue, May 13, 2008 at 8:26 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Luciano Resende wrote: I was waiting to start this discussion after SCA 1.2 was out of the door, but looks like you were faster then me. I'm +1 on this, and here is my proposal. - Continue with SCA 1.x maintenance releases based on the current SCA 1.2 branch. This would be a more stable codebase, and we should avoid big changes that could brake backward compatibility here. - Use trunk as our SCA 2.0 release stream, where we would do the type of work discussed in [1], the cleanup and restructuring mentioned by you on this thread, as well as any other work that the community feels its applicable. Note that my proposal does not exclude merging items between branch and trunk as necessary, but this would probably be done case by case when the community thinks it's applicable. Thoughts ? [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29820.html On Tue, Apr 8, 2008 at 12:55 AM, ant elder [EMAIL PROTECTED] wrote: With 1.2 almost out the door how about starting to think about our next release... We've had several discussions in the past about restructuring and cleaning up the distributions, build, and SPIs etc, is this the time to do that? Looking about the code there's many things that could be tidied up but we've been leaving them to keep backward compatibility, if we start this type of thing now it will make the next release not backward compatible so we need to agree this is the right time. We could make a new 1.x branch to use as a maintenance branch for the previous releases so we can still get fixes out for them. Leaving aside for now any detail about what the clean up and breaking changes might be what do you all think about doing this in the next release? I think its the right time so am in favour of starting this. ...ant I think it's time to restart that discussion. I was busy with conferences the last two weeks and had less time to keep up with the dev discussions. Now that I'm catching up with email it is becoming very apparent to me that there are a number of good discussions and initiatives that can lead to good changes and improvements of our code base. Here are a few examples, in no particular order: - Databinding work, with some brainstorming started by Raymond. - OSGi integration, which may lead to SPI and module changes, maybe even some distribution changes. - Extension mechanism, with some discussions about switching to XML and/or using definitions.xml or similar mechanisms. - SCA domain implementation, I'm starting to see emerge different trends / directions, not addressed by the recent work that Simon and I have done in that area. - Runtime integration in particular with Web containers. I think that We now have 3 or 4 different variants of this. - Model changes, in particular in the area of Bindings/Endpoints, which will lead to Provider SPI changes too. - Changes to our WSDL modeling story, Java2WSDL generation, and looking at the difficulties Mike went through in the BPEL integration to get his hands on WSDL, I think we can improve that WSDL model and handling too. - New SCA client APIs (still need to catch up with that but it looks like there's good discussions about that too). - Support for the SCA/JEE spec, which I think will bring new requirements to our models and SPIs. I'm probably missing a few more items like that, but the point is that we need a place to work on all these new ideas. On the other hand, I think it's really important to continue to maintain the code base that works today alive with it's APIs and SPIs, for all the people who currently use, integrate and embed Tuscany, and to be able to continue to promote SOA and the SCA programming model with that code base. So, how about starting a 2.0 branch for the new stuff that we want to rework, and a 1.x branch for the existing code base? Here's my +1 :) -- Jean-Sebastien It would be good to clean up and improve all the things that have been mentioned in this thread, but I still believe what I said in [1]. So if we're ready to put the 1.x in maintenance mode and start doing this new work in trunk thats great, but if we've still significant development work to do in 1.x then I don't think we should have a 2.0 branch yet. That shouldn't stop us doing most of this new work in trunk though as most of what we're talking in about in this thread can continue to be done in the current trunk without being too disruptive. ...ant [1] http://apache.markmail.org/message/75wp2p3juyzb4xym I don't think we should be putting 1.x into maintenance mode now. I'm open to having an exploratory branch for 2.0 that would be used as a place to experiment with new ideas that can't be done in the 1.x trunk because they are too disruptive. If we do this, we'll need to have a clear understanding of what things would be done in the 2.0 branch and what activity would continue in
Re: Are the nightly builds working?
ant elder wrote: If I go to the Tuscany download page - http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html - and click on any of the nightly build links I get You are not authorized to access this page. Please contact your administrator to be granted the appropriate permissions. Do they work for anyone else, could one of our continuum admins have a look? ...ant I'm getting the same access refused message. Simon
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 Simon ant elder wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged.
[jira] Assigned: (TUSCANY-2306) Client callback state preserved through stateless callback
[ https://issues.apache.org/jira/browse/TUSCANY-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-2306: --- Assignee: Simon Nash Client callback state preserved through stateless callback -- Key: TUSCANY-2306 URL: https://issues.apache.org/jira/browse/TUSCANY-2306 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Lines 650-654 of the Java CAA specification state: The difference for stateless services is that the callback field would not be available if the component is servicing a request for anything other than the original client. So, the technique used in the previous section, where there was a response from the backend Service which was forwarded as a callback from MyService would not work because the *callback field would be null* when the message from the backend system was received. The test case org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statelessCallback3 demosntrates that the callback field is not null when the message is received from the back end service -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TUSCANY-2306) Client callback state preserved through stateless callback
[ https://issues.apache.org/jira/browse/TUSCANY-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2306. - Resolution: Fixed A callback proxy was always being injected, even when the invocation creating the instance did not include a callback endpoint. Fixed in revision 654860. Client callback state preserved through stateless callback -- Key: TUSCANY-2306 URL: https://issues.apache.org/jira/browse/TUSCANY-2306 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash Fix For: Java-SCA-Next Lines 650-654 of the Java CAA specification state: The difference for stateless services is that the callback field would not be available if the component is servicing a request for anything other than the original client. So, the technique used in the previous section, where there was a response from the backend Service which was forwarded as a callback from MyService would not work because the *callback field would be null* when the message from the backend system was received. The test case org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statelessCallback3 demosntrates that the callback field is not null when the message is received from the back end service -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [CANCELLED] [VOTE] Graduate Apache Tuscany as a Top Level Project
Raymond Feng wrote: Hi, When we reference SCA in the charter, should we use Service Component Architecture (SCA) instead? The reference is to the SCA standard defined by the OASIS OpenCSA member section. This seems clear and unambiguous to me. However, I don't object to spelling it out in full if others want to do this. Simon Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Friday, May 09, 2008 5:49 AM To: tuscany-dev@ws.apache.org Subject: Re: [CANCELLED] [VOTE] Graduate Apache Tuscany as a Top Level Project Last call, unless anyone says otherwise i'll be restarting this vote tomorrow morning using the contents of the wiki page: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution ...ant On Fri, May 9, 2008 at 9:01 AM, Luciano Resende [EMAIL PROTECTED] wrote: Seems ok to me too. On Thu, May 8, 2008 at 3:36 AM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: The current draft proposal is at: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution Reviews and updates welcome. ...ant On Wed, Apr 30, 2008 at 5:04 PM, ant elder [EMAIL PROTECTED] wrote: Turns out we're not quite ready yet. ...ant On Wed, Apr 30, 2008 at 5:03 PM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 30, 2008 at 4:59 PM, Simon Nash [EMAIL PROTECTED] wrote: snip I'm not happy that we would do this over something as important as the technical charter for the project. I think we need to formally vote as a project on the words we want to take forward to the IPMC. We should be able to restart the vote with this correction and have it complete in time to get the proposal to the board in time for the May board meeting. Ok I'll cancel this vote then. ...ant This version looks OK to me. Simon -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
Re: Build failure in databindings itest
Mike Edwards wrote:
Folks,
This is another error which adds to the heap of reasons why I hate
Maven - Maven is one of the worst systems I have ever dealt with when
things go wrong.
- it's a dependency problem - dependencies of the velocity package,
which I believe is brought in by one of the Maven plugins
- why its dependencies aren't automatically handled I have no idea -
they are clearly pointed at in the velocity POM
- I fixed the problem by explicitly adding dependencies for
commons-collections and for log4j to the POM for the itest-databindings
Why this fix works, I'd be very happy for someone to explain.
I'll be happy to commit this change should no-one object - it's a hack
but it does fix the build.
Thanks for digging into this and finding a workaround. I'd be fine
with having this committed to SVN. This would be more convenient
than having to modify this POM myself every time I do a checkout.
Simon
Yours, Mike.
Simon Nash wrote:
I ran mvn -e and got a stack trace as follows. It looks like the
class org/apache/commons/collections/ExtendedProperties was not
found. Any ideas?
Simon
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
F:\tuscany69\sca\itest\databindings\sdogen\target
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An exception occured while executing the Java class. null
org/apache/commons/collections/ExtendedProperties
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An exception
occured whi
le executing the Java class. null
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An
exception occured
while executing the Java class. null
at
org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:324)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
... 16 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/collections/Extend
edProperties
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.ja
va:160)
at
org.apache.velocity.runtime.RuntimeSingleton.clinit(RuntimeSingleto
n.java:95)
at org.apache.velocity.app.Velocity.init(Velocity.java:106)
at
org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java
:90)
at
org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:174
)
... 6 more
Simon Nash wrote:
The SDO databindings itest is failing as well. The error is quite
cryptic. See below.
Simon
[INFO
Re: Build failure in databindings itest
After checking out Mike's change (thanks, Mike!), I was able to
build itest/databindings/sdogen but I then hit the same issue in
itest/databindings/jaxbgen. I have added the same dependencies
to this pom file to enable it to build.
Simon
Simon Nash wrote:
Mike Edwards wrote:
Folks,
This is another error which adds to the heap of reasons why I hate
Maven - Maven is one of the worst systems I have ever dealt with when
things go wrong.
- it's a dependency problem - dependencies of the velocity package,
which I believe is brought in by one of the Maven plugins
- why its dependencies aren't automatically handled I have no idea -
they are clearly pointed at in the velocity POM
- I fixed the problem by explicitly adding dependencies for
commons-collections and for log4j to the POM for the itest-databindings
Why this fix works, I'd be very happy for someone to explain.
I'll be happy to commit this change should no-one object - it's a hack
but it does fix the build.
Thanks for digging into this and finding a workaround. I'd be fine
with having this committed to SVN. This would be more convenient
than having to modify this POM myself every time I do a checkout.
Simon
Yours, Mike.
Simon Nash wrote:
I ran mvn -e and got a stack trace as follows. It looks like the
class org/apache/commons/collections/ExtendedProperties was not
found. Any ideas?
Simon
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir:
F:\tuscany69\sca\itest\databindings\sdogen\target
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An exception occured while executing the Java class. null
org/apache/commons/collections/ExtendedProperties
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An exception
occured whi
le executing the Java class. null
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An
exception occured
while executing the Java class. null
at
org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:324)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:447)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
... 16 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NoClassDefFoundError:
org/apache/commons/collections/Extend
edProperties
at
org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.ja
va:160)
at
org.apache.velocity.runtime.RuntimeSingleton.clinit(RuntimeSingleto
n.java:95)
at org.apache.velocity.app.Velocity.init(Velocity.java:106)
at
org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java
:90
Build failure in helloworld-bpel sample
I just did a full checkout and build. The build failed in the helloworld-bpel sample with the following exception. Simon Running helloworld.BPELHelloWorldTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.479 sec FA ILURE! testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 1.456 sec ERRO R! org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCAD omain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain. java:70) at helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:4 2) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner. java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet. java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:879) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .getPartnerLinkTypes(BPELDocumentProcessor.java:206) at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .resolve(BPELDocumentProcessor.java:172) at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .resolve(BPELDocumentProcessor.java:77) at org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProce ssorExtensionPoint$LazyURLArtifactProcessor.resolve(DefaultURLArtifactProcessorE xtensionPoint.java:195) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactPr ocessor.resolve(ExtensibleURLArtifactProcessor.java:86) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.processResolvePhase(ContributionServiceImpl.java:497) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.addContribution(ContributionServiceImpl.java:372) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.contribute(ContributionServiceImpl.java:168) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContrib ution(DefaultSCADomain.java:291) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(Defau ltSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(Def aultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCAD omain.java:242) ... 20 more Results : Tests in error: testInvoke(helloworld.BPELHelloWorldTestCase)
[jira] Resolved: (TUSCANY-2299) Client-set callback id not preserved on stateless callback
[ https://issues.apache.org/jira/browse/TUSCANY-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2299. - Resolution: Fixed The test case was using incorrect code to get the callback ID within the callback method. I have fixed the test case and removed the @Ignore. These changes are in revision 654459. Client-set callback id not preserved on stateless callback -- Key: TUSCANY-2299 URL: https://issues.apache.org/jira/browse/TUSCANY-2299 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec says the following re: stateless callbacks: 613 A stateless callback interface is a callback whose interface is not marked as conversational. Unlike 614 stateless services, the client of that uses stateless callbacks will not have callback methods routed to an 615 instance of the client that contains any state that is relevant to the conversation. As such, it is the 616 responsibility of such a client to perform any persistent state management itself. The only information that 617 the client has to work with (other than the parameters of the callback method) is a callback ID object that is 618 passed with requests to the service and is guaranteed to be returned with any callback. 619 The following is a repeat of the client code fragment above, but with the assumption that in this case the 620 MyServiceCallback is stateless. The client in this case needs to set the callback ID before invoking the 621 service and then needs to get the callback ID when the response is received. The test: org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statelessCallback2 demonstrates this issue and 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.
[jira] Assigned: (TUSCANY-2299) Client-set callback id not preserved on stateless callback
[ https://issues.apache.org/jira/browse/TUSCANY-2299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash reassigned TUSCANY-2299: --- Assignee: Simon Nash Client-set callback id not preserved on stateless callback -- Key: TUSCANY-2299 URL: https://issues.apache.org/jira/browse/TUSCANY-2299 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Assignee: Simon Nash The Java CAA spec says the following re: stateless callbacks: 613 A stateless callback interface is a callback whose interface is not marked as conversational. Unlike 614 stateless services, the client of that uses stateless callbacks will not have callback methods routed to an 615 instance of the client that contains any state that is relevant to the conversation. As such, it is the 616 responsibility of such a client to perform any persistent state management itself. The only information that 617 the client has to work with (other than the parameters of the callback method) is a callback ID object that is 618 passed with requests to the service and is guaranteed to be returned with any callback. 619 The following is a repeat of the client code fragment above, but with the assumption that in this case the 620 MyServiceCallback is stateless. The client in this case needs to set the callback ID before invoking the 621 service and then needs to get the callback ID when the response is received. The test: org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statelessCallback2 demonstrates this issue and 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: Generated WSDL Target Namespace calculation not spec compliant?
Lou Amodeo wrote: Hi, It doesnt appear that Tuscany is implementing section 2.3.2 of the WS Binding specification completely. Can you explain the algorithm used for reference and service side WSDL TNS generation for service, ports, and bindings. Thanks. The target namespace of the WSDL document, and of the service, ports and generated binding 272 elements is: 273 Base System URI for HTTP / Component Name / Service Name I am in the process of changing the Tuscany WSDL generation for the WSDL-less case from using Axis2 to using code within Tuscany. This will enable SCA-specific customizations of the generated WSDL (like the rule above) to be incoporated in the WSDL generation algorithm. On the service side, in the absence of JAX-WS customizations, it seems clear that Tuscany should use the above algorithm to calculate the TNS. If JAX-WS customizations are specified, I believe Tuscany should use them to override this default. It would be good to get a spec clarification that this is correct. On the reference side, the information stated above may not be available. If there is an @target on the reference, it would be possible to use the target's component and service. However, this information isn't available if there's no @target. The spec should state what the reference side should do in the cases with and without @target specified. I'll open a spec issue to clarify what should happen in all these cases. Until this is resolved, I'm inclined to leave the new WSDL generation code for references as it stands currently, i.e., using the TNS specified by JAX-WS. Simon
Re: [CANCELLED] [VOTE] Graduate Apache Tuscany as a Top Level Project
ant elder wrote: The current draft proposal is at: http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Draft+TLP+Resolution Reviews and updates welcome. ...ant On Wed, Apr 30, 2008 at 5:04 PM, ant elder [EMAIL PROTECTED] wrote: Turns out we're not quite ready yet. ...ant On Wed, Apr 30, 2008 at 5:03 PM, ant elder [EMAIL PROTECTED] wrote: On Wed, Apr 30, 2008 at 4:59 PM, Simon Nash [EMAIL PROTECTED] wrote: snip I'm not happy that we would do this over something as important as the technical charter for the project. I think we need to formally vote as a project on the words we want to take forward to the IPMC. We should be able to restart the vote with this correction and have it complete in time to get the proposal to the board in time for the May board meeting. Ok I'll cancel this vote then. ...ant This version looks OK to me. Simon
Re: Build failure in helloworld-bpel sample
Simon Laws wrote: On Thu, May 8, 2008 at 10:24 AM, Simon Nash [EMAIL PROTECTED] wrote: I just did a full checkout and build. The build failed in the helloworld-bpel sample with the following exception. Simon Running helloworld.BPELHelloWorldTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.479 sec FA ILURE! testInvoke(helloworld.BPELHelloWorldTestCase) Time elapsed: 1.456 sec ERRO R! org.osoa.sca.ServiceRuntimeException: java.lang.NullPointerException at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCAD omain.java:276) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain. java:70) at helloworld.BPELHelloWorldTestCase.setUp(BPELHelloWorldTestCase.java:4 2) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner. java:35) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet. java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTes tSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab stractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su refireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j ava:879) Caused by: java.lang.NullPointerException at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .getPartnerLinkTypes(BPELDocumentProcessor.java:206) at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .resolve(BPELDocumentProcessor.java:172) at org.apache.tuscany.sca.implementation.bpel.impl.BPELDocumentProcessor .resolve(BPELDocumentProcessor.java:77) at org.apache.tuscany.sca.contribution.processor.DefaultURLArtifactProce ssorExtensionPoint$LazyURLArtifactProcessor.resolve(DefaultURLArtifactProcessorE xtensionPoint.java:195) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactPr ocessor.resolve(ExtensibleURLArtifactProcessor.java:86) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.processResolvePhase(ContributionServiceImpl.java:497) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.addContribution(ContributionServiceImpl.java:372) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceI mpl.contribute(ContributionServiceImpl.java:168) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContrib ution(DefaultSCADomain.java:291) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(Defau ltSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(Def aultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCAD omain.java:242) ... 20 more Results : Tests in error: testInvoke(helloworld.BPELHelloWorldTestCase) I just got that too. Simon There's also a problem when running the bpel itest. Simon
Re: Move the JSP tag lib to the tuscany-sca-api module?
ant elder wrote: To work at run time yes, but not at development time so the IDE taglib validation works without them while you're developing the JSP. ...ant On Thu, May 8, 2008 at 5:19 PM, Raymond Feng [EMAIL PROTECTED] wrote: What about org.apache.tuscany.sca.host.webapp.jsp.ReferenceTag and org.apache.tuscany.sca.host.webapp.jsp.ReferenceTEI? I guess there classes have to be on the classpath for the TagLib to work, right? Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 8:49 AM To: tuscany-dev@ws.apache.org Subject: Re: Move the JSP tag lib to the tuscany-sca-api module? I may not have been very clear in the first email and also left out the link - it is just a single file that doesn't drag in any additional dependencies - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-webapp/src/main/resources/META-INF/sca.tld Is a whole new module really necessary? ...ant On Thu, May 8, 2008 at 4:46 PM, Raymond Feng [EMAIL PROTECTED] wrote: I think we should have a separate module like tuscany-sca-jee-api if we are ready to do so. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 8:08 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Move the JSP tag lib to the tuscany-sca-api module? I was wondering about moving the JSP taglib thats currently in the host-webapp module [1] to be in the sca-api module. The point being if you use an IDE that can validate JSPs then if the jar with the taglib is in the application classpath the IDE will validate the use of the taglib, so right now that means you need to add the tuscany-host-webapp jar which seems like it unnecessarily exposes tuscany internals to the app developer whereas if the taglib was in the sca-api than thats seems fine to have in the application classpath. ...ant The sca-api module is currently used only for SCA APIs defined by osoa.org. This taglib is a Tuscany API not an SCA API. So I think it should be in a different module. Simon
Re: Build failure in databindings itest
I ran mvn -e and got a stack trace as follows. It looks like the
class org/apache/commons/collections/ExtendedProperties was not
found. Any ideas?
Simon
[INFO] [exec:java {execution: generate-test-sdo-source}]
Building project from dir: F:\tuscany69\sca\itest\databindings\sdogen\target
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] An exception occured while executing the Java class. null
org/apache/commons/collections/ExtendedProperties
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: An exception occured whi
le executing the Java class. null
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:564)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
ltLifecycleExecutor.java:459)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: An exception occured
while executing the Java class. null
at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:324)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
nManager.java:447)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
ultLifecycleExecutor.java:539)
... 16 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:273)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/collections/Extend
edProperties
at org.apache.velocity.runtime.RuntimeInstance.init(RuntimeInstance.ja
va:160)
at org.apache.velocity.runtime.RuntimeSingleton.clinit(RuntimeSingleto
n.java:95)
at org.apache.velocity.app.Velocity.init(Velocity.java:106)
at org.apache.tuscany.sca.itest.generate.Generate.generate(Generate.java
:90)
at org.apache.tuscany.sca.itest.generate.Generate.main(Generate.java:174
)
... 6 more
Simon Nash wrote:
The SDO databindings itest is failing as well. The error is quite
cryptic. See below.
Simon
[INFO]
[INFO] Building Apache Tuscany SCA SDO Databinding Integration Tests
[INFO]task-segment: [install]
[INFO]
[INFO] artifact org.apache.maven.plugins:maven-dependency-plugin:
checking for u
pdates from java.net
[INFO] artifact org.codehaus.mojo:exec-maven-plugin: checking for
updates from j
ava.net
[INFO] artifact org.codehaus.mojo:exec-maven-plugin: checking for
updates from a
pache.incubator
[INFO] artifact org.codehaus.mojo:exec-maven-plugin: checking for
updates from c
odehaus-snapshot
[INFO] snapshot org.codehaus.mojo:exec-maven-plugin:1.1-beta-2-SNAPSHOT:
checkin
g for updates from java.net
[INFO] snapshot org.codehaus.mojo:exec-maven-plugin:1.1-beta-2-SNAPSHOT:
checkin
g for updates from apache.snapshots
[INFO] snapshot org.codehaus.mojo:exec-maven-plugin:1.1-beta-2-SNAPSHOT:
checkin
g for updates from codehaus-snapshot
Downloading:
http://snapshots.repository.codehaus.org/org/codehaus/mojo/exec-mav
en
Re: Move the JSP tag lib to the tuscany-sca-api module?
ant elder wrote: On Thu, May 8, 2008 at 7:38 PM, Simon Nash [EMAIL PROTECTED] wrote: ant elder wrote: To work at run time yes, but not at development time so the IDE taglib validation works without them while you're developing the JSP. ...ant On Thu, May 8, 2008 at 5:19 PM, Raymond Feng [EMAIL PROTECTED] wrote: What about org.apache.tuscany.sca.host.webapp.jsp.ReferenceTag and org.apache.tuscany.sca.host.webapp.jsp.ReferenceTEI? I guess there classes have to be on the classpath for the TagLib to work, right? Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 8:49 AM To: tuscany-dev@ws.apache.org Subject: Re: Move the JSP tag lib to the tuscany-sca-api module? I may not have been very clear in the first email and also left out the link - it is just a single file that doesn't drag in any additional dependencies - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-webapp/src/main/resources/META-INF/sca.tld Is a whole new module really necessary? ...ant On Thu, May 8, 2008 at 4:46 PM, Raymond Feng [EMAIL PROTECTED] wrote: I think we should have a separate module like tuscany-sca-jee-api if we are ready to do so. Thanks, Raymond -- From: ant elder [EMAIL PROTECTED] Sent: Thursday, May 08, 2008 8:08 AM To: tuscany-dev tuscany-dev@ws.apache.org Subject: Move the JSP tag lib to the tuscany-sca-api module? I was wondering about moving the JSP taglib thats currently in the host-webapp module [1] to be in the sca-api module. The point being if you use an IDE that can validate JSPs then if the jar with the taglib is in the application classpath the IDE will validate the use of the taglib, so right now that means you need to add the tuscany-host-webapp jar which seems like it unnecessarily exposes tuscany internals to the app developer whereas if the taglib was in the sca-api than thats seems fine to have in the application classpath. ...ant The sca-api module is currently used only for SCA APIs defined by osoa.org. This taglib is a Tuscany API not an SCA API. So I think it should be in a different module. Simon The tag lib is not defined by Tuscany its exactly as defined by osoa.org, in the SCA JEE spec, section 5.4.4 line 524. ...ant My apologies. I was unaware of this and I was deceived by the Tuscany-specific implementation class names. From looking at the spec, there seem to be a couple of minor issues with this file: 1. The namespace is www.osog.org instead of www.osoa.org. 2. The final part of the URI is sca.tld instead of sca_jsp.tld. As these are official SCA APIs, I don't see why we shouldn't put them in the sca-api module and jar. Simon
[jira] Commented: (TUSCANY-2306) Client callback state preserved through stateless callback
[ https://issues.apache.org/jira/browse/TUSCANY-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595393#action_12595393 ] Simon Nash commented on TUSCANY-2306: - I don't see the statelessCallback3 test in CallbackTestCase.java. What is the revision number for the checkin? Client callback state preserved through stateless callback -- Key: TUSCANY-2306 URL: https://issues.apache.org/jira/browse/TUSCANY-2306 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Kevin Williams Lines 650-654 of the Java CAA specification state: The difference for stateless services is that the callback field would not be available if the component is servicing a request for anything other than the original client. So, the technique used in the previous section, where there was a response from the backend Service which was forwarded as a callback from MyService would not work because the *callback field would be null* when the message from the backend system was received. The test case org.apache.tuscany.sca.vtest.javaapi.conversation.callback.CallbackTestCase.statelessCallback3 demosntrates that the callback field is not null when the message is received from the back end service -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Need some help
Simon Laws wrote: On Thu, May 8, 2008 at 8:48 PM, Charuka Jayarathna [EMAIL PROTECTED] wrote: Dear all, I am a Masters student in Georgia State University, and hope to work on my Theses with some contribution to Tuscany. My adviser is fine with my suggestion to take over a Tuscany project and work on that as for my theses. He advises me to take over a project which has enough intellectual contribution as well as it should be a novel idea resulting a publishable paper at the end. I appreciate if you can help me finding some potential areas having above requirements fulfilled. Thank you Charuka Hi Charuka, welcome to Tuscany! We'd love to have you work with us on a Tuscany project. As it happens we went through a process a couple of months ago to come up with project ideas for Google Summer of Code this year. See the list we came up with here [1] as a starting point. Some of these projects are already being done by GSoC students. See the selected project proposals on this page [2]. It's probably not a good idea to take on one that is already being done. What we need is a new page listing all the current project ideas we have that people aren't working on. Luciano may have done this already and I'm sure he will point us to it if he has. If not this is just the kind of motivation we need to go and create one ;-) I'm sure we can come up with lots of other ideas so take a look at the list that's there and I'm sure people will post with new things here in due course. Regards Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29 [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29+Applications There was a proposal for SCA and PHP integration. It was added quite late and I don't believe anyone has taken it on. Is this of any possible interest? Simon
Build failure in implementation-data-xml
I seem to be having extremely bad luck in getting a build to run
at the moment. I have been trying for a couple of days without
success. After a new checkout, clean and rebuild just now, I got
the following failure in modules/implementation-data-xml.
Simon
[INFO]
[INFO] Building Apache Tuscany SCA Data Implementation Extension
[INFO]task-segment: [install]
[INFO]
[INFO] [sql:execute {execution: create-db}]
[INFO] Executing file: F:\tuscany69\sca\modules\implementation-data-xml\company.
sql
[ERROR] Failed to execute: DROP TABLE COMPANY
[ERROR] java.sql.SQLException: 'DROP TABLE' cannot be performed on 'COMPANY' bec
ause it does not exist.
[INFO] 4 of 5 SQL statements executed successfully
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 10 source files to F:\tuscany69\sca\modules\implementation-data
-xml\target\classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
F:\tuscany69\sca\modules\implementation-data-xml\src\main\java\org\apache\tuscan
y\sca\implementation\data\DATAImplementation.java:[86,78] cannot find symbol
symbol : class DATACollection
location: class org.apache.tuscany.sca.implementation.data.DATAImplementation
F:\tuscany69\sca\modules\implementation-data-xml\src\main\java\org\apache\tuscan
y\sca\implementation\data\DATAImplementation.java:[86,78] cannot find symbol
symbol : class DATACollection
location: class org.apache.tuscany.sca.implementation.data.DATAImplementation
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 7 minutes 28 seconds
[INFO] Finished at: Thu May 08 22:39:39 BST 2008
[INFO] Final Memory: 101M/362M
[INFO]
Re: Tuscany support an usage of binding.ws wsdl.service
Vamsavardhana Reddy wrote: I am running the service as part of a vtest using tuscany-host-tomcat. When I use wsdl.port instead of wsdl.service in wsdlElement, the service is running on the url as given for that port in the wsdl file. Thanks, this confirms that Tuscany has a bug with wsdl.service. Please can you open a JIRA for this. Simon ++Vamsi On Wed, May 7, 2008 at 3:25 AM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I have my AService with wsdl given below: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:soap12= http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:ns0= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:mime= http://schemas.xmlsoap.org/wsdl/mime/; xmlns:http= http://schemas.xmlsoap.org/wsdl/http/; xmlns:ns1= http://org.apache.axis2/xsd; xmlns:wsaw= http://www.w3.org/2006/05/addressing/wsdl; xmlns:xs= http://www.w3.org/2001/XMLSchema; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns= http://wsbinding.vtest.sca.tuscany.apache.org; xs:element name=getGreetings xs:complexType xs:sequence xs:element minOccurs=0 name=param0 nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsResponse xs:complexType xs:sequence xs:element minOccurs=0 name=return nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part name=parameters element=ns0:getGreetings /wsdl:part /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part name=parameters element=ns0:getGreetingsResponse /wsdl:part /wsdl:message wsdl:portType name=AServicePortType wsdl:operation name=getGreetings wsdl:input message=ns0:getGreetingsRequest wsaw:Action=urn:getGreetings /wsdl:input wsdl:output message=ns0:getGreetingsResponse wsaw:Action=urn:getGreetingsResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType soap12:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap12:operation soapAction=urn:getGreetings style=document/ wsdl:input soap12:body use=literal/ /wsdl:input wsdl:output soap12:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType http:binding verb=POST/ wsdl:operation name=getGreetings http:operation location=AService/getGreetings/ wsdl:input mime:content part=getGreetings type=text/xml/ /wsdl:input wsdl:output mime:content part=getGreetings type=text/xml/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=urn:getGreetings style=document/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=AServicePortTypeService wsdl:port name=AServicePortTypePort binding=ns0:AServicePortTypeBinding soap:address location=http://localhost:8090/AService/ /wsdl:port /wsdl:service wsdl:service name=AService wsdl:port name=AServiceHttpport binding=ns0:AServiceHttpBinding http:address location=http://localhost:8080/AService/ /wsdl:port wsdl:port name=AServiceSOAP12port_http binding=ns0:AServiceSOAP12Binding soap12:address location=http://localhost:8012/AService/ /wsdl:port wsdl:port name=AServiceSOAP11port_http binding=ns0:AServiceSOAP11Binding soap:address location=http://localhost:8011/AService/ /wsdl:port /wsdl:service /wsdl:definitions I have my composite one.composite as given below: ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://vtest; name=one component name=AComponent implementation.java class
Re: Tuscany support an usage of binding.ws wsdl.service
Vamsavardhana Reddy wrote: Opening different ports by the hosting environment does not seem to be a problem because when I use service name=AService binding.ws name=p11 wsdlElement= http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.port(AService/AServiceSOAP11port_http) / binding.ws name=p12 wsdlElement= http://wsbinding.vtest.sca.tuscany.apache.org#wsdl.port(AService/AServiceSOAP12port_http) / /service The service is available at http://localhost:8011/AService and http://localhost:8012/AService Which hosting environment did you use when testing this? It would not work if the hosting environment were a webapp container. Simon ++Vamsi On Wed, May 7, 2008 at 3:25 AM, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I have my AService with wsdl given below: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:soap12= http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:ns0= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:mime= http://schemas.xmlsoap.org/wsdl/mime/; xmlns:http= http://schemas.xmlsoap.org/wsdl/http/; xmlns:ns1= http://org.apache.axis2/xsd; xmlns:wsaw= http://www.w3.org/2006/05/addressing/wsdl; xmlns:xs= http://www.w3.org/2001/XMLSchema; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns= http://wsbinding.vtest.sca.tuscany.apache.org; xs:element name=getGreetings xs:complexType xs:sequence xs:element minOccurs=0 name=param0 nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsResponse xs:complexType xs:sequence xs:element minOccurs=0 name=return nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part name=parameters element=ns0:getGreetings /wsdl:part /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part name=parameters element=ns0:getGreetingsResponse /wsdl:part /wsdl:message wsdl:portType name=AServicePortType wsdl:operation name=getGreetings wsdl:input message=ns0:getGreetingsRequest wsaw:Action=urn:getGreetings /wsdl:input wsdl:output message=ns0:getGreetingsResponse wsaw:Action=urn:getGreetingsResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType soap12:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap12:operation soapAction=urn:getGreetings style=document/ wsdl:input soap12:body use=literal/ /wsdl:input wsdl:output soap12:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType http:binding verb=POST/ wsdl:operation name=getGreetings http:operation location=AService/getGreetings/ wsdl:input mime:content part=getGreetings type=text/xml/ /wsdl:input wsdl:output mime:content part=getGreetings type=text/xml/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=urn:getGreetings style=document/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=AServicePortTypeService wsdl:port name=AServicePortTypePort binding=ns0:AServicePortTypeBinding soap:address location=http://localhost:8090/AService/ /wsdl:port /wsdl:service wsdl:service name=AService wsdl:port name=AServiceHttpport binding=ns0:AServiceHttpBinding http:address location=http://localhost:8080/AService/ /wsdl:port wsdl:port name=AServiceSOAP12port_http binding=ns0:AServiceSOAP12Binding soap12:address location=http://localhost:8012/AService/ /wsdl:port wsdl:port name=AServiceSOAP11port_http binding=ns0:AServiceSOAP11Binding soap:address location=http
[jira] Commented: (TUSCANY-2298) Incorrect service endpoint when wsdl.service is used with Service webservice binding
[
https://issues.apache.org/jira/browse/TUSCANY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12594983#action_12594983
]
Simon Nash commented on TUSCANY-2298:
-
The problem is in the start() method of Axis2ServiceProvider. This should
create multiple Axis services if there are multiple compatible ports on the
WSDL service. (See the TODO: comment already in this code.)
Incorrect service endpoint when wsdl.service is used with Service webservice
binding
Key: TUSCANY-2298
URL: https://issues.apache.org/jira/browse/TUSCANY-2298
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension, Java SCA Tomcat
Integration
Affects Versions: Java-SCA-1.2
Reporter: Vamsavardhana Reddy
Fix For: Java-SCA-Next
Web Service Binding Specification Spec v1.00 - Sec 2.1 - lines 38 to 41:
38 o Service:
39 WSDL-namespace-URI#wsdl.service(service-name)
40 In this case, all the endpoints in the WSDL Service that have equivalent
PortTypes with
41 the SCA service or reference must be available to the SCA service or
reference.
When wsdlElement is of 'Service' type, service must be available on all ports
corresponding to the service. The following is the wsdl I am using for
'AService':
{code}
?xml version=1.0 encoding=UTF-8?
wsdl:definitions
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:soap12=http://schemas.xmlsoap.org/wsdl/soap12/;
xmlns:ns0=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:mime=http://schemas.xmlsoap.org/wsdl/mime/;
xmlns:http=http://schemas.xmlsoap.org/wsdl/http/;
xmlns:ns1=http://org.apache.axis2/xsd;
xmlns:wsaw=http://www.w3.org/2006/05/addressing/wsdl;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
wsdl:types
xs:schema attributeFormDefault=qualified
elementFormDefault=qualified
targetNamespace=http://wsbinding.vtest.sca.tuscany.apache.org;
xmlns:ns=http://wsbinding.vtest.sca.tuscany.apache.org;
xs:element name=getGreetings
xs:complexType
xs:sequence
xs:element minOccurs=0 name=param0
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
xs:element name=getGreetingsResponse
xs:complexType
xs:sequence
xs:element minOccurs=0 name=return
nillable=true type=xs:string/
/xs:sequence
/xs:complexType
/xs:element
/xs:schema
/wsdl:types
wsdl:message name=getGreetingsRequest
wsdl:part name=parameters element=ns0:getGreetings
/wsdl:part
/wsdl:message
wsdl:message name=getGreetingsResponse
wsdl:part name=parameters element=ns0:getGreetingsResponse
/wsdl:part
/wsdl:message
wsdl:portType name=AServicePortType
wsdl:operation name=getGreetings
wsdl:input message=ns0:getGreetingsRequest
wsaw:Action=urn:getGreetings
/wsdl:input
wsdl:output message=ns0:getGreetingsResponse
wsaw:Action=urn:getGreetingsResponse
/wsdl:output
/wsdl:operation
/wsdl:portType
wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType
soap12:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap12:operation soapAction=urn:getGreetings style=document/
wsdl:input
soap12:body use=literal/
/wsdl:input
wsdl:output
soap12:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction=/
wsdl:input
soap:body use=literal/
/wsdl:input
wsdl:output
soap:body use=literal/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType
http:binding verb=POST/
wsdl:operation name=getGreetings
http:operation location=AService/getGreetings/
wsdl:input
mime:content part=getGreetings type=text/xml/
/wsdl:input
wsdl:output
mime:content part=getGreetings type=text/xml/
/wsdl:output
/wsdl:operation
/wsdl:binding
wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType
soap:binding style=document
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getGreetings
soap:operation soapAction
Re: Tuscany support an usage of binding.ws wsdl.service
Lou Amodeo wrote: I am reading the WS Binding Specification and am trying to understand the meaning of the wsdl.service form of the WSDL Element's URI and to what extent and how it is supported in Tuscany? Thanks for your help. Service: 39 WSDL-namespace-URI#wsdl.service(service-name) 40 In this case, all the endpoints in the WSDL Service that have equivalent PortTypes with 41 the SCA service or reference must be available to the SCA service or reference. To answer this, I'll start by talking about SCA services, as the meaning in this case seems clearer. Suppose the WSDL document for an SCA service refers to a WSDL service Service1 that has WSDL ports Port1, Port2 and Port3. Port1 and Port3 use bindings that refer to PortType1, and Port2 uses a binding that refers to PortType2. The interface of the SCA service is either the WSDL interface PortType1, or a Java interface that's equivalent to PortType1. In this case, the SCA service would be listening on both Port1 and Port3 (but not Port2). I'm having trouble applying this to references, though. A reference would normally only invoke via one port. I'm not sure how an SCA reference that specifies the WSDL service described above could make use of both Port1 amd Port3. Simon
Re: Tuscany support an usage of binding.ws wsdl.service
Lou Amodeo wrote: I thought Vamsi was illustrating a scenario and asking a question. I thought so too, and I was doing my best to answer it :-) It's my understanding that the port definitions in the WSDL should be used in preference to the endpoint URI that SCA would compute using its default algorithm. Simon I agree with you as well, on the service side the spec does indicate some hosting environments cannot support endpoints defined in wsdl. Still trying to nail down the semantics of this attribute. The example above with the three http ports doesn't work for me. On 5/6/08, Simon Nash [EMAIL PROTECTED] wrote: Vamsavardhana Reddy wrote: I have my AService with wsdl given below: ?xml version=1.0 encoding=UTF-8? wsdl:definitions targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:soap12= http://schemas.xmlsoap.org/wsdl/soap12/; xmlns:ns0= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:mime= http://schemas.xmlsoap.org/wsdl/mime/; xmlns:http= http://schemas.xmlsoap.org/wsdl/http/; xmlns:ns1= http://org.apache.axis2/xsd; xmlns:wsaw= http://www.w3.org/2006/05/addressing/wsdl; xmlns:xs= http://www.w3.org/2001/XMLSchema; xmlns:soap= http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl= http://schemas.xmlsoap.org/wsdl/; wsdl:types xs:schema attributeFormDefault=qualified elementFormDefault=qualified targetNamespace= http://wsbinding.vtest.sca.tuscany.apache.org; xmlns:ns= http://wsbinding.vtest.sca.tuscany.apache.org; xs:element name=getGreetings xs:complexType xs:sequence xs:element minOccurs=0 name=param0 nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element xs:element name=getGreetingsResponse xs:complexType xs:sequence xs:element minOccurs=0 name=return nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=getGreetingsRequest wsdl:part name=parameters element=ns0:getGreetings /wsdl:part /wsdl:message wsdl:message name=getGreetingsResponse wsdl:part name=parameters element=ns0:getGreetingsResponse /wsdl:part /wsdl:message wsdl:portType name=AServicePortType wsdl:operation name=getGreetings wsdl:input message=ns0:getGreetingsRequest wsaw:Action=urn:getGreetings /wsdl:input wsdl:output message=ns0:getGreetingsResponse wsaw:Action=urn:getGreetingsResponse /wsdl:output /wsdl:operation /wsdl:portType wsdl:binding name=AServiceSOAP12Binding type=ns0:AServicePortType soap12:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap12:operation soapAction=urn:getGreetings style=document/ wsdl:input soap12:body use=literal/ /wsdl:input wsdl:output soap12:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServicePortTypeBinding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceHttpBinding type=ns0:AServicePortType http:binding verb=POST/ wsdl:operation name=getGreetings http:operation location=AService/getGreetings/ wsdl:input mime:content part=getGreetings type=text/xml/ /wsdl:input wsdl:output mime:content part=getGreetings type=text/xml/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:binding name=AServiceSOAP11Binding type=ns0:AServicePortType soap:binding style=document transport= http://schemas.xmlsoap.org/soap/http/ wsdl:operation name=getGreetings soap:operation soapAction=urn:getGreetings style=document/ wsdl:input soap:body use=literal/ /wsdl:input wsdl:output soap:body use=literal/ /wsdl:output /wsdl:operation /wsdl:binding wsdl:service name=AServicePortTypeService wsdl:port name=AServicePortTypePort binding=ns0:AServicePortTypeBinding soap:address location=http://localhost:8090/AService/ /wsdl:port /wsdl:service wsdl:service name=AService wsdl:port name=AServiceHttpport binding=ns0:AServiceHttpBinding http:address location=http://localhost:8080/AService/ /wsdl:port wsdl:port name=AServiceSOAP12port_http binding=ns0:AServiceSOAP12Binding soap12:address location=http://localhost:8012/AService/ /wsdl:port wsdl:port name=AServiceSOAP11port_http binding=ns0:AServiceSOAP11Binding soap:address location=http://localhost:8011/AService/ /wsdl:port /wsdl:service
Re: [jira] Updated: (TUSCANY-2220) WSDL representations of binding.ws generated incorrectly.
This was fixed in 1.2. I'm updating and resolving the JIRA. Simon Simon Laws (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws updated TUSCANY-2220: Fix Version/s: (was: Java-SCA-1.2) Java-SCA-Next Move fix to SCA Next WSDL representations of binding.ws generated incorrectly. - Key: TUSCANY-2220 URL: https://issues.apache.org/jira/browse/TUSCANY-2220 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-1.2 Environment: Websphere 6.1.0.14 on AIX, jdk150_10 Jetty on Windows XP x86, jdk150_10 Websphere on Windows XP x86, jdk150_10 Tomcat on Windows XP x86. jdk150_10 Reporter: Dave Sowerby Fix For: Java-SCA-Next WSDL representations of binding.ws generated incorrectly. I'm currently facing issues when attmepting to utilise the wsdl generated by a service exposed using binding.ws, when I use wsdl2java with this wsdl I get the following exception: IWAB0399E Error in generating Java from WSDL: java.io.IOException: Emitter failure. Cannot find endpoint address in port ServiceRequestPortType__SOAPHTTPPort in service ServiceRequestPortType__ServiceLocator java.io.IOException: Emitter failure. Cannot find endpoint address in port ServiceRequestPortType__SOAPHTTPPort in service ServiceRequestPortType__ServiceLocator at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java:189) at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127) at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112) at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate(JavaGeneratorFactory.java:421) at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476) at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362) at java.lang.Thread.run(Unknown Source) I've diffed a previously functioning wsdl against the currently (RC3a) generated wsdl file, the difference causing this problem appears to be the additional lines of: wsdl:service name=ServiceRequestPortType__Service wsdl:port name=ServiceRequestPortType__SOAPHTTPPort binding=ns2:ServiceRequestPortType__SOAPBinding /wsdl:port /wsdl:service Which without an address is causing wsdl2java to fail.
[jira] Resolved: (TUSCANY-2220) WSDL representations of binding.ws generated incorrectly.
[ https://issues.apache.org/jira/browse/TUSCANY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2220. - Resolution: Fixed Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.2 Fixed in SCA Java 1.2 rc4. WSDL representations of binding.ws generated incorrectly. - Key: TUSCANY-2220 URL: https://issues.apache.org/jira/browse/TUSCANY-2220 Project: Tuscany Issue Type: Bug Components: Java SCA Embedded Runtime Affects Versions: Java-SCA-1.2 Environment: Websphere 6.1.0.14 on AIX, jdk150_10 Jetty on Windows XP x86, jdk150_10 Websphere on Windows XP x86, jdk150_10 Tomcat on Windows XP x86. jdk150_10 Reporter: Dave Sowerby Fix For: Java-SCA-1.2 WSDL representations of binding.ws generated incorrectly. I'm currently facing issues when attmepting to utilise the wsdl generated by a service exposed using binding.ws, when I use wsdl2java with this wsdl I get the following exception: IWAB0399E Error in generating Java from WSDL: java.io.IOException: Emitter failure. Cannot find endpoint address in port ServiceRequestPortType__SOAPHTTPPort in service ServiceRequestPortType__ServiceLocator java.io.IOException: Emitter failure. Cannot find endpoint address in port ServiceRequestPortType__SOAPHTTPPort in service ServiceRequestPortType__ServiceLocator at org.apache.axis.wsdl.toJava.JavaServiceImplWriter.writeFileBody(JavaServiceImplWriter.java:189) at org.apache.axis.wsdl.toJava.JavaWriter.generate(JavaWriter.java:127) at org.apache.axis.wsdl.toJava.JavaServiceWriter.generate(JavaServiceWriter.java:112) at org.apache.axis.wsdl.toJava.JavaGeneratorFactory$Writers.generate(JavaGeneratorFactory.java:421) at org.apache.axis.wsdl.gen.Parser.generate(Parser.java:476) at org.apache.axis.wsdl.gen.Parser.access$000(Parser.java:45) at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:362) at java.lang.Thread.run(Unknown Source) I've diffed a previously functioning wsdl against the currently (RC3a) generated wsdl file, the difference causing this problem appears to be the additional lines of: wsdl:service name=ServiceRequestPortType__Service wsdl:port name=ServiceRequestPortType__SOAPHTTPPort binding=ns2:ServiceRequestPortType__SOAPBinding /wsdl:port /wsdl:service Which without an address is causing wsdl2java to fail. -- 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-2275) Problem when with Bean[] and null
Simon Nash wrote: Raymond Feng (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12593441#action_12593441 ] Raymond Feng commented on TUSCANY-2275: --- Hi, I debugged the issue and it turned out an interesting case. 1) When the client side pass 'null' for the service.processBean() method, the body of soap message becomes: ns1:processBean xmlns1=.../ It's the wrapper element with empty children. 2) On the receiving side, the empty data get converted into SimpleBean[0] which is an empty array of SimpleBean. 3) The user code in SimpleServiceImpl.java only tests if the simpleBean==null and it causes an ArrayOutofBoundException. Adding the test of simpleBean.length0 fixes the problem and the client runs successfuly. I would resolve it as a user error. I'm not so sure if we should present the data as null or [0]. If you can find any spec covering this corner case, I would be happy to revisit it. I think the marshalled form should be a wrapper containing a Bean element with xsi:nil=true, not an empty wrapper. Would this be unmarshalled as null instead of an empty array? To answer my own question, this would be unmarshalled as an array of length 1 containing a single null. This seems correct. Unfortunately it seems that there is no way to disambiguate this case from the null array case. I will do some more investigation into this. Simon Simon Thanks, Raymond Problem when with Bean[] and null - Key: TUSCANY-2275 URL: https://issues.apache.org/jira/browse/TUSCANY-2275 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.2 Environment: Tuscnay 1.2-RC4, WAS Reporter: Nishant Joshi Assignee: Raymond Feng Fix For: Java-SCA-1.2 Attachments: null problem.zip I have one service, in which i m passgin Bean[]... If i try to pass null instead then it gives exception - Exception in thread main org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at $Proxy6.processBean(Unknown Source) at com.client.Client.processBean(Client.java:22) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154) at org.apache.tuscany.sca.core.invocation.CglibProxyFactory$CglibMethodInterceptor.intercept(CglibProxyFactory.java:149) at com.client.Client$$EnhancerByCGLIB$$b5aedbbb.processBean(generated) at com.client.Client.main(Client.java:34) Caused by: org.apache.tuscany.sca.interfacedef.util.FaultException: Array index out of range: 0 at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:97) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78) ... 15 more Caused by: org.apache.axis2.AxisFault: Array index out of range: 0 at org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486) at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389) at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211) at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:118) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:89) ... 16 more
Re: Improving support for running in OSGi
Yang Lei wrote: I think enabling OSGI can help modularity with a clear definition of package visibility, so we can have a much cleaner module dependencies through osgi bundle import/export on package. I think it will help Tuscany adopters a lot in the scenarios such as: when implementing new implementation type, binding type, or data binding types, there is clear indication which set of packages can be used (exported API/SPI ). So upgrading to new Tuscany level can be as simple as plug and play if there is no API/SPI changes, and version control (multiple version co-existence) can also be made available through OSGI capabilities. +1 for the benefits to modularity. For versioning, I see the value more in terms of allowing multiple versions of third-party dependencies to coexist, rather than having multiple versions of some parts of Tuscany loaded at the same time. Are there any scenarios that would require the latter? Simon Regards, Yang On Tue, Apr 29, 2008 at 1:49 PM, Konradi, Philipp (CT) [EMAIL PROTECTED] wrote: Hi, I'd like to get people's thoughts on whether the idea of 'promoting' OSGi is a good one, IMHO support of OSGi is very important and I glad to see increasing interest of the community here. and get ideas on how best to proceed. I personally have currently not a very deep insight into implementation details yet, but we are currently prototyping and have there also OSGi services. What I could offer today is only to feed our findings about limitations and rooms for improvement back. Another important thing which I see on the horizon, is the ongoing standardization of Distributed OSGi (RFC119) and the benefit to support that standard in Tuscany's OSGi bits. So from mid-term perspective I suggest to keep an eye on that as well. Regards, Philipp -Ursprüngliche Nachricht- Von: Graham Charters [mailto:[EMAIL PROTECTED] Gesendet: Montag, 28. April 2008 09:48 An: tuscany-dev@ws.apache.org Betreff: Improving support for running in OSGi Hi All, I'd like to get more involved in the OSGi support in Tuscany (both the modularity work (itest/osgi-tuscany) and the implementation.osgi). I recently started looking at the work to run Tuscany in OSGi, embodied in itest/osgi-tuscany and described in the thread entitled Classloading in Tuscany. I've noticed a couple of others on the list also interested in Tuscany running in OSGi and wondered if it might be worth considering making this a first-class option. At the moment the five bundles are only built by folks who want the OSGi support and go into the itest/osgi-tuscany directory to create it. This can result in any problems being discovered late, but also could create the impression that OSGi is considered a second-class environment (which I don't believe is the case). Aside from the obvious benefits to OSGi users in doing this, I think there's a potential for Tuscany to use the OSGi build as a test-bed for highlighting and working through modularity issues, which would also benefit Tuscany in general, not just in an OSGi runtime. I'd like to get people's thoughts on whether the idea of 'promoting' OSGi is a good one, and get ideas on how best to proceed. We could then start discussing what some of the issues might be (e.g. size of builds, time to build, etc...). Regards, Graham.
