Re: Domain changes
Jean-Sebastien Delfino wrote: Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. Simon On top of what you already have, I'd like to be able to describe Nodes with something like follows: composite name=MyNodes component name=NodeA implementation.node composite=bb:BigbankAccount/ /component component name=NodeB implementation.node composite=bb:BigbankCalculator/ /component /composite allowing, as a next step, to do something like follows: composite name=MyNodes component name=NodeA service name=ContributionManager binding.ws/ /service service name=ComponentManager binding.ws/ /service implementation.node composite=bb:BigbankAccount/ /component or for example component name=NodeB service name=ContributionManager binding.atom/ /service service name=ComponentManager binding.jsonrpc/ /service implementation.node composite=bb:BigbankCalculator/ /component /composite I'm starting on working on an implementation-node module to support that. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: uri of binding.ws should be used restrictedly
ant elder wrote: On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Mike Edwards wrote: Folks, Comments inline Yours, Mike. ant elder wrote: Had this over on the user list about how the binding.ws uri is ignored if you use wsdlElement with #wsdl.port. We used to throw an exception in that case which I think makes things much clearer but that code has been changed so that no longer happens. Was that removed intentionally or could i add it back? ...ant So, the question is that if both the URI and a WSDL are used, then they can conflict? From what you say, the WSDL wins silently in the current code. As a result, looking at the URI in the SCDL does not help - it is confusing. I think that at least a warning is called for. Whether an exception is the right thing, I'm less sure. The general rule with SCA WS binding is that once you start using WSDL, then it is taken as gospel. That is true for all kinds of metadata that can live in the WSDL. Only serious conflicts such as mismatch of interfaces or inability to satisfy specified intents should really cause exceptions. However, warnings of conflicts seem useful since it will bring the user's attention to what may indeed be a problem. -- Forwarded message -- From: ant elder [EMAIL PROTECTED] Date: Sep 12, 2007 8:46 AM Subject: Re: uri of binding.ws should be used restrictedly To: [EMAIL PROTECTED] On 9/12/07, shaoguang geng [EMAIL PROTECTED] wrote: Hello every one, uri attribute of binding.ws/ is much convenient to attach a WS in. But it works only within a few circumstances, such as another java generated WS provided by Tuscany, JAXWS. But much more WS is complecated, such as JBoss or even a Tuscany WS when the wsdl becomes delicate. I love the phrasing here. WSDL becomes delicate - may rather be said that the poor programmer's brain becomes delicate, once the WSDL gets complex. I'd far rather not deal with the WSDL, but I accept that is not practical for some cases. In these cases, you hope that the programmer can simply pick up the WSDL for some remote web service and use it without having to inspect it. The only thing they should need to do is run WSDL2Java against it to render a nice Java interface for the service that they use in their code. Otherwise, it's an opaque cookie. Under these circumstances, pre loading wsdl (locally save the wsdl) and use wsdlElement will do most of them. Up to now, I have gone over it with JBoss and ODE. So I just think, to make things frank, I would suggest that Tuscany user should be warned of uri's limitation, and encouraged of using wsdl preloading. The uri attribute should always get used unless the wsdlElement is pointing at the port (ie using #wsdl.port) in which case the uri attribute is ignored. So you can use both uri and pre loaded wsdl as long as you use #wsdl.binding within the wsdlElement. I agree its confusing that the uri can get completely ignored, the code did used to throw an exception in that case so it was obvious there was a conflict, i'll bring it up on the dev list to see if we can add that back. ...ant Having the WSDL win is as per the spec. Here's from the SCA Web Services Binding spec: 70 2.1.1 Endpoint URI resolution 71 The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, 72 when used with binding.ws (in precedence order) are: 73 1. The URIs in the endpoint(s) of the referenced WSDL 74 or 75 The URI specified by the wsa:Address element of the wsa:EndpointReference, 76 2. The explicitly stated URI in the uri attribute of the binding.ws element, which may be 77 relative, 78 3. The implicit URI as defined by the Assembly specification The spec doesn't clearly define what to do in this exact situation, I think thats a bug in the spec. What's not clear? What's the bug in the spec? And it doesn't seem very user friendly to just ignore a users input whether or not we give a warning as thats likely to just get buried in a log somewhere, so i'd prefer and exception. Forcing the application developer to modify the binding.ws and remove the uri attribute, to be able to specify the SOAP address in his WSDL is not user friendly either, and not in line with the spec. Isn't that what we agreed last time this came up - http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200707.mbox/browser. This points to the whole July archive :) ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build error with WSSecurityConfidentialityTestCase
Venkata Krishnan wrote: Hi Sebastien, There is nothing that needs to be done in the environment. The only dependency that I had trouble linking to the classpath from the maven repo during a maven build is the rampart.mar which I have now temporarilty packaged with the module. I suspect it could be to do with the key store and the JDK version you are using. Could you please try creating it with the following command: *keytool -genkey -alias TuscanyWsUser -keyalg RSA -keystore tuscanyKeys.jks * All thro, for everthing there is just one password I have used and it is 'TuscanyWsUserPasswd' and there is just one user id which is TuscanyWsUser. I created the key with keytool. The build is successful with the SUN JDK 1.5, getting the exception below with the IBM JDK 1.5. - Venkat On 9/12/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Is anybody else seeing that build error? Do I need to set up anything new in my build environment now that we have WS-security enabled (which is pretty cool BTW)? Running org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Sep 11, 2007 7:04:02 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://localhost:8085/myExplicitURI *** Calling Integrity Password Handler Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.096 sec FAILURE! testHelloWorld( org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase ) Time elapsed: 3.04 sec ERROR! java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:214) at javax.crypto.KeyGenerator.a(Unknown Source) at javax.crypto.KeyGenerator.init(Unknown Source) at javax.crypto.KeyGenerator.getInstance(Unknown Source) at org.apache.ws.security.message.WSSecEncrypt.getKeyGenerator( WSSecEncrypt.java:578) at org.apache.ws.security.message.WSSecEncrypt.prepare(WSSecEncrypt.java:202) at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:268) at org.apache.ws.security.action.EncryptionAction.execute( EncryptionAction.java:62) at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java :192) at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java :256) at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java :88) at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72) at org.apache.axis2.engine.Phase.invoke(Phase.java:383) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:433) at org.apache.axis2.description.OutInAxisOperationClient.send( OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute( OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget( Axis2BindingInvoker.java:95) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke( Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke (DataTransformationInteceptor.java:70) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldOMComponent.getGreetings (HelloWorldOMComponent.java:31) 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:105) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInteceptor.invoke( PassByValueInteceptor.java:49) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.policy.AbstractHelloWorldOMTestCase.testHelloWorld (AbstractHelloWorldOMTestCase.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
[jira] Updated: (TUSCANY-1690) Support SCA domain level autowire
[ https://issues.apache.org/jira/browse/TUSCANY-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1690: Fix Version/s: Java-SCA-Next Support SCA domain level autowire -- Key: TUSCANY-1690 URL: https://issues.apache.org/jira/browse/TUSCANY-1690 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-Next At this moment, we support autowire in the local composite. We need to add it for the domain-level too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1639) I would suggent a improvement on WSDLInterfaceProcessor
[ https://issues.apache.org/jira/browse/TUSCANY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1639. - Resolution: Duplicate This JIRA duplicates JIRA TUSCANY-1646. I would suggent a improvement on WSDLInterfaceProcessor --- Key: TUSCANY-1639 URL: https://issues.apache.org/jira/browse/TUSCANY-1639 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: jdk1.5 eclipse windiows latest svn code Reporter: gengshaoguang Fix For: Java-SCA-Next Hi everyone, I would suggest the following: When reference a wsdl with referenceinterface.wsdl interface=[uri]//reference, the [uri] atttribute must be based on a preloaded local saved wsdl file. Would it be better if the developer specify a ?wsdl like uri, then the WSDLInterfaceProcessor could load it from remote/dynamic place instead of from classpath. If no one against my suggestion, I would like to do some thing more on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1656) Memory Leaks due to XML Parser not being closed
[
https://issues.apache.org/jira/browse/TUSCANY-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1656:
Priority: Minor (was: Major)
Changing priority to minor as a short term fix has been provided.
Memory Leaks due to XML Parser not being closed
---
Key: TUSCANY-1656
URL: https://issues.apache.org/jira/browse/TUSCANY-1656
Project: Tuscany
Issue Type: Bug
Reporter: Lou Amodeo
Assignee: Raymond Feng
Priority: Minor
Fix For: Java-SCA-Next
I am seeing memory leaks that appear to be a result of the StAX reader not
being explictly closed.Adding an explicit close to the reader in this
instance
eliminated my problem. Also concerned that there are other cases within the
databinding framework.
package org.apache.tuscany.sca.databinding.axiom;
import org.apache.axiom.om.OMElement;
import org.apache.tuscany.sca.databinding.impl.SimpleType2JavaTransformer;
/**
* Transformer to convert data from a simple java bject to OMElement
*/
public class OMElement2Object extends SimpleType2JavaTransformerOMElement {
@Override
protected String getText(OMElement source) {
String aText = source.getText();
try
{
source.getXMLStreamReader().close();
}
catch (Exception ex)
{}
return aText;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1356) Clean up binding-echo and implementation-crud samples
[ https://issues.apache.org/jira/browse/TUSCANY-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1356: Doing this will be an improvement but I don't think that it's a major issue, changing the priority to minor. Clean up binding-echo and implementation-crud samples - Key: TUSCANY-1356 URL: https://issues.apache.org/jira/browse/TUSCANY-1356 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windows XP Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next Attachments: jira1356.diff, jira1356.svnst, jira1356.zip There is duplicate and confusing code in binding-echo and binding-echo-extension, and also in implementation-crud and implementation-crud-extension. See http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg18926.html for more details of the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1162) Contribution Services - Enhance contribution repository
[ https://issues.apache.org/jira/browse/TUSCANY-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1162: Priority: Minor (was: Major) Contribution Services - Enhance contribution repository --- Key: TUSCANY-1162 URL: https://issues.apache.org/jira/browse/TUSCANY-1162 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-M2 Reporter: Luciano Resende Assignee: Luciano Resende Priority: Minor Fix For: Java-SCA-Next - Enhance and extend contribution repository - add contribute application (like launcher) - allow long lived contributions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-545) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename.
[ https://issues.apache.org/jira/browse/TUSCANY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-545: --- Priority: Minor (was: Major) WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. Key: TUSCANY-545 URL: https://issues.apache.org/jira/browse/TUSCANY-545 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-M2 Reporter: Ron Gavlin Priority: Minor Fix For: Java-SCA-Next WSDL2Java should support a URI wsdlname command-line parameter. It currently treats the wsdlname parm as a filename. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1398) Nested Callbacks Fail
[ https://issues.apache.org/jira/browse/TUSCANY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526989 ] Jean-Sebastien Delfino commented on TUSCANY-1398: - Could you please try your test case again? I think this is now fixed. Thanks. Nested Callbacks Fail - Key: TUSCANY-1398 URL: https://issues.apache.org/jira/browse/TUSCANY-1398 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.90, Java-SCA-Next Reporter: York (He Yuan) HUANG Fix For: Java-SCA-Next Attachments: non-block-orderprocess.zip I created a simple SCA application, which involves an order process. The application was attached. Below is the composite file of the application. Note that, the callback method of Supplier will invoke the callback interface of Customer. Thus, there are nested callbacks. ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://orderprocess; xmlns:cb=http://orderprocess; name=orderprocess component name=Customer implementation.java class=orderprocess.CustomerImpl/ reference name=supplier target=Supplier/Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /reference /component component name=Supplier service name=Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /service implementation.java class=orderprocess.SupplierImpl/ reference name=railway target=RailwayTransport/Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference reference name=highway target=HighwayTransport interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference /component component name=HighwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.HighwayTransport/ property name=period5000/property /component component name=RailwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.RaiwayTransport/ property name=period1000/property /component /composite However, the application fails on both SCA Java 0.90 and trunk. Below is the error message. When I debugged the application, I found that it might be caused by wrong from info in ThreadMessageContext. java.lang.NullPointerException at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:77) at $Proxy11.notify(Unknown Source) at orderprocess.SupplierImpl.notify(SupplierImpl.java:70) 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.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:85) at $Proxy13.notify(Unknown Source) at orderprocess.RaiwayTransport.doShipping(RaiwayTransport.java:56) 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.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112
[jira] Resolved: (TUSCANY-1398) Nested Callbacks Fail
[ https://issues.apache.org/jira/browse/TUSCANY-1398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1398. - Resolution: Fixed Nested Callbacks Fail - Key: TUSCANY-1398 URL: https://issues.apache.org/jira/browse/TUSCANY-1398 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-0.90, Java-SCA-Next Reporter: York (He Yuan) HUANG Fix For: Java-SCA-Next Attachments: non-block-orderprocess.zip I created a simple SCA application, which involves an order process. The application was attached. Below is the composite file of the application. Note that, the callback method of Supplier will invoke the callback interface of Customer. Thus, there are nested callbacks. ?xml version=1.0 encoding=UTF-8? composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://orderprocess; xmlns:cb=http://orderprocess; name=orderprocess component name=Customer implementation.java class=orderprocess.CustomerImpl/ reference name=supplier target=Supplier/Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /reference /component component name=Supplier service name=Order interface.java interface=orderprocess.Order callbackInterface=orderprocess.OrderNotification/ /service implementation.java class=orderprocess.SupplierImpl/ reference name=railway target=RailwayTransport/Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference reference name=highway target=HighwayTransport interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /reference /component component name=HighwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.HighwayTransport/ property name=period5000/property /component component name=RailwayTransport service name=Shipment interface.java interface=orderprocess.Shipment callbackInterface=orderprocess.ShipmentNotification/ /service implementation.java class=orderprocess.RaiwayTransport/ property name=period1000/property /component /composite However, the application fails on both SCA Java 0.90 and trunk. Below is the error message. When I debugged the application, I found that it might be caused by wrong from info in ThreadMessageContext. java.lang.NullPointerException at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:77) at $Proxy11.notify(Unknown Source) at orderprocess.SupplierImpl.notify(SupplierImpl.java:70) 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.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134) at org.apache.tuscany.sca.implementation.java.invocation.TargetInvokerInvoker.invoke(TargetInvokerInvoker.java:46) at org.apache.tuscany.sca.core.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:84) at org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:85) at $Proxy13.notify(Unknown Source) at orderprocess.RaiwayTransport.doShipping(RaiwayTransport.java:56) 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.JavaTargetInvoker.invokeTarget(JavaTargetInvoker.java:112) at org.apache.tuscany.sca.implementation.java.invocation.JavaTargetInvoker.invoke(JavaTargetInvoker.java:134)RuntimeException invoking receiveResult
Re: Including the XQuery sample in the next release?
Vasil Vasilev wrote: Hi, Some thoughts about the example simplification - really it would be good to simplify the sample, but the client+server scenario should remain as JUnit test I think. +1 to keep the client/server scenario, I'd suggest to create an itest module for it, something like itest/implementation-xquery. You can see below some problems I currently have exactly with this scenario. I started looking at the following issues: 1. sharing common Configuration object 2. Being able to directly implement a WSDL interface Unfortunately I was not able to execute the sample JUnit test after I checked out the latest sources. The problem occurs when executing the scenario in which the XQuery component is a remote one and is exposed as Web Service. When I investigated the problem it appeared that the targetOperation of the DataTransformationInteceptor on the server side (i.e. the one that is called by Axis2ServiceProvider.invokeTarget) has input type with SDO data bindings of the input parameters, while I should have had Saxon type data binding. Not sure... Raymond, any idea? could this be caused by a recent change to the DataBinding framework? In the contrary if I look at the contract variable of the Axis2ServiceProvider - the databinding of the input parameters of the operation are correct. Is there something done recently in this direction, which could have led to the problem? -- One more note: Currently it will be possible (I will verify it after i have finished with the implementation :) ) for an XQuery component to implement a WSDL interface, bt it will not be possible to call a reference which has WSDL interface. At least i do not see how, because Saxon wants a java interface, which to be called. Can we think of some workaround? How about asking on the saxon-help mailing list? Bye, Vasil -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
Jean-Sebastien Delfino wrote: Vasil Vasilev wrote: Hi, Isn't in the official repository some older version of Saxon. May be we could try to run the prototype with this older version. Bye, Vasil If the Saxon project really doesn't want to publish newer JARs then I guess we're going to have to use the 8.7 version already on ibiblio.org. In the longer term, this also gives us a good opportunity to think about making XQuery processor implementations pluggable, as you already suggested :) Hi Vasil, Did you manage to backport and run the XQuery implementation code on Saxon 8.7? or are there any issues with 8.7 and we should try to see what we can do to get 8.9 published in a Maven repos? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resetting state of service references at conversation end
I'm overall +1 with this proposal, with some minor changes described in
comments inline.
Raymond Feng wrote:
Hi,
As we agreed, the conversation id alone is not sufficient to deal with
conversations. We need to maintain the state of the conversations
(STARTED, ENDED or EXPIRED).
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it has ended.
I propose that we do the following:
1) Define a ConversationManager like:
public interface ConversationManager() {
String start(String conversationID); // If the conversationID is
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.
Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.
Also I think it's better to return the Conversation object (see below
for its contents).
void end(String conversationID); // Ends the conversation
void endConversation(Conversation conversation)
Don't you need another method to make a conversation expire?
ConversationState getConversationState(String conversationID); //
Get the state of the conversation
Conversation getConversation(Object conversationID)
void register(ConversationListener listener); // Register a listener
void unregister(ConversationListener listener); // Remove a listener
Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)
Also, these methods should be on the Conversation object described below
I think.
}
public interface ConversationListener() {
void conversationStarted(String conversationID);
void conversationEnded(String conversationID);
void conversationExpired(String conversationID);
}
Pass Conversation conversation instead of String conversationID.
If the methods are on the Conversation object instead of the
ConversationManager they can be simpler I think:
public interface ConversationListener() {
void conversationStarted();
void conversationEnded();
void conversationExpired();
}
public enum ConversationState {
STARTED, ENDED, EXPIRED
}
class Conversation {
ConversationState state;
Object conversationID;
}
Having this class allows you to evolve it over time, does not rely on
the fact that conversations are stored in a map, and also IMO better
represents what you'll store in persistent storage in the future.
Do we we need an expiry time field here as well?
2) The proxy or callable references will only keep the conversation
ID. Whenever the Conversation object is referenced or we need to
perform any actions to a conversation, we use the ID to look up the
state of the conversation.
3) Move the expiration timer from the ConversationScopeContainer to
the ConversationManager.
If different Conversations can have different expiration timers then the
timer needs to be on the Conversation object instead of the
ConversationManager.
4) The ConversationScopeContainer will be registered as listener to
the ConversationManager. When an active conversation is started,
expired or ended, the ConversationScopeContainer will be notified.
It might be easier to register the actual instance wrapper wrappering
the component instance associated with a particular conversation.
5) The ConversationManager maintains the conversations using an
in-memory Map as the first step. In the future, it can be extended to
backed by a persistent store.
+1 to use an in-memory map for now.
Thanks,
Raymond
- Original Message - From: Simon Laws
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end
Hi Raymond
some comments below...
Simon
On 9/9/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I have been thinking of this problem as well. It's not realistic to
search
for all CallableReferences because it can be dynamically created
too. We
Agreed. You would have to have registered them somewhere first. This
is what
happens in the case of the conversation scope container currently.
probably need to use a listener pattern to have all the Conversation
objects
listen on the events of expiration or end of the conversation and reset
the
state based on the event. Another way is to have a pointer to the
This would rely on having the conversation object register with
something
that is able to broadcast these events. Where would be a sensible
place to
put this event broadcasting function. Do we have an internal eventing
feature? Scope container?
ScopeContainer in the ConversationImpl object and query the state of the
conversation before
Re: IntentAttachPoint
Greg Dritschler wrote: I have a question about changes that were made in revision 566649. This revision changed the assembly model object interfaces so that they don't extend IntentAttachPoint. The assembly model implementations now extend IntentAttachPoint. As a consequence any code that wants to reference the intents needs to check if the implementation object is an instance of IntentAttachPoint and then cast it. Why was this done? I'm not saying it's right or wrong, I just want to know the point of the change. It seems to allow assembly model objects (implementations, bindings) to be created which don't support intents. Is that a good thing? Greg I think it's a good thing :) The idea is as follows: - Some bindings and implementation types will not support policies. For example only some binding types will support confidentiality, only some implementation types will support transactions. The policy framework spec defines how to describe binding types and implementation types and the policies that can be applied to them in definitions.xml. It's easy to imagine that some binding or implementation types will not support any policy. - We can make the development of binding or implementation extensions which don't support any policy simpler by not requiring them to implement IntentAttachPoint and PolicySetAttachPoint. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resetting state of service references at conversation end
More comments inline.
[snip]
Simon Laws wrote:
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it has ended.
I would go further than this to say, if we follow the words of the spec, we
should keep the state of a conversation in a central place in a domain. At
least in the very specific cases where there is a 3rd party involved in the
conversation. However a sentral place in a node is a good place to start.
+1, a central place in a node is a good place to start :)
I propose that we do the following:
1) Define a ConversationManager like:
public interface ConversationManager() {
String start(String conversationID); // If the conversationID is
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.
Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.
Also I think it's better to return the Conversation object (see below
for its contents).
Why don't we register a Conversation object with a ConversationManager and
do away with getConversationState
+1
I think it's what I'm proposing. However I think we should distinguish
org.osoa.sca.Conversation (the API, for Java clients and component
implementations) and org.apache.tuscany.whatever.Conversation (the SPI
Conversation object I'm talking about here).
void end(String conversationID); // Ends the conversation
void endConversation(Conversation conversation)
Don't you need another method to make a conversation expire?
ConversationState getConversationState(String conversationID); //
Get the state of the conversation
Conversation getConversation(Object conversationID)
+1
[snip]
4) The ConversationScopeContainer will be registered as listener to
the ConversationManager. When an active conversation is started,
expired or ended, the ConversationScopeContainer will be notified.
It might be easier to register the actual instance wrapper wrappering
the component instance associated with a particular conversation.
An instance wrapped could be registered as a listener with multiple
conversations.
Exactly, an instance wrapper will be registered with the conversation
associated with an incoming call, plus the conversations that were
started by any outgoing calls through conversational interfaces. So
you'll register a wrapper with all the conversations that it
participates in. So we have two choices:
- register with the conversation an object carrying (the instance
wrapper + the conversation itself) and then we don't need to pass the
conversation in the listener methods
- or just register the instance wrapper and then the listener methods
needs to pass the conversation object.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: JIRA-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?
kelvin goodson wrote: Luciano, can you confirm in the JIRA whether the updated fix is good? I'll keep an eye on this thread to see how your plans develop, and what that might mean for SDO release plans. Kelvin. On 10/09/2007, Luciano Resende [EMAIL PROTECTED] wrote: We have found an issue on the SDO Tools, described in JIRA-1673 [1] that is affecting the proper generation of java interfaces from a given wsdl. What's the plan to get this fix, when available, in SCA 1.0 release ? This might require a new SDO release ? [1] http://issues.apache.org/jira/browse/TUSCANY-1673 I have checked in a workaround for this problem under revision r574423. We should leverage the SDO fix as soon as it's in an SDO release, but the workaround in place in r574423 will allow a Tuscany SCA 1.0 release to work with the published SDO 1.0 release. I can't comment on the SDO fix as I've just looked into the workaround, but Luciano probably can. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resetting state of service references at conversation end
Raymond Feng wrote:
OK. I'll add the interfaces first for review. Should they go to the
core-spi?
Thanks,
Raymond
Only the interfaces actually used by binding and implementation
extensions should go to core-spi. If not needed by extensions they
should go to core.
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service references at conversation end
I'm overall +1 with this proposal, with some minor changes described
in comments inline.
Raymond Feng wrote:
Hi,
As we agreed, the conversation id alone is not sufficient to deal
with conversations. We need to maintain the state of the
conversations (STARTED, ENDED or EXPIRED).
Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and
the other conversation participants to see that it has ended.
I propose that we do the following:
1) Define a ConversationManager like:
public interface ConversationManager() {
String start(String conversationID); // If the conversationID is
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.
Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.
Also I think it's better to return the Conversation object (see below
for its contents).
void end(String conversationID); // Ends the conversation
void endConversation(Conversation conversation)
Don't you need another method to make a conversation expire?
ConversationState getConversationState(String conversationID); //
Get the state of the conversation
Conversation getConversation(Object conversationID)
void register(ConversationListener listener); // Register a listener
void unregister(ConversationListener listener); // Remove a listener
Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)
Also, these methods should be on the Conversation object described
below I think.
}
public interface ConversationListener() {
void conversationStarted(String conversationID);
void conversationEnded(String conversationID);
void conversationExpired(String conversationID);
}
Pass Conversation conversation instead of String conversationID.
If the methods are on the Conversation object instead of the
ConversationManager they can be simpler I think:
public interface ConversationListener() {
void conversationStarted();
void conversationEnded();
void conversationExpired();
}
public enum ConversationState {
STARTED, ENDED, EXPIRED
}
class Conversation {
ConversationState state;
Object conversationID;
}
Having this class allows you to evolve it over time, does not rely on
the fact that conversations are stored in a map, and also IMO better
represents what you'll store in persistent storage in the future.
Do we we need an expiry time field here as well?
2) The proxy or callable references will only keep the conversation
ID. Whenever the Conversation object is referenced or we need to
perform any actions to a conversation, we use the ID to look up the
state of the conversation.
3) Move the expiration timer from the ConversationScopeContainer to
the ConversationManager.
If different Conversations can have different expiration timers then
the timer needs to be on the Conversation object instead of the
ConversationManager.
4) The ConversationScopeContainer will be registered as listener to
the ConversationManager. When an active conversation is started,
expired or ended, the ConversationScopeContainer will be notified.
It might be easier to register the actual instance wrapper wrappering
the component instance associated with a particular conversation.
5) The ConversationManager maintains the conversations using an
in-memory Map as the first step. In the future, it can be extended
to backed by a persistent store.
+1 to use an in-memory map for now.
Thanks,
Raymond
- Original Message - From: Simon Laws
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end
Hi Raymond
some comments below...
Simon
On 9/9/07, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I have been thinking of this problem as well. It's not realistic
to search
for all CallableReferences because it can be dynamically created
too. We
Agreed. You would have to have registered them somewhere first.
This is what
happens in the case of the conversation scope container currently.
probably need to use a listener pattern to have all the
Conversation
Re: Including the SCA spec XSDs in the Tuscany distribution?
ant elder wrote: On 9/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: This has come up several times but I've not seen any conclusion. Here are the relevant JIRAs: http://issues.apache.org/jira/browse/TUSCANY-181 http://issues.apache.org/jira/browse/TUSCANY-678 http://issues.apache.org/jira/browse/TUSCANY-1389 To resolve these JIRAs I think we should include the SCA XSDs [1] in the Tuscany distribution. Is there any issue with the SCA license [2] preventing us to include the XSDs? Is the license going to change now that SCA is being standardized at OASIS? Thoughts? [1] http://www.osoa.org/xmlns/sca/1.0/ [2] http://www.osoa.org/xmlns/sca/1.0/license.txt -- Jean-Sebastien I think it should be fine to include them as we already include some other things which also use that OSOA license in previous SCA and SDO releases. It would be interesting to know if the license will be changed to something more standard with the move to OASIS. ...ant OK, if there's no objection, I'll go ahead and include the XSDs. This will allow us to do a number of interesting things: - Validate SCA assembly XML when loading .composite, .componentType, .constrainingType, improving our error reporting story. I'll try to see how we can just leverage Validating StAX XMLStreamReaders for that. - Document how to register the XSDs in an IDE like Eclipse and get validation there too, again improving the error reporting story. We may even be able to provide a simple plugin.xml file that you can drop in your IDE and does the XSD registration for you. - Define XSDs for our various implementation and binding extensions, extending the core SCA XSDs. I think it is important to help document them. More on this in the next 2 days if I find a little bit of time to work on it... -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Improving Store sample to describe client JSON and Atom references
I checked in a version of the Store sample described in the Getting Started document a while ago. I'd like to describe a few thoughts on how to improve the sample with small changes to the sample itself and some improvements to the implementation.resource extension and how it integrates with Web 2.0-friendly bindings. The current Store sample looks like this: store.composite compositexmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:s=http://store; name=store component name=ufs t:implementation.resource location=ufservices/ service name=Resource t:binding.http/ /service /component component name=Catalog implementation.java class=services.CatalogImpl/ property name=currencyCodeUSD/property service name=Catalog t:binding.jsonrpc/ /service reference name=currencyConverter target=CurrencyConverter/ /component component name=ShoppingCart implementation.java class=services.ShoppingCartImpl/ service name=Collection t:binding.atom/ /service /component component name=CurrencyConverter implementation.java class=services.CurrencyConverterImpl/ /component /composite store.html html head titleStore/title script type=text/javascript src=binding-atom.js/script script type=text/javascript src=binding-jsonrpc.js/script script language=JavaScript //Reference catalog = (new JSONRpcClient(../Catalog/)).Catalog; //Reference shoppingCart = new AtomClient(../ShoppingCart/); We can see that the Catalog and ShoppingCart services offered to the Store client are properly modeled and configured with binding.jsonrpc and binding.atom. However the Composite does not describe any references on the UFS component. When you look at the composite you don't see that the client Javascript code in store.html actually references the Catalog and ShoppingCart services, and proxies to these services are constructed by hand in the client Javascript code. I think it would be better if we could write something like follows: store.composite compositexmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:s=http://store; name=store component name=ufs !-- Point directly to the HTML page -- t:implementation.resource location=store.html/ service name=Resource t:binding.http/ /service !-- Describe references to the target services -- reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart t:binding.atom/ /reference /component component name=Catalog implementation.java class=services.CatalogImpl/ property name=currencyCodeUSD/property service name=Catalog t:binding.jsonrpc/ /service reference name=currencyConverter target=CurrencyConverter/ /component component name=ShoppingCart implementation.java class=services.ShoppingCartImpl/ service name=Collection t:binding.atom/ /service /component component name=CurrencyConverter implementation.java class=services.CurrencyConverterImpl/ /component /composite store.html html head titleStore/title !-- include a single script, covering multiple bindings -- script type=text/javascript src=sca.js/script script language=JavaScript !-- Simplified creation of the client proxies -- catalog = Reference(catalog); shoppingCart = Reference(shoppingCart); This introduces the following changes: In store.composite - The implementation.resource element directly points to store.html, so when you look at the .composite you know what HTML page is actually used. - The ufs component now declares correct references and wiring to other service components in the assembly. In store.html - A single sca.js script is generated for the client to include, very much like the generated scaDomain.js file, but covering multiple bindings, and customized for this particular UFS component and the references that were declared on it. - The client code is simpler, you can do catalog = Reference(catalog) or you could do something like catalog = references.catalog (where references.catalog would be initialized in sca.js), but I think I prefer the first form as it allows me to pick the name of the variable I'm going to use and Reference(catalog) also allows execution of some initialization code when the proxy is initialized. These changes should be possible with minimum effort but I think they will improve the sample a lot. Thoughts? -- Jean-Sebastien
How to create composite diagrams for the samples
I'd like to understand how to create composite diagrams similar to the ones Simon already created for most samples. Do we have a quick summary of the steps to do this? Is there a set of predefined shapes uploaded somewhere that we all can use for these diagrams? Should I use a tool like inkscape to create the diagrams? Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Improving Store sample to describe client JSON and Atom references
Simon Laws wrote: On 9/11/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I checked in a version of the Store sample described in the Getting Started document a while ago. I'd like to describe a few thoughts on how to improve the sample with small changes to the sample itself and some improvements to the implementation.resource extension and how it integrates with Web 2.0-friendly bindings. The current Store sample looks like this: store.composite compositexmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:s=http://store; name=store component name=ufs t:implementation.resource location=ufservices/ service name=Resource t:binding.http/ /service /component component name=Catalog implementation.java class=services.CatalogImpl/ property name=currencyCodeUSD/property service name=Catalog t:binding.jsonrpc/ /service reference name=currencyConverter target=CurrencyConverter/ /component component name=ShoppingCart implementation.java class=services.ShoppingCartImpl/ service name=Collection t:binding.atom/ /service /component component name=CurrencyConverter implementation.java class=services.CurrencyConverterImpl/ /component /composite store.html html head titleStore/title script type=text/javascript src=binding-atom.js/script script type=text/javascript src=binding-jsonrpc.js/script script language=JavaScript //Reference catalog = (new JSONRpcClient(../Catalog/)).Catalog; //Reference shoppingCart = new AtomClient(../ShoppingCart/); We can see that the Catalog and ShoppingCart services offered to the Store client are properly modeled and configured with binding.jsonrpc and binding.atom. However the Composite does not describe any references on the UFS component. When you look at the composite you don't see that the client Javascript code in store.html actually references the Catalog and ShoppingCart services, and proxies to these services are constructed by hand in the client Javascript code. I think it would be better if we could write something like follows: store.composite compositexmlns=http://www.osoa.org/xmlns/sca/1.0; xmlns:t=http://tuscany.apache.org/xmlns/sca/1.0; xmlns:s=http://store; name=store component name=ufs !-- Point directly to the HTML page -- t:implementation.resource location=store.html/ service name=Resource t:binding.http/ /service !-- Describe references to the target services -- reference name=catalog target=Catalog t:binding.jsonrpc/ /reference reference name=shoppingCart target=ShoppingCart t:binding.atom/ /reference /component component name=Catalog implementation.java class=services.CatalogImpl/ property name=currencyCodeUSD/property service name=Catalog t:binding.jsonrpc/ /service reference name=currencyConverter target=CurrencyConverter/ /component component name=ShoppingCart implementation.java class=services.ShoppingCartImpl/ service name=Collection t:binding.atom/ /service /component component name=CurrencyConverter implementation.java class=services.CurrencyConverterImpl/ /component /composite store.html html head titleStore/title !-- include a single script, covering multiple bindings -- script type=text/javascript src=sca.js/script script language=JavaScript !-- Simplified creation of the client proxies -- catalog = Reference(catalog); shoppingCart = Reference(shoppingCart); This introduces the following changes: In store.composite - The implementation.resource element directly points to store.html, so when you look at the .composite you know what HTML page is actually used. - The ufs component now declares correct references and wiring to other service components in the assembly. In store.html - A single sca.js script is generated for the client to include, very much like the generated scaDomain.js file, but covering multiple bindings, and customized for this particular UFS component and the references that were declared on it. - The client code is simpler, you can do catalog = Reference(catalog) or you could do something like catalog = references.catalog (where references.catalog would be initialized in sca.js), but I think I prefer the first form as it allows me to pick the name of the variable I'm going to use and Reference(catalog) also allows execution of some initialization code when the proxy is initialized. These changes should be possible with minimum effort but I think they will improve the sample a lot. Thoughts? -- Jean-Sebastien
Re: Domain changes
Simon Laws wrote: There are some reorganized domain/node classes under modules/distributed and modules/distributed-impl dirs. Here the SCADomain is replaced by a Node. A node runs all or part of a domain. A Node has contributions added and removed and has components started/stoppped etc. If available (a domain and node name are provided and the domain is running) a Node registers with a DomainManager service and a ServiceDiscovery service. Here's what's in the new code Node - A node implementation (NodeImpl) - A contributions manager for adding/removing contributions - A component manager - A management SCA application that provides access to these features remotely - a web page for looking at the node Domain - A ServiceDiscovery service - A domain manager service - A sample domain application that pulls two together and includes - A web page for looking at the domain and provides links to each nodes web page. This looks pretty good to me! So far I've looked at the interfaces and the implementation, and will try the web pages next :) I'd like to make a proposal to change ServiceDiscovery a bit, but I'll do that in a separate email. You can try this by running the calculator distributed sample. This runs and exercises some distributed nodes as it always has but uses the new classes now. If you run the nodes independently from the command line they stay around long enough for you to point a browser at them. Try htpp://localhost:8080/node/index.html (or whatever port the node has come up on) and see the components in a node. There is a new sample (sample-domain-webapp). The intention here is to provide a generic domain and a node so you can start the domain and node and then add contributions. Not complete yet as the add contribution function needs turning into a remote service but you can use the domain implementation along with nodes from the distributed calculator sample which have hard coded contributions. Here are some todos I've copied all of the interfaces I need to make this work into modules/distributed so there is code/interfaces here that is also elsewhere, for example, the component manager classes. I would like to move the new code to new modules modules/host-node - for the node related code? modules/host-domain - for the domain related code? How about this? modules/node modules/domain IMO host-* is for the integration with hosting environments like Tomcat, Jetty, an HTTP or RMI server. And host-embedded should probably not be called host-embedded :) I have used the interfaces Node and Domain currently should this be SCANode and SCADomain? I'm OK with both, not sure what others prefer. host-embedded can stay as it provides the runtime and embedded support but there are numerous domain implementations that we can remove assuming we get to the stage where we are comfortable with Node. Ant has already ported the hot update web app to use the new domain (currently working through an issue with uris) I'd like to start using the Node implementation in the samples. I'll have a go at converting some and see how it goes. Great! I'd suggest to move the API methods (expected to be used in application business logic) like getService(), getServiceReference() and cast() to a separate interface in a separate domain-api or node-api module. Simon -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Build error with WSSecurityConfidentialityTestCase
Is anybody else seeing that build error? Do I need to set up anything new in my build environment now that we have WS-security enabled (which is pretty cool BTW)? Running org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase log4j:WARN No appenders could be found for logger (org.apache.axiom.om.util.StAXUtils). log4j:WARN Please initialize the log4j system properly. Sep 11, 2007 7:04:02 PM org.apache.tuscany.sca.http.jetty.JettyServer addServletMapping INFO: Added Servlet mapping: http://localhost:8085/myExplicitURI *** Calling Integrity Password Handler Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.096 sec FAILURE! testHelloWorld(org.apache.tuscany.sca.binding.ws.axis2.itests.policy.WSSecurityConfidentialityTestCase) Time elapsed: 3.04 sec ERROR! java.lang.ExceptionInInitializerError at java.lang.J9VMInternals.initialize(J9VMInternals.java:214) at javax.crypto.KeyGenerator.a(Unknown Source) at javax.crypto.KeyGenerator.init(Unknown Source) at javax.crypto.KeyGenerator.getInstance(Unknown Source) at org.apache.ws.security.message.WSSecEncrypt.getKeyGenerator(WSSecEncrypt.java:578) at org.apache.ws.security.message.WSSecEncrypt.prepare(WSSecEncrypt.java:202) at org.apache.ws.security.message.WSSecEncrypt.build(WSSecEncrypt.java:268) at org.apache.ws.security.action.EncryptionAction.execute(EncryptionAction.java:62) at org.apache.ws.security.handler.WSHandler.doSenderAction(WSHandler.java:192) at org.apache.rampart.handler.WSDoAllSender.processBasic(WSDoAllSender.java:256) at org.apache.rampart.handler.WSDoAllSender.processMessage(WSDoAllSender.java:88) at org.apache.rampart.handler.WSDoAllHandler.invoke(WSDoAllHandler.java:72) at org.apache.axis2.engine.Phase.invoke(Phase.java:383) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:203) at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:433) at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:330) at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:294) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invokeTarget(Axis2BindingInvoker.java:95) at org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingInvoker.invoke(Axis2BindingInvoker.java:75) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInteceptor.invoke(DataTransformationInteceptor.java:70) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.HelloWorldOMComponent.getGreetings(HelloWorldOMComponent.java:31) 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:105) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInteceptor.invoke(PassByValueInteceptor.java:49) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:231) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:128) at $Proxy2.getGreetings(Unknown Source) at org.apache.tuscany.sca.binding.ws.axis2.itests.policy.AbstractHelloWorldOMTestCase.testHelloWorld(AbstractHelloWorldOMTestCase.java:43) 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 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
Re: Issue with dynamic creation of NotificationReferenceBindingProvider
Ignacio Silva-Lepe wrote: The thread has gone quiet and I am not sure we have reached a conclusion. In summary, binding-notification relies on both the activation and start phases to occur early for the reference binding provider, that is, at the same time as for the service binding provider. So, are we ok with making dynamic activation of references optional as proposed earlier, or is there another proposal? Ideally, we should be able to fix this in time to be included in the 1.0 release. Thanks I am proposing to have early activation of references in all cases, will will solve your issue, but Raymond listed a number of cases where reference activation is dynamic. I am not sure that the scenarios he has listed apply to the notification binding, but I'll post my questions or concerns with dynamic activation in a response to his email. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release management for 1.0 release, was: Release management for next release, was: SCA 0.92 release?
Ant has been doing a great job as Release Manager for several releases. I'd like to nominate him as Release Manager for release 1.0, as it's going to be a pretty important milestone release for the project, and I'm sure he'll make it a successful release again! Thoughts? [snip] ant elder wrote: Taking the branch on the 14th and making an RC1 on the 14th is possible, just the RC is likely to be a little rough as there won't be much time at all to do checking. But as we're talking about RC1 not expected to be _the_ RC then i guess that could be fine. ...ant -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Comments inline.
[snip]
Simon Nash wrote:
I agree that we need a conclusion. I believe the detailed proposal below
supports all the SCA semantics and I'd like to propose that we go with it
for Tuscany 1.0.
Any comments, questions, agreement, or disagreement?
Simon
I was initially thinking that the Callback EPR should be a separate
header outside of the To EPR but the code snippet that you put together
to simulate the SCA built-in callback (at the bottom of that email)
convinced me that I was wrong about it :)
So I'm +1 with your proposal in [1]:
Request message
wsa:To
wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=...
wsa:Address...URI of the service being invoked.../wsa:Address
wsa:ReferenceParameters
tuscany:CallbackIDcallback-A01/tuscany:CallbackID
tuscany:ConversationIDconversation-006/tuscany:ConversationID
tuscany:CallbackReference
wsa:EndpointReference
wsa:Address...URI of the service for the
callback.../wsa:Address
wsa:EndpointReference
/tuscany:CallbackReference
/wsa:ReferenceParameters
/wsa:EndpointReference
/wsa:To
Callback message:
wsa:To
wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=...
wsa:Address...URI of the service for the callback.../wsa:Address
wsa:ReferenceParameters
tuscany:CallbackIDcallback-A01/tuscany:CallbackID
tuscany:ConversationIDconversation-006/tuscany:ConversationID
/wsa:ReferenceParameters
/wsa:EndpointReference
/wsa:To
In plain text:
- CallbackID flows as a reference parameter of the To EPR
- ConversationID flows as a reference parameter of the To EPR
- CallbackReference is a well formed EPR and flows as a reference
parameter of the To EPR
I think that we should propose this mapping to the OASIS SCA Bindings
workgroup. Different implementations of SCA should follow the same
mapping if we want them to interoperate over Web Services for example.
[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html
[snip]
Yes, I'm proposing what I said in [1] with a
tuscany:CallbackReference
reference parameter under the wsa:To stateful EPR. Looking at this
again,
it could be slightly improved to eliminate the wsa:EndpointReference
and wsa:Address within tuscany:CallbackReference, giving:
wsa:To
wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=...
wsa:Address...URI of the service being invoked.../wsa:Address
wsa:ReferenceParameters
tuscany:CallbackIDcallback-A01/tuscany:CallbackID
tuscany:ConversationIDconversation-006/tuscany:ConversationID
tuscany:CallbackReference
...URI of the service for the callback...
/tuscany:CallbackReference
/wsa:ReferenceParameters
/wsa:EndpointReference
/wsa:To
This requires the tuscany:CallbackReference to be fluffed up into
a wsa:Towsa:EndpointReference when the callback is sent, with the
tuscany:CallbackID and tuscany:ConversationID as its reference
parameters:
wsa:To
wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=...
wsa:Address...URI of the service for the
callback.../wsa:Address
wsa:ReferenceParameters
tuscany:CallbackIDcallback-A01/tuscany:CallbackID
tuscany:ConversationIDconversation-006/tuscany:ConversationID
/wsa:ReferenceParameters
/wsa:EndpointReference
/wsa:To
Simon
I'm not keen on doing that. I'd prefer to stick to your initial proposal
which seems cleaner to me, using the same standard form to represent the
CallbackReference EPR in the request message and the To EPR in the
callback message.
@Service(Client.class)
class Client {
ComponentContext componentContext;
Writer writer;
write(inputData) {
target = componentContext.getServiceReference(Writer.class,
writer);
self = componentContext.createSelfReference();
id = new UUID();
target.setCallbackID(id);
self.setCallbackID(id);
target.setCallback(self);
target.getService().asyncWrite(target, inputData);
}
written(myReference) {
// data myReference.getCallbackID() has been written
}
}
@Service(Writer.class)
class Writer {
@OneWay
asyncWrite(myReference, inputData) {
// actually write the data
clientReference = myReference.getCallback();
clientReference.getService().written(clientReference);
}
}
I'd suggest a small variation of this pseudo-code, to be more in line
with the protocol that you proposed (the callbackID doesn't flow in the
CallbackReference in the request message):
@Service(Client.class)
class Client {
ComponentContext componentContext;
Writer writer;
write(inputData) {
target = componentContext.getServiceReference(Writer.class,
writer);
self = componentContext.createSelfReference();
id = new UUID();
target.setCallbackID(id);
target.setCallback(self);
target.getService().asyncWrite(target, inputData);
}
written(myReference) {
// data
Re: Issue with dynamic creation of NotificationReferenceBindingProvider
Comments inline. [snip] Raymond Feng wrote: What do you mean by a reference can be dynamically created? can you please describe the scenario you have in mind? There are a few cases: 1) SCADomain.getService() will create self reference 2) ComponentContext.createSelfReference() 3) ComponentContext.getService() (if the business interface is not the same as the reference) 4) Rebind a reference to a target OK I see now. So, we have two cases: (A) a reference is statically declared on a component == The binding provider(s) for the reference binding(s) should be started when the component is started. The actual sequence is: 1. the component is created 2. the reference is created 3. the reference is started 4. the component is started (B) a floating reference is created == The binding provider(s) for the reference binding(s) should be started just after the reference is created. 1. the reference is created 2. the reference is started Invocation chains can be created whenever we want (lazily on first invocation if we wish) as they have no lifecycle attached to them I think that this resolves the binding.notification issue (getting started early), while accommodating for dynamically created references, and without complicating the SPIs with another option. At this point and for our upcoming 1.0 release I'd like to apply the Ockam's Razor principle [1] to our SPIs and keep them as slim and simple as possible :) [1] http://en.wikipedia.org/wiki/Occam%27s_razor -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
[ https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1561: Attachment: 1561.patch 1561-java.diff I did an evaluation of the changes required to port to Axis2 1.3. 1561-java.diff is a diff of the java source code changes only, to help people review the changes. They are very minimal (mostly Java package renames, plus a few method signature changes). I marked the actual logic changes with a // JIRA TUSCANY-1561 comment. 1561.patch is the complete patch including changes to the Maven pom.xml files and the axis2.xml configuration file. The rampart mar (for the security policy support) also needs to be upgraded to from 1.2 to 1.3, as shown in 1561.patch. I am running into a few test errors with this patch so it would be great if people involved in the binding-ws-axis2 work could review it and help see what's wrong, as I may have missed something... Thanks. Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Fix For: Java-SCA-Next Attachments: 1561-java.diff, 1561.patch Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3
[ https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1561: Patch Info: [Patch Available] Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Based on the analysis I just did, showing that Java code changes to port to Axis2 are very minimal and can be clearly identified, I recommend to do this port for the 1.0 release. Move up from Axis2 1.2 to 1.3 - Key: TUSCANY-1561 URL: https://issues.apache.org/jira/browse/TUSCANY-1561 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension, Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.91 Reporter: ant elder Fix For: Java-SCA-1.0 Attachments: 1561-java.diff, 1561.patch Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
More thoughts at the bottom. Simon Nash wrote: Raymond Feng wrote: At this moment, the From of the Message is used for the reference of the source component. And if the interface is bidirectional, the From EPR will contain a callback EPR. The current code only sets From in the Message for a bidirectional interface. This means that outbound interceptors don't currently get any From endpoint information for calls across a unidirectional interface. What's going to happen if the user customize the callback object by calling ServiceReference.setCallback() with a ServiceReference? Should we replace the callback EPR under the From or carry it as part of the reference parameters of the To? In this case, the current code in JDKInvocationHandler replaces the From EPR with the custom ServiceReference. Again, this means that outbound interceptors don't have access to the From reference endpoint. So the value of holding the callback endpoint information somewhere other than the Message's From endpoint is that outbound interceptors can have access to the actual calling reference endpoint if they need it. Simon Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, September 07, 2007 4:09 PM Subject: Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?) Simon Nash wrote: Until now we have always held this information in the wsa:From element. However, in thinking about what is really going on here in WS-Addressing terms, I believe we should be putting it in the wsa:To element instead. The wsa:To element is mandatory for WS-Addressing, but we are not sending it currently. Here's how this would look: wsa:To wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...URI of the service being invoked.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID tuscany:CallbackReference wsa:EndpointReference wsa:Address...URI of the service for the callback.../wsa:Address wsa:EndpointReference /tuscany:CallbackReference /wsa:ReferenceParameters /wsa:EndpointReference /wsa:To (Note: I have capitalized the first letters of CallbackID, ConversationID and CallbackReference to match the WS-Addressing house style) This has a few advantages: 1. It makes us fully compliant with WS-Addressing. 2. WS-Addressing has the notion of a stateful endpoint reference, where the endpoint address is augmented with other information that represents a particular instance of the endpoint. This is exactly what is happening here. Invocations to the same SCA service that differ only in their conversation and callback information are very nicely modelled as different WS-Addressing endpoint references for the same endpoint address. 3. It allows the wsa:To infomation to be exactly the same as the information that would be serialized to represent the CallableReference for the invocation. This is a very neat solution to the question of how a CallableReference should be serialized. It might even give us a decent chance of being interoperable with some non-SCA environments. The callback message would be as follows: wsa:To wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...URI of the service for the callback.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /wsa:ReferenceParameters /wsa:EndpointReference /wsa:To Regarding the sca or tuscany namespace question, the code currently uses the sca namespace but it may be better to use tuscany until we get spec endorsement that this is the correct SCA-approved mapping for SCA conversations and callbacks to Web service protocols. This would be defined in the WS Binding specification. For comparison, this is what the current code does for forward calls, with the From address directly representing the callback endpoint: wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...The URI of the service for the callback.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /wsa:ReferenceParameters /wsa:EndpointReference /wsa:From Simon Raymond Feng wrote: Hi, I'm thinking of this syntax: wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm
Re: Base interface
Luciano Resende wrote:
I just changed the import and compiled the module with mvn clean
install, no erros... but i didn't do a full build... i can try that
later on...
It's weird...
Module interface, contains the following:
interface public interface Interface extends
org.apache.tuscany.sca.interfacedef.Base, Cloneable {
and does not depend on module assembly.
How will the following:
interface public interface Interface extends
org.apache.tuscany.sca.assembly.Base, Cloneable {
compile without adding a dependency on module assembly?
And if you add a dependency on module assembly won't that create a
circular dependency?
On 9/7/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Luciano Resende wrote:
Any particular reason for us to have two copies of Base ?
import org.apache.tuscany.sca.assembly.Base;
import org.apache.tuscany.sca.interfacedef.Base;
They seem identical, and making the change in interface-wsdl to use
the Base class from assembly seems to cause no harm and the module
seems to compile ok.
How are you changing the module dependencies for this to compile?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Including the SCA spec XSDs in the Tuscany distribution?
This has come up several times but I've not seen any conclusion. Here are the relevant JIRAs: http://issues.apache.org/jira/browse/TUSCANY-181 http://issues.apache.org/jira/browse/TUSCANY-678 http://issues.apache.org/jira/browse/TUSCANY-1389 To resolve these JIRAs I think we should include the SCA XSDs [1] in the Tuscany distribution. Is there any issue with the SCA license [2] preventing us to include the XSDs? Is the license going to change now that SCA is being standardized at OASIS? Thoughts? [1] http://www.osoa.org/xmlns/sca/1.0/ [2] http://www.osoa.org/xmlns/sca/1.0/license.txt -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SCA Specifications starting up in OASIS
Mike Edwards wrote: Folks, The SCA specifications which are implemented by Tuscany have just started out a new phase - they are moving to OASIS for formal standardization. This is being done as a series of OASIS technical committees, each dealing with one or more of the SCA specifications. The OASIS activities are carried out in public and it is possible to either observe activities in the various technical committees, or you are welcome to join one or more of the committees. You can find the 6 SCA technical committees here: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-assembly http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-policy http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-bindings http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-j http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-c-cpp http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=sca-bpel Meeting minutes, documents, issues and so on are linked from the main page. Mailing list archives can be found here: http://www.oasis-open.org/archives/sca-assembly/ http://www.oasis-open.org/archives/sca-policy/ http://www.oasis-open.org/archives/sca-bindings/ http://www.oasis-open.org/archives/sca-j/ http://www.oasis-open.org/archives/sca-c-cpp/ http://www.oasis-open.org/archives/sca-bpel/ Please note that there is an SCA Plenary session taking place on Tuesday 18th September in Palo Alto, CA. This session is an education session about SCA and the work that will take place within OASIS over the next year or so. This session is free and open to anyone who registers for the session. For more details, please look here: http://www.oasis-opencsa.org/2007-09-18-program Yours, Mike Edwards. Co-Chair, OASIS SCA Assembly TC. Great! Thanks Mike. What do people think about adding these links to a page on the Tuscany web site, linked from our Getting Involved page? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Avoiding unnecessary pass-by-value copies
ant elder wrote: No comments on this for a while so if no one shouts i'm going to do this to fix TUSCANY-1559. ...ant +1 from me to move the logic to enforce pass by value into a separate interceptor, out implementation-java-runtime. I think it should be in the core-databinding module. I didn't quite get Raymond's comment that we'll have to pass a flag in a message header. Don't we know what to do w.r.t pass by value just by looking at the source and target interfaces? Can't we just decide to either insert the interceptor in the invocation chain or not when the invocation chain is built? On 9/5/07, ant elder [EMAIL PROTECTED] wrote: Sure, thats just making the source and target interfaces use different databindings caused a databinding transformation explicit on the message. So if you want it explicit like that that sounds ok to me as well. Still seems like the pass-by-value code should be out of the Java implementation and part of the Tuscany core to me though so it works for all implementation types. ...ant On 9/5/07, Raymond Feng [EMAIL PROTECTED] wrote: We could fix this issue by allowing some headers on the Message. The DataBinding interceptor can then use one header to pass a flag down so that the Pass-By-Value invoker can skip the copy. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Wednesday, September 05, 2007 3:27 AM Subject: Avoiding unnecessary pass-by-value copies I'm looking at what we could do for TUSCANY-1559 which is about unnecessary pass-by-value copies causing failures when arguments aren't serializable. The problem is on line 260 of JavaComponentContextProvider where it tries to determine if the pass-by-value invoker is required, but it doesn't take into account whats at the other end of the invocation chain. How about changing this so its not the Java implementation types responsibility to handle pass-by-value and move it out into core, having a separate RuntimeWireProcessor and Interceptor for pass-by-value support, and don't do copies if the source and target interfaces use different databindings? ...ant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Base interface
Luciano Resende wrote: Any particular reason for us to have two copies of Base ? import org.apache.tuscany.sca.assembly.Base; import org.apache.tuscany.sca.interfacedef.Base; They seem identical, and making the change in interface-wsdl to use the Base class from assembly seems to cause no harm and the module seems to compile ok. How are you changing the module dependencies for this to compile? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Message.set/getCallableReference used for?
[snip] Simon Nash wrote: I'm OK with most of this, but I have some comments and concerns. See inline. Simon I'm not convinced about putting callbackObject into EndpointReference. The callbackObject can be one of the following: 1) a ServiceReference 2) a local Java instance that supports the callback interface For case 1), the From or replyTo field (see my comments below) on the wire would be used to pass the callbackObject's endpoint instead of passing the client's callback service endpoint. The callback would not be directed back to this client, so there is no reason to hold this ServiceReference in this client's EndpointReference. For case 2), this is not passed on the wire, but is retained by the caller (for stateful callbacks only) to be used for callback invocations. The caller needs to provide a means to correlate the callback object instance with the conversation ID for the stateful callback's conversation. I don't think the caller's EndpointReference needs to hold the callbackObject or play any part in this. +1 - A new Message.replyTo endpoint reference field should be added as the replyTo endpoint can be different from the from endpoint and callback information should be carried in that new replyTo endpoint reference. I don't agree with this. The WS-Addressing replyTo field is used for a reply to the forward message. The semantics of a reply (see section 3.2 of the WS-Addressing spec) are not the same as SCA callback semantics. An SCA callback is a new message that is additional to the reply for the original forward message. A WS-Addressing request/reply exchange must observe the following requirements: 1. The request message must contain a MessageID element 2. The reply message must contain a RelatesTo element containing the MessageId of the original request. Neither of these is needed for callback purposes. SCA callbacks should not be tied to the original message in this way. The wsa:From element is well suited to carrying the SCA callback endpoint information because it simply provides an endpoint to call and does not impose any additional protocol requirements. Your reading of the WS-addressing spec if correct, +1 from me to use from instead of replyTo to carry the endpoint reference of the callback service. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)
Simon Nash wrote: Until now we have always held this information in the wsa:From element. However, in thinking about what is really going on here in WS-Addressing terms, I believe we should be putting it in the wsa:To element instead. The wsa:To element is mandatory for WS-Addressing, but we are not sending it currently. Here's how this would look: wsa:To wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...URI of the service being invoked.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID tuscany:CallbackReference wsa:EndpointReference wsa:Address...URI of the service for the callback.../wsa:Address wsa:EndpointReference /tuscany:CallbackReference /wsa:ReferenceParameters /wsa:EndpointReference /wsa:To (Note: I have capitalized the first letters of CallbackID, ConversationID and CallbackReference to match the WS-Addressing house style) This has a few advantages: 1. It makes us fully compliant with WS-Addressing. 2. WS-Addressing has the notion of a stateful endpoint reference, where the endpoint address is augmented with other information that represents a particular instance of the endpoint. This is exactly what is happening here. Invocations to the same SCA service that differ only in their conversation and callback information are very nicely modelled as different WS-Addressing endpoint references for the same endpoint address. 3. It allows the wsa:To infomation to be exactly the same as the information that would be serialized to represent the CallableReference for the invocation. This is a very neat solution to the question of how a CallableReference should be serialized. It might even give us a decent chance of being interoperable with some non-SCA environments. The callback message would be as follows: wsa:To wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...URI of the service for the callback.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /wsa:ReferenceParameters /wsa:EndpointReference /wsa:To Regarding the sca or tuscany namespace question, the code currently uses the sca namespace but it may be better to use tuscany until we get spec endorsement that this is the correct SCA-approved mapping for SCA conversations and callbacks to Web service protocols. This would be defined in the WS Binding specification. For comparison, this is what the current code does for forward calls, with the From address directly representing the callback endpoint: wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...The URI of the service for the callback.../wsa:Address wsa:ReferenceParameters tuscany:CallbackIDcallback-A01/tuscany:CallbackID tuscany:ConversationIDconversation-006/tuscany:ConversationID /wsa:ReferenceParameters /wsa:EndpointReference /wsa:From Simon Raymond Feng wrote: Hi, I'm thinking of this syntax: wsa:From wsa:EndpointReference xmlns:wsa=... xmlns:tuscany=... !-- I'm not sure if we should use sca or tuscany ns here -- wsa:Address...sourceComponentURI#referenceName.../wsa:Address wsa:ReferenceParameters tuscany:callbackIDcallback-A01/tuscany:conversationID tuscany:conversationIDconversation-006/tuscany:conversationID tuscany:callbackReference wsa:EndpointReference wsa:Address...The URI of the service for the callback.../wsa:Address wsa:EndpointReference /tuscany:callbackReference /wsa:ReferenceParameters /wsa:EndpointReference /wsa:From +1 to flow callback ID and conversation ID in parameters of the to endpoint reference. I don't understand the technical reason for flowing the callback endpoint reference - nested!! - in a parameter of the to endpoint reference. Can you help me understand why we cannot just use the from endpoint reference to identify the callback endpoint? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Message.set/getCallableReference used for?
I'm OK with everything else said in thread so I cut it out to keep this readable. [snip] Raymond Feng wrote: - A new Message.replyTo endpoint reference field should be added as the replyTo endpoint can be different from the from endpoint and callback information should be carried in that new replyTo endpoint reference. I don't agree with this. The WS-Addressing replyTo field is used for a reply to the forward message. The semantics of a reply (see section 3.2 of the WS-Addressing spec) are not the same as SCA callback semantics. An SCA callback is a new message that is additional to the reply for the original forward message. A WS-Addressing request/reply exchange must observe the following requirements: 1. The request message must contain a MessageID element 2. The reply message must contain a RelatesTo element containing the MessageId of the original request. Neither of these is needed for callback purposes. SCA callbacks should not be tied to the original message in this way. The wsa:From element is well suited to carrying the SCA callback endpoint information because it simply provides an endpoint to call and does not impose any additional protocol requirements. I don't think we should directly use From to hold the callback endpoint. We'll lost the caller's EPR if we do so and we cannot support RequestContext.getServiceReference(). I sgguest that we keep the callback endpoint as a reference parameter in the caller's EPR which should be the From. By default, the callback endpoint will be the callback service on the source reference and it can be changed by calling ServiceReference.setCallback() on the caller side. To help me understand what you're proposing (and since all of this has to work with Web Services as well) can you paste here two SOAP envelopes showing a request and a callback? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapper style test in WSDL processing?
[snip] Simon Laws wrote: I've done a bit more investigation now. For the signature String foo() Axis2 Java2WSDL generates wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; attributeFormDefault=qualified elementFormDefault=qualified targetNamespace=http://test/xsd; xs:element name=fooResponse xs:complexType xs:sequence xs:element name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=fooMessage / wsdl:message name=fooResponseMessage wsdl:part name=part1 element=ns:fooResponse / /wsdl:message I'm trying to understand the overall picture before choosing a side: - tolerate what Axis2 generates in our isWrapped() algorithm? - or fix the WSDL after it's generated by Axis2? I have the following two questions: 1) Is it true that the above WSDL has no chance to work at all as it doesn't allow the foo operation to be sent at all (since there is no foo element to carry it)? 2) Could you please paste the entire WSDL? including the generated binding and service+port? I believe that it'll help answer question (1). Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with dynamic creation of NotificationReferenceBindingProvider
[snip] Raymond Feng wrote: At this moment, the code works as Ignacio described. We defer the activation of a reference to the first time it's used for invocation. If we decide that we need to agressively start the reference bindings, we can add the part back to CompositeActivatorImpl. Thanks, Raymond I think we need to activate references when the component that owns them is activated, to keep the semantics of of start()/stop() clear, and allow providers to perform any initialization they need on references (which are not so different from services in many aspects). -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapper style test in WSDL processing?
ant elder wrote: On 9/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip I'm trying to understand the overall picture before choosing a side: - tolerate what Axis2 generates in our isWrapped() algorithm? Is it really just the wsdl that Axis2 (1.2) generates? What about anyone using an existing wsdl that is wrapped style but may not precisely match the jaxws definition of wrapped? ...ant Do you have a specific WSDL pattern in mind? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wrapper style test in WSDL processing?
Jean-Sebastien Delfino wrote: [snip] Simon Laws wrote: I've done a bit more investigation now. For the signature String foo() Axis2 Java2WSDL generates wsdl:types xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; attributeFormDefault=qualified elementFormDefault=qualified targetNamespace=http://test/xsd; xs:element name=fooResponse xs:complexType xs:sequence xs:element name=return nillable=true type=xs:string / /xs:sequence /xs:complexType /xs:element /xs:schema /wsdl:types wsdl:message name=fooMessage / wsdl:message name=fooResponseMessage wsdl:part name=part1 element=ns:fooResponse / /wsdl:message I'm trying to understand the overall picture before choosing a side: - tolerate what Axis2 generates in our isWrapped() algorithm? - or fix the WSDL after it's generated by Axis2? I have the following two questions: 1) Is it true that the above WSDL has no chance to work at all as it doesn't allow the foo operation to be sent at all (since there is no foo element to carry it)? 2) Could you please paste the entire WSDL? including the generated binding and service+port? I believe that it'll help answer question (1). Thanks OK, looks like the answer to your question was already in your post, I should have read it better. In this case, it works with SOAP action. I think it's better to tolerate that (incorrect) behavior from Axis2 for now, as: (a) I don't think we'll be able to patch all WSDLs that may be generated by users with the Axis2 tools out of our control (b) this is a workaround anyway, and a tolerating workaround is not worse than a patching workaround, actually it is probably better as it won't introduce any other side effects I also think that we need to open an Axis2 JIRA to report and track this bug. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: On 8/30/07, ant elder [EMAIL PROTECTED] wrote: This thread has gone quiet but there's been more discussion on this in TUSCANY-1654 (in case people aren't reading all the jira comments). How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method? That seems the easiest way to fix things so i'd like to do this unless someone has a better approach? ...ant There's a better approach IMO: the getBaseURI method you proposed initially. Here's my last comment on getContextPath(), which got snipped out of the thread, so I'm just going to say it again :) After reading this: http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html#getContextPath(), getContextPath() seems to return the path portion of the URI starting with /, this is different from the complete request URI. So if a complete URL from a mapping is not convenient to pass to Axis2 then I don't think that there's an equivalent in the Servlet APIs and it's probably best to go back to your initial idea of a getBaseURI() method. This is also consistent with the comments in TUSCANY-1654, which report that getContextPath are returning... a path, not the complete URI. Also the code that you pointed me to does this: String filePart = req.getRequestURL().toString(); -- to get the complete URL/URI, different from the request path ... o.a.t.s.binding.ws.axis2.TuscanyListingAgent.setContextRoot(filePart) So I'm still not sure about how this new ServletHost.getXyz() method will be used, but anyway a getContextPath() doing something different than the Servlet API getContextPath() will be confusing and I prefer your initial getBaseURI() proposal. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with dynamic creation of NotificationReferenceBindingProvider
Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, September 05, 2007 9:03 AM Subject: Re: Issue with dynamic creation of NotificationReferenceBindingProvider [snip] Raymond Feng wrote: At this moment, the code works as Ignacio described. We defer the activation of a reference to the first time it's used for invocation. If we decide that we need to agressively start the reference bindings, we can add the part back to CompositeActivatorImpl. Thanks, Raymond I think we need to activate references when the component that owns them is activated, to keep the semantics of of start()/stop() clear, and allow providers to perform any initialization they need on references (which are not so different from services in many aspects). There are some differences. A reference can be dynamically created and it is possible that a reference binding won't be selected at all. What do you mean by a reference can be dynamically created? can you please describe the scenario you have in mind? As a balance, can we do the following? 1) During the activation of a component, we add the reference binding providers to the defined references. Then the binding provider will have a chance to do some initialization (for example, handle subscription). Do you mean in its constructor? 2) When the reference is used for invocation, we start the binding provider (further initilization can be performed at this time) and create the wire/invocation chains. Thanks, Raymond -- Jean-Sebastien -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: On 9/5/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: On 8/30/07, ant elder [EMAIL PROTECTED] wrote: This thread has gone quiet but there's been more discussion on this in TUSCANY-1654 (in case people aren't reading all the jira comments). How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method? That seems the easiest way to fix things so i'd like to do this unless someone has a better approach? ...ant There's a better approach IMO: the getBaseURI method you proposed initially. Here's my last comment on getContextPath(), which got snipped out of the thread, so I'm just going to say it again :) After reading this: http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html#getContextPath() , getContextPath() seems to return the path portion of the URI starting with /, this is different from the complete request URI. So if a complete URL from a mapping is not convenient to pass to Axis2 then I don't think that there's an equivalent in the Servlet APIs and it's probably best to go back to your initial idea of a getBaseURI() method. This is also consistent with the comments in TUSCANY-1654, which report that getContextPath are returning... a path, not the complete URI. Also the code that you pointed me to does this: String filePart = req.getRequestURL().toString(); -- to get the complete URL/URI, different from the request path ... o.a.t.s.binding.ws.axis2.TuscanyListingAgent.setContextRoot(filePart) So I'm still not sure about how this new ServletHost.getXyz() method will be used, but anyway a getContextPath() doing something different than the Servlet API getContextPath() will be confusing and I prefer your initial getBaseURI() proposal. I think there's some miscommunication going on here. When i said How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method i meant it would also work like the Servlet API method and return a path not a complete URI as with the getBaseURI proposal. So for the examples given initially a webapp url like, http://localhost:8080/helloworld-ws-service-webapp and the war distro http://localhost:8080/tuscany, the new getContextPath method would return /helloworld-ws-service-webapp and /tuscany respectively. ...ant Ah I see. Got it... finally :) I'm +1 on it then, ServletHost.getContextPath() is definitely the right approach! Sorry for having mis-understood what you meant before. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is Message.set/getCallableReference used for?
Simon Nash wrote: See inline. Simon Raymond Feng wrote: Hi, There are a set of states associated with CallableReference/ServiceReference such as the callbackID, conversationID and callbackObject. We need to flow them in the Message so that the target service can have the correct correlations. At this moment, we have some of fields on the Message and I thought maybe it's better to follow the CallableReference as a whole. Another reason is that the RequestContext has a few methods to retrieve the ServiceReference, CallbackReference and Callback object. This works on the reference binding side for marshalling onto the wire but not on the service binding side for unmarshalling from the wire into the Message. See point 5 of my comments in TUSCANY-1591. I agree with your comments that it's not very nice to have CallableReference directly on the Message as accessors. Moving forward, we probably need to define headers for the Message interface so that we can flow extra context data without poluting the Message interface. Its makes sense to put everything that is Java-specific (currently callback ID, conversation ID, conversation sequence and callbackObject) into a separate header. It would also be good to separate out the processing of these things from the core invocation framework into Java-specific interceptors. There are already some use cases such as: * Pass some information from one interceptor to another one, for example, the DataBindingInterceptor can tell the PassByValueInvoker to skip the copy. * Carry binding-specific context in the Message, for example, SOAP headers for binding.ws or JMS properties for binding.jms. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, September 03, 2007 7:03 PM Subject: What is Message.set/getCallableReference used for? Could somebody help me understand what Message.set/getCallableReference is used for? If I comment it then some callback test cases start to fail, but I don't really understand why we need to store a CallableReference in the message, and its relationship with the from and to EndpointReferences, which can already host callback endpoints. Also CallableReference is specific to Java (if I understand correctly it takes a Java business interface) so if it's really used and needed I'm not sure about how it's used for callbacks typed by WSDL or other interface definition languages. There are a number of implementation classes for Java-specific APIs that6 are currently in core/context: CallableReferenceImpl ComponentContextImpl ConversationImpl RequestContextImpl ServiceReferenceImpl Having these classes in core causes problems when trying to fully implement their spec semantics, because some of these semantics need Java-specific code. The example that I am struggling with at the moment is ServiceReferenceImpl.setCallback() which can take either an instance of a Java implementation class or a service reference. If the former is passed, ServiceReferenceImpl should check to make sure it implements the callback interface and is Serializable (see section 1.6.7.5 of the Java Annotations and APIs spec). This is not possible without using Java-specific code, but I don't want to make the core module dependent on the implementation-java-runtime module. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] We're getting close to our 1.0 release and I think it's time to clean up some of the SPIs, remove what's not really indispensable, and try to avoid inconsistencies in last minute improvements and bug fixes. I've reviewed some of this code and here's what I think needs to happen: - Implementations of the org.osoa.sca Java API should move out of core to the implementation-java-runtime module, as suggested - if I understood correctly - by Simon as well - Message.callableReference should be removed, as it's carrying duplicate info - EndpointReference should reference parameters, similar to the evil WS-addressing, but simpler and more light weight, with just 3 fields: - callbackID - conversationID - callbackObject 3 fields will be better than a big Map here as I'd hate to see a new Map created for each invocation :) - Message.correlationID should be removed as its semantics is not clear and it won't be necessary anymore if callbackID gets carried in the endpoint reference - A new Message.replyTo endpoint reference field should be added as the replyTo endpoint can be different from the from endpoint and callback information should be carried in that new replyTo endpoint reference. Hopefully this won't generate long debates. If there's too many questions or if what I'm proposing here is not clear, I'll post some code implementing this. It'll be more concrete this way
[jira] Updated: (TUSCANY-1638) SDO command-line code generator behaves differently than standalone when invoked in Eclipse
[ https://issues.apache.org/jira/browse/TUSCANY-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1638: Affects Version/s: (was: Java-SCA-1.0) Java-SDO-1.0 Fix Version/s: (was: Java-SCA-1.0) Java-SDO-Next Assigning to the correct SDO release. SDO command-line code generator behaves differently than standalone when invoked in Eclipse --- Key: TUSCANY-1638 URL: https://issues.apache.org/jira/browse/TUSCANY-1638 Project: Tuscany Issue Type: Bug Components: Java SDO Tools Affects Versions: Java-SDO-1.0 Environment: OS is Windows XP Professional SP2, and the SDO command line tool is invoked in side an Eclipse 3.3 plugin. Reporter: Sean Zhou Fix For: Java-SDO-Next I am trying to invoke the SDO command-line code generator inside eclipse which is causing it to behave differently than standalone. The following fix is suggested by Frank in Tuscany: 1) In class org.apache.tuscany.sdo.generate.adapter.SDOGenModelGeneratorAdapterFactory add another override method, createGenModelAdapter(), to return a new Tuscany subclass of GenModelGeneratorAdapter (e.g., SDOGenModelGeneratorAdapter). 2) In the new subclass, override the ensureProjectExists() method to do nothing. 3) Override anything else you need to ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524852 ] Jean-Sebastien Delfino commented on TUSCANY-1516: - This seems to use old APIs (CurrentCompositeContext?) to locate the service. Is there any chance you can port your test case to the latest Tuscany SCA APIs (SCADomain)? Thanks. Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Fix For: Java-SCA-1.0 Attachments: default.composite, MyServiceImpl.java, mySimpleService.composite, MyTotalService.java, MyTotalServiceImpl.java, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue with dynamic creation of NotificationReferenceBindingProvider
Ignacio Silva-Lepe wrote:
Part of the design of binding-notification is that
NotificationReferenceBindingProvider
serves as a producer service to handle subscription requests from consumers.
Because of this, the code was relying on
NotificationReferenceBindingProvider
being created early, at activation time of components and (component)
services.
In particular, having NotificationReferenceBindingProvider created at the
first
invocation from its notification component is too late, as no consumer will
be able
to subscribe before any message is sent.
There may be a few ways to work around this dynamic creation, which I'll try
to
enumerate, but none of them seem ideal. But my real question is whether it
would
be possible to make this dynamic or lazy activation of references
optional.
That is, would it be possible to let the provider factory interface include
a
supportsDynamicReferenceActivation kind of method. The default return value
would be true, but if necessary, the method could return false and then the
composite activator would activate the references for this factory eagerly.
Thoughts?
Dynamic creation work around possiblities:
1- Try to create the producer service in the module activator - One of the
problems
is that producer service activator is implicit and reliant on the values of
the
notificationType and ntm attributes in the binding element, which are not
known
until the binding is processed. Also, the binding object itself does not
seem to
have a good way to determine the component reference and component that it
corresponds to and that are needed to activate the producer service.
2- Try to create the producer service when the notification component is
started -
It is not clear to me that the hooks are there for the implementation
provider to
do this either, not to mention the fact that this would add a coupling of
the
implementation-notification module to the binding-notification module.
I have two questions:
(1) Is the issue that NotificationReferenceBindingProvider.start() is
not called until a service invocation reaches the reference? If that's
the case then it's a bug in the activator algorithm. A
ReferenceBindingProvider should be started when the component owning the
reference is started.
(2) Your start method looks like this:
start() {
if (started) {
return;
}
brokerManager.referenceProviderStarted(notificationType, this,
remoteNtmUrl);
started = true;
}
The if (started) { test caught my eye, are you seeing the start
method called several times? If that's the case then it's another bug in
the activator. If that's not the case then it's a bug in your start
method, a minor one, since the test is not necessary :)
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationalizing SCA Domain implementations
Comments at the bottom Simon Laws wrote: On 9/4/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/31/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote: In the same JVM, we now use a singleton object to keep all the metadata for the deployable composites running on the node. This has been proven to be problematic, especially in the case of Tomcat or Geronimo integration where applications are running in isolated address spaces. The partition is the portion of SCA domain visible to a given address space and its lifecycle is the same as an Web/JEE application (or some other modules). Then we have the following hierarchy: SCA domain (accross multiple nodes on the network) --- SCA node (I assume one node per JVM and one JVM per node) --- SCA partition (I assume one partition per address space in the JVM) Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 31, 2007 9:46 AM Subject: Re: Rationalizing SCA Domain implementations On 8/31/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Comments inline. Thanks, Raymond - Original Message - From: Simon Laws [EMAIL PROTECTED] To: tuscany-dev tuscany-dev@ws.apache.org Sent: Thursday, August 30, 2007 9:13 AM Subject: Rationalizing SCA Domain implementations We now have a number of domain implementations in Tuscany Java SCA including - The SCADomain interface - DefaultSCADomain - EmbeddedSCADomain - HotUpdatableSCADomain - DistributedDomain/Node Covering a number of scenarios - running a domain in a single node - running a domain across multiple nodes - Adding, removing, updating the contributions of a domain through the API and automatically - Activating/deactivating, starting/stopping deployable composites through the API - Starting, stopping components through the API - Locating service in the domain through the API etc. There are some scenarios that we don't cover at the moment - running multiple domains in a VM Why does one JVM want to join multiple SCA domains? IMHO, it might be over-engineered. I think this depends on the answers to you second point. What else? I would like to propose that we rationalize these various implementations down to a more manageable number. I have a simple model in my mind of the building blocks we have to deal with. 1/ The node. Is responsible for running segregated domains in a VM Associated with zero or more domains. I think we probably miss another layer here, the 'partition's in the same node. In a typical server hosting environment such as Tomcat or Geronimo, applications are isolated by address spaces (such as ClassLoader for java classes). The list of deployable composites coming from the same address space will form a partition. With this layer, we can better embed Tuscany to the various hosting environment and provide the flexibility for dynamic updates. With this in mind, the node will have an aggregate view of all the partitions within the node. Can you say some more about what a partition is in the context of SCA? Asking the question in a different way, what is the implication of having multiple partitions in the same domain? Is this like having separate nodes but with more efficient cross node comms mechaninsm, i.e. within the same JVM? 2/ The domain. Logically knows about all of the artifacts of a domain. Associated with one or more (in the distributed case) nodes. A local representation of the domain (the SCADomain object) provides the interface to wider domain There are some subtleties here about the timing of associating a domain with a node(s) but the simple case, which we implement at the moment, is if you start a domain, start a node, associate the two together and then add contributions. The contributed components run on the node with which the local domain object is associated (more complex node/component selection algorithms can be imagined but we don't do this at present). Here are some suggestions based on the interfaces from the list of existing domain classes above, of the kind of things we need to be able to do; Domain Create/destroy the domain based on
Re: What is Message.set/getCallableReference used for?
Raymond Feng wrote: Hi, There are a set of states associated with CallableReference/ServiceReference such as the callbackID, conversationID and callbackObject. We need to flow them in the Message so that the target service can have the correct correlations. At this moment, we have some of fields on the Message and I thought maybe it's better to follow the CallableReference as a whole. Another reason is that the RequestContext has a few methods to retrieve the ServiceReference, CallbackReference and Callback object. CallbackID seems to be set to CorrelationID, already another field of the message. Here are the only usages I can find for getCallableReference(): in Axis2BindingInvoker fromEPR.addReferenceParameter(CALLBACK_ID_REFPARM_QN, (String)msg.getCallableReference().getCallbackID()); in CallbackInterfaceInterceptor, doesn't look like a valid usage and setCallableReference(): in JDKInvocationHandler msg.setCallableReference(callableReference); just after having done msg.setCorrelationID(callbackID); Are there any other valid usages? I'm probably missing something as I've not been able to understand why callbacks start to fail when I remove this and just flow the callbackID in the correlationID field... Could somebody else give it a try as well? I agree with your comments that it's not very nice to have CallableReference directly on the Message as accessors. Moving forward, we probably need to define headers for the Message interface so that we can flow extra context data without poluting the Message interface. There are already some use cases such as: * Pass some information from one interceptor to another one, for example, the DataBindingInterceptor can tell the PassByValueInvoker to skip the copy. * Carry binding-specific context in the Message, for example, SOAP headers for binding.ws or JMS properties for binding.jms. We'll probably need a headers property on the message, but I think we'll have to be careful into a bag of things that are convenient to pass around this way but not absolutely necessary. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, September 03, 2007 7:03 PM Subject: What is Message.set/getCallableReference used for? Could somebody help me understand what Message.set/getCallableReference is used for? If I comment it then some callback test cases start to fail, but I don't really understand why we need to store a CallableReference in the message, and its relationship with the from and to EndpointReferences, which can already host callback endpoints. Also CallableReference is specific to Java (if I understand correctly it takes a Java business interface) so if it's really used and needed I'm not sure about how it's used for callbacks typed by WSDL or other interface definition languages. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
ant elder wrote: On 9/2/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Hi, I'm thinking that we should include the XQuery implementation that Vasil has contributed in our next release as I think that XQuery gives us a great way to work with / mediate / transform XML data sources. To get ready for that and help Tuscany users understand what they can do with XQuery, I'd like to suggest the following improvements and simplifications to the XQuery sample at [1]. - Move the .xq files from src/main/resources/META-INF/sca to src/main/resources/xquery so that they are in plain sight and people realize that they are first class development artifacts; - support WSDL interfaces, basically removing the requirement to generate SDOs and write many Java interfaces, to help show that you can something useful with just XQuery without having to write any Java code; - I'm not sure about this one, but I was also thinking that we could simplify the sample by using local components instead of having a client + a server and web services in the middle... the idea is that a simpler example will be more effective at demonstrating the value of XQuery. In a parallel thread I'd like to start discussing how we could show XQuery components in the tutorial that we are preparing for ApacheCon 2007, for example to extract data out of the Amazon Web Services that we're planning to use in the tutorial. Thoughts? [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/quote-xquery/ Sounds really good to me. The main issue is with getting a recent release of Saxon in a maven repository so we could included it isn't it? Does anyone have any links to where this has been asked for on the Saxon mailing list, i've been hunting around and not found much yet? (Note, you can also manipulate xml with script components using things like e4x or rexml so these could also be used in the tutorial) ...ant I asked on saxon-help earlier today, here's the archived thread: http://sourceforge.net/mailarchive/message.php?msg_name=005d01c7eded%2414d0d190%240d00a8c0%40turtle -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1345) Many StAXArtifactProcessor implementations read policy but do not write it
[ https://issues.apache.org/jira/browse/TUSCANY-1345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1345. - Resolution: Fixed Fixed as part of a big fix to the StaxArtifactProcessor write methods. Many StAXArtifactProcessor implementations read policy but do not write it -- Key: TUSCANY-1345 URL: https://issues.apache.org/jira/browse/TUSCANY-1345 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Affects Versions: Java-SCA-0.90, Java-SCA-0.91 Environment: sca-java-0.90 Reporter: Matthew Sykes Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.0 While the 0.90 release was closing down, several changes were made to the StAXArtifactProcessor implementations used by the assembly model processors to get rid of the use of an abstract base class capable of dealing with policy. When that work was done, the read operations were updated to read the policy but the write operations were not. It seems that if the processors are going to be used to serialize the model, the write operations would need to serialize the polices as well. I've seen this issue in the RMIBindingProcessor, WebServiceBindingProcessor, and JavaImplementationProcessor but there may be others. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Including the XQuery sample in the next release?
Vasil Vasilev wrote: Hi, Isn't in the official repository some older version of Saxon. May be we could try to run the prototype with this older version. Bye, Vasil If the Saxon project really doesn't want to publish newer JARs then I guess we're going to have to use the 8.7 version already on ibiblio.org. In the longer term, this also gives us a good opportunity to think about making XQuery processor implementations pluggable, as you already suggested :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build failure in binding-echo-extension
Luciano Resende wrote: I'm seeing the following issue under revision #572386 [INFO] Compilation failure D:\dev\Opensource\Apache\Tuscany\source\java\sca\samples\binding-echo-extension\src\main\java\echo\impl\EchoBindingProcessor.java:[51,12] cannot find symbol symbol : class PolicyAttachPointProcessor location: class echo.impl.EchoBindingProcessor D:\dev\Opensource\Apache\Tuscany\source\java\sca\samples\binding-echo-extension\src\main\java\echo\impl\EchoBindingProcessor.java:[55,35] cannot find symbol symbol : class PolicyAttachPointProcessor location: class echo.impl.EchoBindingProcessor Sorry, I missed this module in my previous commit. Now fixed in revision r572423. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Renaming http-* modules to host-*
To be more consistent with the other host-* modules, I'd like to rename http-jetty to host-jetty and http-tomcat to host-tomcat. If there's no objection I'll do this in the next couple days. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What is Message.set/getCallableReference used for?
Could somebody help me understand what Message.set/getCallableReference is used for? If I comment it then some callback test cases start to fail, but I don't really understand why we need to store a CallableReference in the message, and its relationship with the from and to EndpointReferences, which can already host callback endpoints. Also CallableReference is specific to Java (if I understand correctly it takes a Java business interface) so if it's really used and needed I'm not sure about how it's used for callbacks typed by WSDL or other interface definition languages. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sharing XQuery Configuration object, was: Current XQuery implementation issues
Starting a new thread to discuss how to keep the Saxon Configuration around... [snip] 4. I would like to know if a can use some kind of context, which is associated with given request and if I can use this context to put some data there. I do not want this context to be transferred in web service invocation for example, but only in the chain of transformers to the target invoker. We may be able to extend the Tuscany Message or EndpointReference to carry extra context data, but could you give me a little more background on what kind of data you'd like to pass or keep around, and how it's going to be used? In the JIRA you mentioned which configuration is associated with an invocation... The message carrying an invocation should have pointers to assembly model representing the from (reference) and target (service), from which I think you could navigate to the binding model and its configuration. Is that the kind of configuration you're looking for? or some other configuration? [snip] About 4: Sorry i is my mistake. I ment the net.sf.saxon.Configuration object. I want to preserve it the first time it is created for a given invokation. For example this could happen when for first time DataObejct is transformed to NodeInfo. The I want all further transformation and the invokation in the XQueryInvoker to use the same configuration object. I want that this configuration object is invalidated after the invocation finishes. Currently I am doing not very good workaronds to prevent this: see comments in SaxonDataBindingHelper and XQueryInvoker for details. Hi Vasil, I looked at how the Saxon Configuration is used in your code. If I understand correctly, it looks like a new Configuration is created the first time an XQuery expression is compiled, and then used to execute all invocations of that expression. Then the Configuration of the current expression is shared with the Saxon dataBinding Node2NodeInfoTransformer.transform method via the SaxonDataBindingHelper.CURR_EXECUTING_CONFIG static variable. This will not work in a multithreaded environment, as the static is likely to have changed and contain the Configuration from the expression executing in another thread when you reach the transformer. After reading the Saxon Javadoc I am under the impression that it is OK to use the same Configuration object for multiple expressions. How about using a single Configuration object, shared between all the Saxon transformer and the XQuery implementation code. Will that work? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Including the XQuery sample in the next release?
Hi, I'm thinking that we should include the XQuery implementation that Vasil has contributed in our next release as I think that XQuery gives us a great way to work with / mediate / transform XML data sources. To get ready for that and help Tuscany users understand what they can do with XQuery, I'd like to suggest the following improvements and simplifications to the XQuery sample at [1]. - Move the .xq files from src/main/resources/META-INF/sca to src/main/resources/xquery so that they are in plain sight and people realize that they are first class development artifacts; - support WSDL interfaces, basically removing the requirement to generate SDOs and write many Java interfaces, to help show that you can something useful with just XQuery without having to write any Java code; - I'm not sure about this one, but I was also thinking that we could simplify the sample by using local components instead of having a client + a server and web services in the middle... the idea is that a simpler example will be more effective at demonstrating the value of XQuery. In a parallel thread I'd like to start discussing how we could show XQuery components in the tutorial that we are preparing for ApacheCon 2007, for example to extract data out of the Amazon Web Services that we're planning to use in the tutorial. Thoughts? [1] http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/samples/quote-xquery/ -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Transaction support - a bigger picture question
[snip] Luciano Resende wrote: I guess your suggestion for starting simple is fine, and I guess implementation.das could get integrated with SCA Policy and DAS would have the necessary support, unless we find some bugs on the DAS side. I'll see if I can get to this in the coming weeks... BTW, what transaction manager are we going to use in Tuscany ? Do we have any today ? Two suggestions: - in a standalone environment, use JOTM [1] - in Geronimo, get the TM from Geronimo, as done in the Tuscany/Geronimo plugin at [2] [1] http://jotm.objectweb.org/ [2] http://svn.apache.org/repos/asf/geronimo/plugins/tuscany -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (TUSCANY-1499) Core wiring framework should create pseudo-services and pseudo-references for callbacks
Simon Nash wrote: I think it would be good to step back from details of which characters are usable in URIs and look at the bigger picture. Right :) The major question we have to decide is whether the pseudo-services used by callbacks are to be treated from the user's perspective a. exactly like SCA services in every respect +1 b. exactly like SCA services except for a very small number of differences c. as a different thing from an SCA service with its own set of rules for how it is used By treating these exactly like SCA services, I mean doing the following things with them: 1. Specifying as a target of a reference wire 2. Specifying a callback interface and binding in addition to a forward interface and binding 3. Creating a ServiceReference that can be passed to setCallback() 4. Creating a ServiceReference that can be used for normal forward invocations 5. Mapping to an endpoint URI using the standard algorithm defined in the SCA assembly spec 6. Enforcing name uniqueness rules with respect to other services 7. Including in the calculation of whether a component only has a single service so that its default URI need not include the service name 8. Automatically creating an exposed endpoint on a configured host server There could be other aspects that I have overlooked. Please send your additions to this list. +1 for 1 through 8 I'm assuming that this is symmetric and that a callback on a service will work like a reference. The reference representing the callback will have its target endpoint configured at the time a request is received with the endpoint of the originator of the request. The ability to configure the endpoint of a reference at run-time is actually a core function of service references, not specific to callbacks. Although, the Java SCA API does not expose that capability yet, the BPEL programming model does, for regular references as well. Conclusion: - service/callback works like a regular reference - reference/callback works like a regular service As a simple solution I'd like to propose that a callback reference defines an SCA service with the same name as the reference, and that this service can be used exactly like an SCA service except for points 1 and 2 above, which are explicitly precluded by the SCA assembly spec. This callback service would support all the other points on the list above and any other properties of SCA services that I may have overlooked in the above list. The soundbite version is: Callbacks are full SCA services that can't be wired and can't themselves have callbacks. +1 that looks like a clean and simple design to me, I also like the fact that the service is named exactly like the callback reference. Any thoughts or comments on this, or other suggestions? Simon Simon Nash wrote: See inline. Simon Jean-Sebastien Delfino wrote: (cut) The # symbol has a special meaning in URIs as it separates a URI from a fragment id. This form of URI will prevent bindings to use fragment ids to identify the target operation or to append some context to the URI for example. RFC 2396 [1], section 4.1 clearly states this: When a URI reference is used to perform a retrieval action on the identified resource, the optional fragment identifier, separated from the URI by a crosshatch (#) character, consists of additional reference information to be interpreted *BY THE USER AGENT* after the retrieval action has been successfully completed. As such, *IT IS NOT PART OF A URI*, but is often used in conjunction with a URI. So I don't think that using '#' is a good idea. It may work with some bindings, will break others. [1] http://www.ietf.org/rfc/rfc2396.txt Thanks for explaining the issues with #. There were other questions in my last post concerning the use of / as the separator. Since you didn't comment on these, I'm assuming that I have correctly captured the scenario that causes you concerns with this. The reference to RFC2396 is extremely helpful and provides (I think) the necessary information to come up with a good solution to your challenge. From this document, we have a few options for the separator character. Option 1: Use semicolon (;). In section 3.3 of RFC 2394 this is defined as delimiting a parameter or parameters that are part of a path component. It seems quite appropriate to use a ;callback suffix in the last path segment of a URI to represent a callback parameter. Option 2: Use any character that's legal within a path component but not legal in an NCName (used for SCA service and reference names). The possible characters are path segment characters in section 3.3: : | @ | | = | + | $ | , unreserved characters in section 2.3: ! | ~ | * | ' | ( | ) I don't have a strong preference here, but : and @ look good to me, with ! as a possible alternative. With any of these approaches, some kind of callback suffix appears explicitly in the URI, rather than
Re: Monitoring, logging and exceptions (again)
[snip]
Simon Laws wrote:
Ok, so we know there is no generally acceptable logging interface. Has
been proved time and time again. All we can hope to do is use something that
suits us and doesn't mess up anyone who wants to embed our code.
I'm perfectly happy to +1 JDK logging. However without some wrappers to do
it for us we need to define the ground rules for how we use it.
So, in line with what I believe is common practice, how about these...
End user readable information is expected to be recorded against the
following levels
SEVERE
WARNING
INFO
CONFIG
The following levels are tracing levels and are assumed to be developer
readable only
FINE
FINER
FINEST
+1 from me
Loggers will be initialized against the class name to which they relate, and
a resource bundle for the package/or module.
How about leaving the resource-bundle part out for 1.0 and do a pass to
externalize messages later?
private static final Logger Log = Logger.getLogger(
SomeTuscanyClassB.class.getName(), tuscany-?-messages);
We can define some global o.a.t.s loggers if we don't want to have to make
bundles for all of the non-extension modules, e.g.
private static final Logger Log = Logger.getLogger(org.apache.tuscany.sca,
tuscany-messages);
Hmm, wouldn't that require changes in the module containing the global
module when an extension wants to change a message?
Log statements for user readable messages will take the following form, for
example,
Log.log(Level.INFO,
MESSAGE1);
String componentName = Some component;
Log.log(Level.INFO,
MESSAGE2, // message id
componentName); // parameter
Integer params[] = {8, 9, 4};
Log.log(Level.INFO,
MESSAGE3, // message id
params);// parameter
Exception ex = new IllegalStateException(TEST_MESSAGE);
Log.log(Level.INFO,
MESSAGE4, // message id
ex);// parameter
These messages will be localized against a message bundle from the classpath
based on the configuration of the Logger (or the Logger's parent), for
example, tuscany-messages.properties, tuscany-messages_en.properties etc.
MESSAGE1 = This is a test message with no params
MESSAGE2 = This is a test message with a string param {0}
MESSAGE3 = This is a test message with numbers {0}, {1}, {2}
MESSAGE4 = This is a test message with exception
+1 for all that, except that again I'll be more comfortable to leave
externalization to later after 1.0.
Which can of course be provided on an extension by extension basis if
required and if specified when the logger is created.
Developer readable messages are assumed not to be localized and so can be
output using the Logger convenience methods.
We won't use log.entering and log exiting. This level of tracing will be
provided via AspectJ injection.
+1
I'm assuming we don't want our logging properties to have to live in
jdk/lib/logging properties so we need an extensible/replaceable way to
initialize logging. e.g.
InputStream logConfigStream = Thread.currentThread
().getContextClassLoader().getResourceAsStream(tuscany-logging.properties
);
LogManager.getLogManager().readConfiguration(logConfigStream);
+ any other logging configuration that we need
Anyone have a good idea where to put this. It should go close to the start
of our domain/node implementation but would be good if it's replaceable. So
we could do with a new logging extension type that is one of the first
things that gets loaded.
Simon
What would be put in specific logging properties?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Simon Laws wrote: What would be put in specific logging properties? The usual logging configuration, what we want our default logging level to be on a module by module bases, what handlers to use, configuration of the handlers e.g. if it's a file handler where to put the file and what to call it. etc. I'm using the IBM JDK and that doesn't seem to come with a default logging.properties file. We could go with hardcoded defaults but as soon as you want to change something it's problematic. We could ask people to drop one into jdk/lib but that would be active for any other java apps they use. Do you know an easy way round this? I don't know an easy way around this, but I'm still a little confused. If we define a tuscany-logging properties file then what's going to happen when we do: LogManager.getLogManager().readConfiguration(stream for tuscany-logging.properties); Isn't that going to reset the logging configuration for the whole LogManager, altering the log configuration for other projects that use the JDK logger as well? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1636) There should not be an SCABinding created under reference if there is no target on the reference 558780
[
https://issues.apache.org/jira/browse/TUSCANY-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524179
]
Jean-Sebastien Delfino commented on TUSCANY-1636:
-
Raymond is correct, it is valid to have a binding with no target, as
implementations should be able to wire the reference later, dynamically (this
is not exposed by the Java SCA API at this point but is allowed by the SCA BPEL
programming model for example).
Can the SCA binding code just test for a null URI?
Also, what did u mean by there is a null object set to the reference, which
will override existing reference value in the component?
There should not be an SCABinding created under reference if there is no
target on the reference 558780
---
Key: TUSCANY-1636
URL: https://issues.apache.org/jira/browse/TUSCANY-1636
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Reporter: Yang Lei
In CompositeBuilderImpl, we create defeault SCABinding where there is no
binding defined under reference. This will break the SCABinding handling if
the reference does not have a target, then SCABinding willl still get
executed so either there is a NPE as we are not expecting target is not
there, or there is a null object set to the reference, which will override
existing reference value in the component.
I did the following to remove the SCABinding at the end of the
CompositeBuilderImpl.connectComponentReferences, the else block
if (!targets.isEmpty()) {
}else
{
// need to remove the SCABinding we created that did not have
target
if (componentReference.getBindings().size()==1)
{
SCABinding binding =
componentReference.getBinding(SCABinding.class);
if (binding!=null binding.getURI()==null)
{
componentReference.getBindings().clear();
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1642) WSDL2Java cannot handle spaces in the path on Windows
[ https://issues.apache.org/jira/browse/TUSCANY-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1642: Fix Version/s: Java-SCA-1.0 WSDL2Java cannot handle spaces in the path on Windows - Key: TUSCANY-1642 URL: https://issues.apache.org/jira/browse/TUSCANY-1642 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.0 Environment: Windows Reporter: Sean Zhou Fix For: Java-SCA-1.0 WSDL2Java.bat -targetDirectory C:/Documents and Settings/Administrator/runtime-New_configuration2/AAA/src -javaPackage com.addressbook -generateSDO /C:/Documents and Settings/Administrator/runtime-New_configuration2/AAA/AddressBook.wsdl It will receive java.io.FileNotFoundException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1633) To support reference target for SCA Binding using URI on r558780
[
https://issues.apache.org/jira/browse/TUSCANY-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1633:
Fix Version/s: Java-SCA-1.0
To support reference target for SCA Binding using URI on r558780
---
Key: TUSCANY-1633
URL: https://issues.apache.org/jira/browse/TUSCANY-1633
Project: Tuscany
Issue Type: Bug
Components: Java SCA Assembly Model
Environment: Windows
Reporter: Yang Lei
Fix For: Java-SCA-1.0
We assume we can use SCA binding 's URI for its target service. We see the
following problems:
1. When there is a SCABinding element under the reference or we are trying to
create one when there is none, the URI is not set. So added a else block to
the following code in CompositeBuilderImpl,matchBinding method:
if (binding instanceof WireableBinding) {
.
} else {
//use terget serviceBinding's URI as referece's
binding URI
//This is to support reference target
if (cloned instanceof SCABinding cloned.getURI()
== null) {
cloned.setURI(serviceBinding.getURI());
}
}
2. When there is a SCABinding element defined on service side, URI is not set
we need to add the else block:
// Create and configure an SCA binding for the service
if (componentService.getBindings().isEmpty()) {
SCABinding scaBinding =
componentService.getBinding(SCABinding.class);
if (scaBinding == null) {
scaBinding = scaBindingFactory.createSCABinding();
scaBinding.setName(componentService.getName());
componentService.getBindings().add(scaBinding);
}
scaBinding.setComponent(component);
scaBinding.setURI(uri);
}else
{
SCABinding scaBinding =
componentService.getBinding(SCABinding.class);
if (scaBinding != null scaBinding.getURI()==null) {
scaBinding.setURI(uri);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Simon Laws wrote: On 8/31/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: What would be put in specific logging properties? The usual logging configuration, what we want our default logging level to be on a module by module bases, what handlers to use, configuration of the handlers e.g. if it's a file handler where to put the file and what to call it. etc. I'm using the IBM JDK and that doesn't seem to come with a default logging.properties file. We could go with hardcoded defaults but as soon as you want to change something it's problematic. We could ask people to drop one into jdk/lib but that would be active for any other java apps they use. Do you know an easy way round this? I don't know an easy way around this, but I'm still a little confused. If we define a tuscany-logging properties file then what's going to happen when we do: LogManager.getLogManager().readConfiguration(stream for tuscany-logging.properties); Isn't that going to reset the logging configuration for the whole LogManager, altering the log configuration for other projects that use the JDK logger as well? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Yes , say if we embed tuscany in some other project and we were to read the logging.properties file as above we would mess up the settings of the embedding application. Thats why we have to be able to remove any configuration we provide, for example, for our samples. Simon How about not messing up the settings - i.e. not impose or provide a configuration properties file - and let the user configure the JDK logger the way he wants? Sometimes not providing anything is better than providing something that's going to get in the way, even if we document how to remove the obstacle we have created :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1142) Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with named complexType
[
https://issues.apache.org/jira/browse/TUSCANY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1142:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
Need to allow generation of wrapped Java intf from doc-lit-wrap WSDL with
named complexType
Key: TUSCANY-1142
URL: https://issues.apache.org/jira/browse/TUSCANY-1142
Project: Tuscany
Issue Type: Bug
Components: Java SCA Tools
Affects Versions: Java-SCA-M2
Reporter: Scott Kurz
Fix For: Java-SCA-1.0
Our WSDL2Java tool maps the following WSDL pattern onto a non-wrapped Java
interface even when using doc-lit-wrapped WSDL:
...types
complexType name=getGreetings
sequence
element name=name type=xsd:string/
/sequence
/complexType
element name=getGreetings type=tns:getGreetings/
...
/types
I noticed that wsimport seems to unwrap this and produce:
getGreetings(String)
whereas our WSDL2Java treats this as non-wrapped and generates:
getGreetings(getGreetings)
The key line of Tuscany code is:
org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.isWrapped()
if (typeMappingEntry.isAnonymous()) {
wrapped = true;
}
As I claim in this JIRA, TUSCANY-1019, it would be nice to ALSO have the
ability to generate a non-wrapped Java interface from the given WSDL pattern,
but we should also allow for generation of a wrapped interface (the wrapped
by my guess should be the default).
Yang Zhong posted this reply in agreement to the Tuscany dev list.
Once binding is involved within WSDL2Java, one WSDL portType/message can end
up with multiple Java classes respective to different bindings.
It mixes business logic and wire format :-(
Assuming involving binding is de facto, and only one binding each WSDL
portType/message,
maybe we can change JavaInterfaceEmitter.isWrapped to an algorithm such as:
1. not wrapped if the style is not document or the use is not literal
2. not wrapped if the message has more than one parts
3. not wrapped if the part isn't element or its local name doesn't match the
operation local name
4. not wrapped if the operation name isn't unique within the portType
Yes, I agree with Scott not to take isAnonymous() into account.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1511) Conversational - spec funnies and other improvements
[ https://issues.apache.org/jira/browse/TUSCANY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1511: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Conversational - spec funnies and other improvements Key: TUSCANY-1511 URL: https://issues.apache.org/jira/browse/TUSCANY-1511 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Environment: All Reporter: Simon Laws Fix For: Java-SCA-1.0 We closed http://issues.apache.org/jira/browse/TUSCANY-1377 when we got to the stage where conversation support was basically back up and running. There are still some outstanding issues recorded against that report that come down to lack of clarity in the spec and/or are awaiting other bits of the Tuscany runtime to be completed. Here is the list so far. Features Currently Supported --- @Conversational - service callback interfaces @Scope(CONVERSATION) @Scope(STATELESS) @Init @Destroy @ConversationAttributes(maxAge=2 days, maxIdleTime=5 minutes ) @ConversationId @EndsConversation - service and callback interfaces ServiceReference getConversationID() setConversationID(Object) CallableReference (can be persisted,can be passed) isConversational() getConversation() Conversation getConversationID() end() ConversationEndedException Restrictions And Required Clarifications The specification is not clear on a number of points related to Stateful callbacks. 1/ In the current implementation the spec has been interpreted to mean that the client component, i.e. the component implementing the callback interface, must be marked as conversational in order that callback messages return to the same instance of the client component that originated the conversational call. In this case the target of a callback (the source of the original message) has to be stored against a conversationId so that the callback can find it and invoke the callback operation on it. Currently, at the source component, the incoming conversationid is reused for outgoing messages to allow this to happen (the component instance will automatically have been registered against this id when it was created). A better solution would be to allow the reference logic to always create a new conversation id (or accept a user defined conversation id) but, for stateful callbacks this implies that the source component instance has to be registered against multiple conversation ids in the conversational scope container. As pumbing this in is a little tricky we need discuss round alternative solutions. 2/ The spec isn't explicit about what happens at the server when Conversation.end() is used on the target service. In the current implementation it will not free any resources held at the target. A protocol is required between source and target to carry this end() instruction. As it stands the target conversation will eventually time out. Subsequent requests to the target will create a new conversation. 3/ @EndsConversation on the target component where a stateful callback is defined will end the callback conversation at the target only, I.e. the component instance representing the conversation at the source end will remain in place. It remains until the callback calls an @EndConversation annotated message. This is tricky because the source component instance may have been created as part of another conversation which hasn't ended yet. Not clear whether the intention of the spec is to get both to happen at once. The specification also talks about the ability to pass round references that refer to ongoing conversations. No passing of services references, referring to conversational services, is currently supported. This is primarily because the service reference is not currently serializeable but the spec could also benefit from some clarrification in this area. For example, If a callable reference is passed off to another service how does that callable reference know what the state of the conversation is? There are also a few other pieces that are awaiting the completion of other bits of work. @Scope(COMPOSITE) excluded due to ML conversation (http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg20573.html) @ConversationAttributes(singlePrincipal=false). Awaiting plicy/security work The WS binding is being targetted as the first remote binding with conversation support but this is not complete
Re: Boolean instead of boolean for autowire attributes
Raymond Feng wrote: Hi, I'm reviewing our support for autowiring and found out there is an issue with our Composite/Component/ComponentReference models. By the assembly spec, there is difference between the following two cases: a) component name=C1 b) component name=C1 autowire=false Case a) will inherit the autowire from the containing composite while case b) will override the one from the composite. In the current code, we use a boolean to represent the setting in Composite/Component/ComponentReference interface and it cannot reflect the null value. I propose that we make the following changes: 1) Change the method void setAutowire(boolean autowire) to void setAutowire(Boolean autowire). Thanks to the JDK5 autoboxing, this will not break any existing code. 2) Change the implementation of isAutowire() to default null value to false. 3) Add a new method to Boolean getAutowire() to the Composite/Component/ComponentReference 4) Update the CompositeProcessor and CompositeConfigurationBuilderImpl to read/propagate the autowire settings correctly. I have all these changes working locally. If there's no objections, I'll check in the code soon. Thanks, Raymond +1, would be good to also @deprecate isAutowire then. Are there any other boolean attributes in the model deserving a similar treatment? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1646) Web Service binding doesn't handle wsdli:wsdlLocation
Web Service binding doesn't handle wsdli:wsdlLocation - Key: TUSCANY-1646 URL: https://issues.apache.org/jira/browse/TUSCANY-1646 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.99 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 According to the Web Service binding spec, it should be possible to specify the location of the WSDL file used to configure a Web Service binding. Our WebServiceBindingProcessor is able to read that location but later ignores it and does not use it to get the the WSDL file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1647) Web Service binding doesn't handle SOAP1/2 policy intent
Web Service binding doesn't handle SOAP1/2 policy intent Key: TUSCANY-1647 URL: https://issues.apache.org/jira/browse/TUSCANY-1647 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The Web Service binding should use SOAP 1.2 when configured with a soap/1.2 policy intent, as described in section 2.3.1 of the SCA WebService binding spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1648) WS Binding WSDL generation should follow the rules in section 2.3.5 of the WS binding spec
WS Binding WSDL generation should follow the rules in section 2.3.5 of the WS binding spec -- Key: TUSCANY-1648 URL: https://issues.apache.org/jira/browse/TUSCANY-1648 Project: Tuscany Issue Type: Bug Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-0.99 Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The WSDL automatically generated by the Web Service binding should be generated as described in section 2.3.5 of the WS binding specification. Our current WSDL generation algorithm generates valid WSDL, but different from what's described in the SCA spec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1494) Implement a functional SCA Policy Framework
[ https://issues.apache.org/jira/browse/TUSCANY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1494: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Implement a functional SCA Policy Framework Key: TUSCANY-1494 URL: https://issues.apache.org/jira/browse/TUSCANY-1494 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Venkatakrishnan Assignee: Venkatakrishnan Fix For: Java-SCA-1.0 Implement a functional policy framework for Java SCA. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1649) Implement SCA transaction policy intents
Implement SCA transaction policy intents Key: TUSCANY-1649 URL: https://issues.apache.org/jira/browse/TUSCANY-1649 Project: Tuscany Issue Type: New Feature Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-Next Implement a model, XML syntax support, and runtime for transaction policy intents. The SCA spec for this is not ready yet, but a discussion has started on the subject there: http://www.mail-archive.com/[EMAIL PROTECTED]/msg01656.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1651) Implement support for SCA security policy intents
Implement support for SCA security policy intents - Key: TUSCANY-1651 URL: https://issues.apache.org/jira/browse/TUSCANY-1651 Project: Tuscany Issue Type: New Feature Components: Java SCA Assembly Model Affects Versions: Java-SCA-Next Reporter: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 We should implement support for the security policy intents described in the SCA Policy spec 1.0 sections 1.7.1 and 1.7.2. It shouldn't be too hard to leverage Axis2 support for WS security to add support for the to the Web Service Binding. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1639) I would suggent a improvement on WSDLInterfaceProcessor
[ https://issues.apache.org/jira/browse/TUSCANY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524247 ] Jean-Sebastien Delfino commented on TUSCANY-1639: - Hi Right, it is sometimes useful to be able to point to the actual location of the WSDL file. I'd like to suggest a minor variation of what you're describing. Instead of using the uri attribute, the SCA specification suggests to use: interface wsdlLocation=location/ to point to the location of a WSDL file. This is documented on lines 2307, 2847 and 2943 in the SCA assembly spec 1.0 document. Doing it this way will also allow Tuscany to support other schemes than ?wsdl, since whatever is specified in the wsdlLocation attribute will be used as a location hint for the WSDL. It would be great if you could work on that and provide support for loading WSDL from the specified location! You just need to attach a patch to this JIRA and we'll review it. Thanks! I would suggent a improvement on WSDLInterfaceProcessor --- Key: TUSCANY-1639 URL: https://issues.apache.org/jira/browse/TUSCANY-1639 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: jdk1.5 eclipse windiows latest svn code Reporter: gengshaoguang Fix For: Java-SCA-Next Hi everyone, I would suggest the following: When reference a wsdl with referenceinterface.wsdl interface=[uri]//reference, the [uri] atttribute must be based on a preloaded local saved wsdl file. Would it be better if the developer specify a ?wsdl like uri, then the WSDLInterfaceProcessor could load it from remote/dynamic place instead of from classpath. If no one against my suggestion, I would like to do some thing more on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1639) I would suggent a improvement on WSDLInterfaceProcessor
[ https://issues.apache.org/jira/browse/TUSCANY-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1639: Fix Version/s: Java-SCA-Next I would suggent a improvement on WSDLInterfaceProcessor --- Key: TUSCANY-1639 URL: https://issues.apache.org/jira/browse/TUSCANY-1639 Project: Tuscany Issue Type: Improvement Components: Java SCA Axis Binding Extension Affects Versions: Java-SCA-Next Environment: jdk1.5 eclipse windiows latest svn code Reporter: gengshaoguang Fix For: Java-SCA-Next Hi everyone, I would suggest the following: When reference a wsdl with referenceinterface.wsdl interface=[uri]//reference, the [uri] atttribute must be based on a preloaded local saved wsdl file. Would it be better if the developer specify a ?wsdl like uri, then the WSDLInterfaceProcessor could load it from remote/dynamic place instead of from classpath. If no one against my suggestion, I would like to do some thing more on this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is there value in keeping download links for old releases?
ant elder wrote: The Eclipse STP project isn't using M2 because they accidentally downloaded the wrong release, its what was current at the time and they haven't migrated to a newer release yet. I think its good to keep old releases to (1) show the release history, and (2) have historical downloads available for people working on back level systems. No problem with rearranging the website if it makes the current release more obvious but i don't think old ones should just be deleted or hidden. ...ant +1 for keeping links to old releases, but rearranging the download web page to make more obvious that the current release is current and that old releases are old. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Add getBaseURI to ServletHost (was Re: Problem with getting wsdl for HelloWorldService webservice
ant elder wrote: On 8/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: ant elder wrote: I've not yet been able to find any good way to reliably work out the complete service URL in all environments. What i think maybe the best approach is to add a getBaseURI method to the Tuscany ServletHost interface so that can be used by bindings. So then it would be down to each ServletHost impl to set this correctly rather than the Axis2 binding to work it out. So for example for WebappServletHost it would be the webapp url like, http://localhost:8080/helloworld-ws-service-webapp, for the war distro http://localhost:8080/tuscany, for Geronimo http://localhost:8080 etc. Does something like this sound ok or does anyone have any better ideas? ...ant I'm not sure which scenario you have in mind for this, so here are the two use cases I can think of: (1) A binding was configured with a URI like localhost:8080 but will need to tell the world (in generated WSDL, in service endpoint references etc.) the actual endpoint address at which it can be reached, 192.168.1.1:8080 or myhost:8080 for example (2) A binding was configured with a URI, but we are not in a position to provide the service at that exact same URI, because we are running in a Webapp deployed at a different URI for example. I don't really like this use case as I think there's issues with this approach and that we should configure the Web container from the SCA metadata, not the other way around, but I guess we have to live with that for now :) Anyway, in that case as well we need to figure the effective URI of the particular service to put it in service endpoint references for example. For both scenarios, I'd suggest methods like this: ServletHost.getRequestURI(String mapping) - giving you the complete URI that people will have to send requests to or ServletHost.getServletPath(String mapping) - giving you the actual URI at which the particular servlet is available Both methods are modeled after the Servlet API interface, and will give you what you need (assuming I correctly guessed the scenarios you're after) in a simpler way than a getBaseURI() method which would still require the binding to combine that base URI with the rest of the URI that it knows about. There's also a 3rd case where the binding uses a default or relative uri which the runtime can honour and things like ?wsdl still need to be able to advertise the actual endpoint. Anyway from those three cases it seems like a way to get his from the ServletHost is valid thing to have. Yes From the perspective of whats the simplest way to code this for the ws binding as-is now i suspect a method that returns a complete url from a mapping may not be so easy to use with the current Axis2 code. Can you point me to piece of code that will use that URL and pass it to Axis2? This area has changed a lot with Axis2 1.3 though so it may depend on if we move up to Axis2 1.3. We'd also have to have all the code to work out the actual ip address or host name for use by the Jetty and Tomcat standalone ServletHosts. How about we just have a ServletHost getContextPath() modeled after the Servlet APIs getContextPath method? ...ant After reading this: http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletRequest.html#getContextPath(), getContextPath() seems to return the path portion of the URI starting with /, this is different from the complete request URI. So if a complete URL from a mapping is not convenient to pass to Axis2 then I don't think that there's an equivalent in the Servlet APIs and it's probably best to go back to your initial idea of a getBaseURI() method :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JDKLogger calls, was: Monitoring, logging and exceptions (again)
Raymond Feng wrote: I just created https://issues.apache.org/jira/browse/TUSCANY-1635 to track the aspectj-based tracing. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 29, 2007 11:06 AM Subject: Re: Monitoring, logging and exceptions (again) Simon Laws wrote: On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/20/07, Simon Nash [EMAIL PROTECTED] wrote: See inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 17, 2007 9:27 AM Subject: Re: Monitoring, logging and exceptions (again) [snip] ant elder wrote: And also my 2p inline... ...ant On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy that this is the responsibility of whoever wants to trace through the code and not a core part of the codebase. For the Tuscany developer community AspectJ have been proposed a couple of times and support has been prototyped. We could choose SLF4J as the interface through which messages are output. I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a facade for logging APIs, so you can code to the SLF4J API and then plug in whatever logging impl you like, but if the only logging calls we have are confined to a single tracing aspect we might as well just code that aspect to a specific logging API like JDK logging. That avoids the extra dependency on SLF4J and anyone can add additional aspects if they really want to use a different logger. The main other benefit of SLF4J is its parameterized message logging (avoids all the if(logger.isDebugEnabled()) ) but again if all the logging calls are in a single aspect thats not so useful. Makes sense to me. If we go the aspectj route for tracing method entry/exit, I agree that using the JDK logger directly is simpler. Since the aspect is on the side, we're flexible. JDK logger can be default and it can be replaced easily if the embedders or users choose to do so. A few more questions on this: What dependencies will aspectj add to our distribution? aspectjweaver is more than 1Mb, do we need it? I'll try to spend some time to explore both the compile-time and load-time weaving. What about mid-method logging of specific interesting events, for example the contents of requests as the enter and leave bindings and implementation types and things like that? That sort of logging is often all a lot of users want to see not the detail tracing of every method entry/exit. Could we add things like this in specific places? +1 for the ability to produce this level of information. This is my preferred approach for debugging or understanding how some part of the code works. Having every method entry and exit produce a trace line often creates a huge amount of output that obscures the essential details of what is happening. Can this mid-method logging be split in two categories? a) Debug tracing A simple solution is to split the method in two, and then leverage the entry/exit method tracing as discussed above. In many cases this would lead to a convoluted code structure with local variables needing to be passed as parameters between the two methods, or methods that contain a single line of code (if a trace line needs to be produced from within a loop). We can use JDK logger to add statements in the middle of a method. Then we can use an aspect to capture such calls to dump out the information. For example, if we have the following statement in a method: logger.debug(...); The apsect can trap it by a point cut like call * java.util.logger.Logger.debug(..). If the logger call is already there, why is an aspect needed to trap it? Why not just let it execute? b) End-user readable information (info that a binding is sending/receiving a message for example) This falls into the second category discussed in this thread, reporting significant events to a management console. The above suggestion should help too. The key here is to have some calls to indicate such requirements and they can be then trapped to provide the concrete logic. I think we're starting to see concrete solutions for (a) with aspectj. I have not seen any real concrete proposal for (b) yet. -- Jean-Sebastien
[jira] Assigned: (TUSCANY-1326) DWR binding should use endpoints as defined in the assembly spec 1.7.2
[ https://issues.apache.org/jira/browse/TUSCANY-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino reassigned TUSCANY-1326: --- Assignee: Jean-Sebastien Delfino DWR binding should use endpoints as defined in the assembly spec 1.7.2 -- Key: TUSCANY-1326 URL: https://issues.apache.org/jira/browse/TUSCANY-1326 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.99, Java-SCA-Next Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the services they provide. Instead they should use the algorithm described in the SCA assembly spec section 1.7.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1326) DWR binding should use endpoints as defined in the assembly spec 1.7.2
[ https://issues.apache.org/jira/browse/TUSCANY-1326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523498 ] Jean-Sebastien Delfino commented on TUSCANY-1326: - I'm starting to work on this. To make different services available at different URIs, I thing that we'll need multiple instances of DWRServlet (one per service) instead of the single instance currently mapped to the hardcoded SCADomain/* URI. Will this break DWRServlet? How is DWRServlet designed to be used? DWR binding should use endpoints as defined in the assembly spec 1.7.2 -- Key: TUSCANY-1326 URL: https://issues.apache.org/jira/browse/TUSCANY-1326 Project: Tuscany Issue Type: Bug Components: Java SCA JSON-RPC Binding Extension Affects Versions: Java-SCA-0.99, Java-SCA-Next Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 The jsonrpc and Ajax bindings currently hardcode the endpoint uri of the services they provide. Instead they should use the algorithm described in the SCA assembly spec section 1.7.2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1627) alert aggregator demo feeds don't work (may be a wider problem with the way feed url's are managed in host-webapp environment)
[
https://issues.apache.org/jira/browse/TUSCANY-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino resolved TUSCANY-1627.
-
Resolution: Fixed
Can you try again with the latest trunk? it should be fixed now.
See http://www.mail-archive.com/[EMAIL PROTECTED]/msg01668.html for a
description of the issues with the Webapp integration and what I did to fix
them.
Please reopen if there are still any problems. Thanks.
alert aggregator demo feeds don't work (may be a wider problem with the way
feed url's are managed in host-webapp environment)
--
Key: TUSCANY-1627
URL: https://issues.apache.org/jira/browse/TUSCANY-1627
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SCA-0.99
Reporter: Simon Laws
Fix For: Java-SCA-1.0
Using the URL
http://localhost:8080/demo-alert-aggregator/services/AlertsFeedServiceRSS
With the alert-aggregator demo results in a 404.
This is what Tomcat prints out
28-Aug-2007 12:07:24
org.apache.tuscany.sca.binding.feed.provider.FeedBindingLis
tenerServlet doGet
INFO: FeedEndPointServlet (rss_2.0)
/demo-alert-aggregator/services/AlertsFe
edServiceRSS
28-Aug-2007 12:07:24
org.apache.tuscany.sca.binding.feed.provider.FeedBindingLis
tenerServlet doGet
I added a little extra debug and find that the path info is
INFO: FeedEndPointServlet path = /AlertsFeedServiceRSS
Having this path info means that the feed binding will ignore the request.
There is code in FeedBindingListenerServlet that, for rss feeds, only does
something if
if (path == null || path.length() == 0 || path.equals(/)) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1481) TuscanyServlet looks for servlets using path info and not the whole path
[
https://issues.apache.org/jira/browse/TUSCANY-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino resolved TUSCANY-1481.
-
Resolution: Won't Fix
When we package services in a webapp, I think that we have to accept that part
of their URIs will be ignored as host, port, and context root are fixed by the
Web container and cannot be controlled anymore by the SCA runtime embedded in
that Web container.
This is not necessarily an issue, there are other examples where part of the
service/binding URI used to publish a service is ignored or becomes irrelevant:
- localhost for example is ignored in the standalone runtime, assuming that a
service is always running on localhost, in this case the host name (or names)
cannot be controlled by the SCA runtime as it is fixed by the machine on which
it runs and its network configuration
- the complete URI can also become irrelevant in many other cases, in presence
of virtual hosting, proxies, redirections, or URI aliasing, all of which are
external to the SCA runtime.
TuscanyServlet looks for servlets using path info and not the whole path
-
Key: TUSCANY-1481
URL: https://issues.apache.org/jira/browse/TUSCANY-1481
Project: Tuscany
Issue Type: Bug
Components: Java SCA Web App Integration
Affects Versions: Java-SCA-Next
Environment: All
Reporter: Simon Laws
Fix For: Java-SCA-1.0
In the TuscanyServlet service method there is code to find a registerest
servlet
String path = ((HttpServletRequest)req).getPathInfo();
Servlet servlet = servletHost.getServlet(path);
if (servlet == null) {
throw new IllegalStateException(No servlet registered for
path: + path);
}
Currently though in the code servlets can get registered against full path
names, e,g, when the full path name is defined in WSDL, and hence the servlet
is not found. I expect it is this way as its not expecting a full path to be
specified. Why would it, the application is deployed into an already running
app server. We either need to raise an error to tell people why their
services can't be found or check for full path names.
I've dont the latter for now (see the change assoicated with this JIRA) but
would welcome some more thought on this issue as I expect the is a good
reason why it is this way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: some error when i test the samples
flying fish wrote: hi , i have some questions to ask for help , thank you at first! when i want to test the samples , like the tuscany-sca-1.0-incubator-M2-samples\standalone\calculator when i Building and Running the Samples , i input mvn -N install in , however, there are the errors informations as follows: Hi, tuscany-sca-1.0-incubator-M2-samples is from Nov 2006, a little too old :) Can you try our last published release instead? Release 0.91 is available there: http://incubator.apache.org/tuscany/sca-java-releases.html We're also about to publish release 0.99, available there: http://people.apache.org/~antelder/tuscany/0.99-RC2/ Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging and exceptions (again)
Simon Laws wrote: On 8/20/07, Simon Laws [EMAIL PROTECTED] wrote: On 8/20/07, Simon Nash [EMAIL PROTECTED] wrote: See inline. Simon Raymond Feng wrote: Comments inline. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, August 17, 2007 9:27 AM Subject: Re: Monitoring, logging and exceptions (again) [snip] ant elder wrote: And also my 2p inline... ...ant On 8/16/07, Simon Laws [EMAIL PROTECTED] wrote: A number of different requirements have been discussed and solutions proposed. My 2p (I'm using Raymond's definitions b.t.w) Tracing: Dump out input/output/exception for method calls for the purpose of debugging/troubleshooting. (Target for developers/technical support) I feel that tracing of execution paths through the Tuscany codebase would be useful but agree that it's a lot of work and will be difficult to maintain and keep consistent if we did it manually. I'm happy that this is the responsibility of whoever wants to trace through the code and not a core part of the codebase. For the Tuscany developer community AspectJ have been proposed a couple of times and support has been prototyped. We could choose SLF4J as the interface through which messages are output. I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a facade for logging APIs, so you can code to the SLF4J API and then plug in whatever logging impl you like, but if the only logging calls we have are confined to a single tracing aspect we might as well just code that aspect to a specific logging API like JDK logging. That avoids the extra dependency on SLF4J and anyone can add additional aspects if they really want to use a different logger. The main other benefit of SLF4J is its parameterized message logging (avoids all the if(logger.isDebugEnabled()) ) but again if all the logging calls are in a single aspect thats not so useful. Makes sense to me. If we go the aspectj route for tracing method entry/exit, I agree that using the JDK logger directly is simpler. Since the aspect is on the side, we're flexible. JDK logger can be default and it can be replaced easily if the embedders or users choose to do so. A few more questions on this: What dependencies will aspectj add to our distribution? aspectjweaver is more than 1Mb, do we need it? I'll try to spend some time to explore both the compile-time and load-time weaving. What about mid-method logging of specific interesting events, for example the contents of requests as the enter and leave bindings and implementation types and things like that? That sort of logging is often all a lot of users want to see not the detail tracing of every method entry/exit. Could we add things like this in specific places? +1 for the ability to produce this level of information. This is my preferred approach for debugging or understanding how some part of the code works. Having every method entry and exit produce a trace line often creates a huge amount of output that obscures the essential details of what is happening. Can this mid-method logging be split in two categories? a) Debug tracing A simple solution is to split the method in two, and then leverage the entry/exit method tracing as discussed above. In many cases this would lead to a convoluted code structure with local variables needing to be passed as parameters between the two methods, or methods that contain a single line of code (if a trace line needs to be produced from within a loop). We can use JDK logger to add statements in the middle of a method. Then we can use an aspect to capture such calls to dump out the information. For example, if we have the following statement in a method: logger.debug(...); The apsect can trap it by a point cut like call * java.util.logger.Logger.debug(..). If the logger call is already there, why is an aspect needed to trap it? Why not just let it execute? b) End-user readable information (info that a binding is sending/receiving a message for example) This falls into the second category discussed in this thread, reporting significant events to a management console. The above suggestion should help too. The key here is to have some calls to indicate such requirements and they can be then trapped to provide the concrete logic. I think we're starting to see concrete solutions for (a) with aspectj. I have not seen any real concrete proposal for (b) yet
[jira] Updated: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1605: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523647 ] Jean-Sebastien Delfino commented on TUSCANY-1605: - This turned to be a more complex issue :) 1. A bug in the SCA contribution runtime. JarContributionPackageProcessor was not creating DeployedArtifact models for folders. 2. Bugs in our embedded TomcatServer and JettyServer which didn't handle in-jar resources correctly. I am fixing (1) and (2), allowing implementation.resource components to serve in-jar resources normally. I'll also remove the workaround from the sample build.xml. web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1605) web-resource sample ant script does a compile as part of ant run
[ https://issues.apache.org/jira/browse/TUSCANY-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1605. - Resolution: Fixed web-resource sample ant script does a compile as part of ant run -- Key: TUSCANY-1605 URL: https://issues.apache.org/jira/browse/TUSCANY-1605 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-0.99, Java-SCA-Next Environment: Windowx XP Reporter: Simon Nash Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.0 In the 0.99 binary distro, the web-resource sample's ant script's run target does a compile before the run. This is contrary to our normal samples convention that ant run does not do a compile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1482) CompositeProcessor does not write out Property objects completely
[ https://issues.apache.org/jira/browse/TUSCANY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1482: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 CompositeProcessor does not write out Property objects completely - Key: TUSCANY-1482 URL: https://issues.apache.org/jira/browse/TUSCANY-1482 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model Reporter: Brent Daniel Fix For: Java-SCA-1.0 CompositeProcessor will write out a Property with its name, but will ignore other attributes such as source, many, or must supply. This is true of both component properties and composite properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1451) Fix the algorithm to determine references for an unannotated java class
[ https://issues.apache.org/jira/browse/TUSCANY-1451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1451: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Fix the algorithm to determine references for an unannotated java class --- Key: TUSCANY-1451 URL: https://issues.apache.org/jira/browse/TUSCANY-1451 Project: Tuscany Issue Type: Bug Components: Java SCA Java Implementation Extension Affects Versions: Java-SCA-Next Reporter: Raymond Feng Fix For: Java-SCA-1.0 http://www.osoa.org/display/Main/Errata+for+Java+Component+Implementation+V1.00 4. Fix and clarify algorithm for determining references of an unannotated POJO (section 1.2.7) Replace the algorithm on lines 369-377 with the following: 1) If the Java type is an interface annotated with @Remotable, then it's a reference. 2) Otherwise, if the Java type is an array whose element type is an interface annotated with @Remotable, then it's a reference. 3) Otherwise, if the Java type is a java.util.Collection or a sub-interface or sub-class of it, if the parameterized type of the collection is an interface annotated with @Remotable, then it's a reference. 4) Otherwise it's a property. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1516) Possible promotion problem with Tuscany
[ https://issues.apache.org/jira/browse/TUSCANY-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1516: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 Possible promotion problem with Tuscany --- Key: TUSCANY-1516 URL: https://issues.apache.org/jira/browse/TUSCANY-1516 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Environment: All Reporter: Hasan Muhammad Fix For: Java-SCA-1.0 Attachments: default.composite, MyServiceImpl.java, mySimpleService.composite, MyTotalService.java, MyTotalServiceImpl.java, MyTotalServiceTest.java I am experiencing a testcase failure in case of the scenario where a composite file is embedded in another and from the embedded composite we promote a service. I have attached composite files. In the testcases, if we locate a service as such and obtain the location property, the value is correct and is Durham myServiceAnother = context.locateService(MyService.class, MySimpleServiceInRecursiveAnother/MyServiceNew1); assertEquals(Durham,myServiceAnother.getLocation()); But if we locate another service from the parent composite directly as such and obtain the location property, the value is incorrect and is again Durham. myTotalServiceNew= context.locateService(MyTotalService.class, MyTotalServiceNewComponent); assertEquals(Raleigh,myTotalServiceNew.getLocation()); Shouldnt it be Raleigh in the second case since we are accessing the component/service defined in the parent component and not the promoted one from the embedded composite? I dont know where to look but is this a potential wiring problem? I will be attaching the composite files and test case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1347) IndexOutOfBoundsException thrown when trying to locate a service that includes a callback
[ https://issues.apache.org/jira/browse/TUSCANY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino updated TUSCANY-1347: Fix Version/s: (was: Java-SCA-Next) Java-SCA-1.0 IndexOutOfBoundsException thrown when trying to locate a service that includes a callback - Key: TUSCANY-1347 URL: https://issues.apache.org/jira/browse/TUSCANY-1347 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-1.0 Attachments: 1347.patch, 1347part2.patch, sca_itest_echoService.jar More complete description and test case to follow Here is the exception thrown... [6/14/07 17:59:55:187 MDT] 0020 SystemErr R java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:572) at java.util.ArrayList.get(ArrayList.java:347) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.getServiceReference(RuntimeComponentImpl.java:98) at org.apache.tuscany.sca.core.runtime.RuntimeComponentImpl.createSelfReference(RuntimeComponentImpl.java:58) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getServiceReference(EmbeddedSCADomain.java:292) at org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.getService(EmbeddedSCADomain.java:228) at org.apache.tuscany.sca.host.embedded.impl.SimpleCompositeContextImpl.locateService(SimpleCompositeContextImpl.java:80) at sca.fvt.EchoServiceImpl.asyncEcho(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1208) Service using callback and methods that don't perform callback over WS binding hangs
[
https://issues.apache.org/jira/browse/TUSCANY-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1208:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
Service using callback and methods that don't perform callback over WS
binding hangs
Key: TUSCANY-1208
URL: https://issues.apache.org/jira/browse/TUSCANY-1208
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.90
Reporter: Lou Amodeo
Assignee: Simon Nash
Fix For: Java-SCA-1.0
I have a service exposed over the WS binding. The service interface has
multiple methods. Some methods perform callbacks and others do not. The
methods that performs the callback functions while the others hang and
eventually timeout. It appears that the binding is expecting all methods to
perform a
callback. It appears that other have observed the same behavior. I have not
seen this same behavior with the default binding.
From muhwas:
yeah i had the same problem so i thought we can't
inculde sync and async method together in one
Interface. so i created two interfaces and two service
one sync and other async.
From post to list:
Service using WS Binding with Calback and multiple methods on interface hangs
Lou Amodeo
Thu, 12 Apr 2007 18:55:05 -0700
I am seeing a hang when using the Web Services bindings to access a service
that has a callback reference. In this particular case the service expose
several methods on the interface. Only one of the methods invokes a method
on the callback reference. The method that invokes the callback functions
fine. The issue is with the other methods on the interface. It appears
that the binding is expecting every request to the service to perfrom a
callback. What I have found is the latch associated with doneSignal.await()
is never freed up. Also since this method did not use invoke a callback
not sure why it would be using an Async message receiver rather than the
Sync version? Its almost as if the binding is anticipating a mandatory
callback rather than waiting for one to actually be called. After about 5
minutes the request will timeout. Thanks for your help.
*public* Axis2ServiceInOutAsyncMessageReceiver() {
}
*public* *final* *void* receive(*final* MessageContext messageCtx) {
*try* {
Object messageId = messageCtx.getMessageID();
*if* (messageId == *null*) {
messageId = *new* MessageId();
}
// Now use message id as index to context to be used by callback
// target invoker
CountDownLatch doneSignal = *new* CountDownLatch(1);
InvocationContext invCtx =
service.*new* InvocationContext(messageCtx, operation,
getSOAPFactory(messageCtx), doneSignal);
service.addMapping(messageId, invCtx);
invokeBusinessLogic(messageCtx, messageId);
*try* {
doneSignal.await();
} *catch*(InterruptedException e) {
e.printStackTrace();
Timeout occurs after 5 minutes:
[4/12/07 21:49:43:529 EDT] 002b SystemErr R Exception in thread Axis2
Task *org.apache.tuscany.spi.wire.InvocationRuntimeException*:
org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
*java.net.SocketTimeoutException*: Async operation timed out
[4/12/07 21:49:43:529 EDT] 002b SystemErr R at
org.apache.tuscany.binding.axis2.Axis2ReferenceCallback.onError(*
Axis2ReferenceCallback.java:54*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
(*OutInAxisOperation.java:417*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(*ThreadPoolExecutor.java:665*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
(*ThreadPoolExecutor.java:690*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R at java.lang.Thread.run(*
Thread.java:803*)
[4/12/07 21:49:43:539 EDT] 002b SystemErr R Caused by:
org.apache.axis2.AxisFault: Async operation timed out; nested exception is:
*java.net.SocketTimeoutException*: Async operation timed out
at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(*
HTTPTransportSender.java:271*)
at org.apache.axis2.engine.AxisEngine.send(*AxisEngine.java:464*)
at org.apache.axis2.description.OutInAxisOperationClient.send(*
OutInAxisOperation.java:325*)
at
org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run
(*OutInAxisOperation.java:400*)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
(*ThreadPoolExecutor.java:665
[jira] Updated: (TUSCANY-966) getRequestContext() does not return a Context
[
https://issues.apache.org/jira/browse/TUSCANY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-966:
---
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
Affects Version/s: (was: Java-SCA-M2)
Java-SCA-0.99
Java-SCA-0.91
getRequestContext() does not return a Context
-
Key: TUSCANY-966
URL: https://issues.apache.org/jira/browse/TUSCANY-966
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-0.91, Java-SCA-0.99
Reporter: Lou Amodeo
Assignee: Simon Nash
Fix For: Java-SCA-1.0
Remote Service hangs obtaining the request context using getRequestContext().
[INFO] [tuscany-itest:start {execution: start}]
[INFO] Starting Tuscany...
[INFO] [tuscany-itest:test {execution: test}]
[INFO] Executing tests...
CallBackApiServiceImpl message received: Knock Knock
CallBackApiServiceImpl getting request context
[INFO] Test results: {skipped=0, completedCount=1, failures=1, errors=0}
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There were test failures
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 37 seconds
[INFO] Finished at: Fri Dec 01 08:14:20 EST 2006
[INFO] Final Memory: 7M/18M
[INFO]
---
Test set: org.apache.tuscany.sca.test.CallBackApiITest
---
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 30.023 sec
FAILURE!
testCallBackBasic(org.apache.tuscany.sca.test.CallBackApiITest) Time
elapsed: 30.023 sec FAILURE!
junit.framework.ComparisonFailure: CallBackBasicITest expected:Who's There
but was:null
at junit.framework.Assert.assertEquals(Assert.java:81)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.test1(CallBackApiClientImpl.java:55)
at
org.apache.tuscany.sca.test.CallBackApiClientImpl.run(CallBackApiClientImpl.java:21)
at
org.apache.tuscany.sca.test.CallBackApiITest.testCallBackBasic(CallBackApiITest.java:12)
package org.apache.tuscany.sca.test;
import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Context;
import org.osoa.sca.CompositeContext;
import org.osoa.sca.RequestContext;
@Service(CallBackApiService.class)
public class CallBackApiServiceImpl implements CallBackApiService {
@Context
protected CompositeContext compositeContext;
protected CallBackApiCallBack callback;
public void knockKnock(String aString) {
System.out.println(CallBackApiServiceImpl message received: +
aString);
callback = this.getCallBackInterface();
callback.callBackMessage(Who's There);
System.out.println(CallBackApiServiceImpl response sent);
return;
}
private CallBackApiCallBack getCallBackInterface()
{
System.out.println(CallBackApiServiceImpl getting request context);
RequestContext rc = compositeContext.getRequestContext();
System.out.println(CallBackApiServiceImpl getting callback from
request context);
callback = (CallBackApiCallBack)
rc.getServiceReference().getCallback();
System.out.println(CallBackApiServiceImpl returning callback);
return callback;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1539) The assembly model does not contain the annotated intent information
[
https://issues.apache.org/jira/browse/TUSCANY-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Sebastien Delfino updated TUSCANY-1539:
Fix Version/s: (was: Java-SCA-Next)
Java-SCA-1.0
The assembly model does not contain the annotated intent information
Key: TUSCANY-1539
URL: https://issues.apache.org/jira/browse/TUSCANY-1539
Project: Tuscany
Issue Type: Improvement
Components: Java SCA Assembly Model
Environment: r558780
Reporter: Yang Lei
Fix For: Java-SCA-1.0
I am following JavaAnnotationsAndAPIs section 2.3.1 and 2.4 to create an
sample with both intent annotation and SCDL file. I realize no matter I
define intents or not in SCDL, it is alreays the SCDL version get picked up.
I use the following code to load the composite model:
EmbeddedSCADomain domain= new
EmbeddedSCADomain(this.getClass().getClassLoader(),http://+name);
domain.start();
ModelResolver resolver = new ModelResolverImpl(cl);
ContributionService service=
util.getDomain(null).getContributionService();
service.contribute(contributionId, contributionLocation,
resolver, false);
r service.getContribution(contributionId);
I use the following code to display the composite :
Composite composite =null;
for (DeployedArtifact artifact : contribution.getArtifacts()) {
if (artifact.getModel() instanceof Composite) {
if
(artifact.getURI().toString().endsWith(default.composite))
{
composite = ((Composite)artifact.getModel());
break;
}
}
}
if (composite!=null)
{
System.out.println(this is the artifact);
display(composite);
System.out.println(this is the added composite);
domain.getDomainCompositeHelper().addComposite(composite);
display(composite);
System.out.println(this is the started composite);
domain.getDomainCompositeHelper().startComposite(composite);
display(composite);
}
Under all 3 cases, the composite does not contain the annotated intent setting
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1497) Add full support for service references (which can be passed accross binding protocols)
[ https://issues.apache.org/jira/browse/TUSCANY-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-1497. - Resolution: Fixed Looks like this has been implemented now. Please reopen new JIRA issues for any specific limitations or bug, with a precise description of what the issue is or what needs to be implemented. Thanks. Add full support for service references (which can be passed accross binding protocols) --- Key: TUSCANY-1497 URL: https://issues.apache.org/jira/browse/TUSCANY-1497 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Reporter: Raymond Feng Assignee: Raymond Feng Fix For: Java-SCA-Next The Java spec defines CallableReference and ServiceReference. At this moment, we only have limited support for local cases (keeping pointers to java objects). We need to support the marshaling/unmarshaling of service references accross binding protocols. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
