[jira] Created: (TUSCANY-1515) The JavaBeansDataBinding does not provide an exception handler
The JavaBeansDataBinding does not provide an exception handler -- Key: TUSCANY-1515 URL: https://issues.apache.org/jira/browse/TUSCANY-1515 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Environment: svn revision 563847 Reporter: Matthew Sykes Priority: Minor Fix For: Java-SCA-Next The DefaultDataBindingExtensionPoint does explicitly omits classes that extend java.lang.Throwable from being associated with the JavaBeansDataBinding. Without an association with the JavaBeansDataBinding (or some other default databinding), fault transformations from POJO exceptions to some other databinding do not occur as the transformation chain can't be established. The symptom of this is a new TransformationException(Target fault type cannot be resolved) getting thrown from the DataTransformationInterceptor. After removing the code in the DefaultDataBindingExtensionPoint that explicitly omits java.lang.Throwable classes from being associated with the JavaBeansDataBinding, an ExceptionHandler needed to be created for the JavaBeansDataBinding. An initial, naive implementation is attached as a patch. This implementation will simply act as a holder of the original exception and return it on createException. With these changes the Exception2ExceptionTransformer was able to establish a transformation from the JavaBeansDataBinding to a custom DataBinding implementation. Further work may be needed in the exception handler. -- 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-1515) The JavaBeansDataBinding does not provide an exception handler
[ https://issues.apache.org/jira/browse/TUSCANY-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1515: --- Attachment: javabeans-exception-handler.diff Patch to allow the JavaBeansDataBinding to be associated with faults when no other databinding is associated. The JavaBeansDataBinding does not provide an exception handler -- Key: TUSCANY-1515 URL: https://issues.apache.org/jira/browse/TUSCANY-1515 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Environment: svn revision 563847 Reporter: Matthew Sykes Priority: Minor Fix For: Java-SCA-Next Attachments: javabeans-exception-handler.diff The DefaultDataBindingExtensionPoint does explicitly omits classes that extend java.lang.Throwable from being associated with the JavaBeansDataBinding. Without an association with the JavaBeansDataBinding (or some other default databinding), fault transformations from POJO exceptions to some other databinding do not occur as the transformation chain can't be established. The symptom of this is a new TransformationException(Target fault type cannot be resolved) getting thrown from the DataTransformationInterceptor. After removing the code in the DefaultDataBindingExtensionPoint that explicitly omits java.lang.Throwable classes from being associated with the JavaBeansDataBinding, an ExceptionHandler needed to be created for the JavaBeansDataBinding. An initial, naive implementation is attached as a patch. This implementation will simply act as a holder of the original exception and return it on createException. With these changes the Exception2ExceptionTransformer was able to establish a transformation from the JavaBeansDataBinding to a custom DataBinding implementation. Further work may be needed in the exception handler. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
[ https://issues.apache.org/jira/browse/TUSCANY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1452: --- Attachment: (was: clone.diff) InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Fix For: Java-SCA-Next Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
[ https://issues.apache.org/jira/browse/TUSCANY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1452: --- Attachment: clone-2.diff Patch to make InterfaceContract, Interface, and Operation Cloneable. The previous attachment did not make a deep copy of the inputType associated with the operation and that caused the reference interface contract that was cloned to be effected by updates to the binding interface contract. InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Fix For: Java-SCA-Next Attachments: clone-2.diff Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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-1452) InterfaceContract and its associated objects should be Cloneable
[ https://issues.apache.org/jira/browse/TUSCANY-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1452: --- Attachment: clone.diff Patch to make InterfaceContract, Interface, and Operation Cloneable. InterfaceContract and its associated objects should be Cloneable Key: TUSCANY-1452 URL: https://issues.apache.org/jira/browse/TUSCANY-1452 Project: Tuscany Issue Type: Improvement Components: Java SCA Assembly Model, Java SCA Core Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91, Java-SCA-Next Reporter: Matthew Sykes Attachments: clone.diff Given the current infrastructure in 0.90, it is difficult for a binding provider to setup a binding-specific databinding on the binding InterfaceContract because the InterfaceContract, Interface, and Operation model objects can't be easily cloned. While the binding providers are allowed to give the runtime an InterfaceContract for the binding, if the data describing the interface comes from something other than the binding configuration the binding will typically use the InterfaceContract from the componentType. Without a way to copy the InterfaceContract, the binding provider will need to create an interface from scratch by using one of the interface processors or the assembly model factories and custom logic. For example, the axis2 binding will use the portType from wsdl document associated with the binding.ws ... element in scdl to create an InterfaceContract or the binding. This approach requires the WebServiceBindngProcessor to access the interface introspector and introspect an interface contract. I've discussed this a bit with Raymond who has agreed that making the InterfaceContract, Interface, Operation, and associated objects cloneable would allow a binding provider implementation to get an instance of the interface contract that could be updated with a binding-specific databinding. This is similar to what existed in the M2 branches of days gone by. -- 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: Supporting callbacks across Web Services
I did notice that the code that is responsible for creating the callback wires / invocation chains out of createWires on the service side is currently commented out in the CompositeActivatorImpl. When that code is uncommented I found that the callback proxy was injected as there were callback wires associated with the service. Even when the proxy is injected, the rest of the issues you've raised still come into play. I'm interested in the progress you make here as I'm also trying to figure out how to make callbacks work when the callback target is not local to the composite containing the service. Right now it seems that callbacks only work when the reference and service are associated with components in the same composite as the callback target. I think some of this is due to how Tuscany treats the concept of the default binding and extends it to hold a direct reference to the target component associated with the binding. In particular, within the CompositeActivatorImpl, the createWires method that deals with the reference side will create the callback wires with endpoint references that hold pointers to the runtime components on both sides of the wire. With the target service in hand, you can add the callback wire to the service side as is done at the end of createWires. Since the wire deals with RuntimeComonent instances on the source and target, everything works fine with an implementation interceptor. When the implementation interceptors are not added and only the binding interceptors exist on the wire, I'm not sure how to connect up the two. Simon Nash wrote: In my investigations into TUSCANY-1341, I'have fixed a few minor blocking defects (see my updates to the JIRA) and I'm now getting to the heart of the problem. I think the right approach is to do this in a similar way to callbacks over direct local wires, with the forward call proceeding as normal and a callback proxy being injected on the service side to make a reverse call back to the client instance using the same Web services connection thar was used for the forward call from client to server. This isn't the approach used by the current code. So far I have got this path working as far as the attempt to call back using the service's proxy. The code to inject this proxy isn't working properly yet. I'm not yet sure how callbacks should be mapped to the protocol used by the Web services connection. There need to be standard mappings for this, or SCA callbacks won't interoperate with non-SCA Web service endpoints. I'm hoping Axis2 provides a way to call back from a server to a client over an already established connection, but I haven't looked into this in detail yet. I'm hoping my fix will support callback from both two-way methods and one-way methods. (The spec seems to imply that both of these are valid.) The two-way case seems harder because the callback invocation will be sent back on the wire before the forward invocation has returned its response message. If it's too hard to do this, I may back off and only support callbacks from one-way methods for now. This seems to present challenges as well, because I'm not sure whether the connection is guaranteed to remain active after the one-way call has been made and the server method is running. Before I go further down this path, I would welcome any comments on the above issues and whether my basic approach is sound. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-1344) Tuscany does not provide a loader for the binding.sca / elements in scdl
[ https://issues.apache.org/jira/browse/TUSCANY-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505380 ] Matthew Sykes commented on TUSCANY-1344: When the artifact processor is created, createSCABindings in CompositeBuilderImpl will need to be a little bit smarter about how and when it overwrites the uri attributes on the bindings. In particular, on the reference side, the uri could point to the target but the current implementation will set it to the URI of the reference. Tuscany does not provide a loader for the binding.sca / elements in scdl -- Key: TUSCANY-1344 URL: https://issues.apache.org/jira/browse/TUSCANY-1344 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 Priority: Trivial There doesn't appear to be a StAXArtifactProcessor capable of reading and serializing binding.sca / elements in the scdl. -- 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-1344) Tuscany does not provide a loader for the binding.sca / elements in scdl
Tuscany does not provide a loader for the binding.sca / elements in scdl -- Key: TUSCANY-1344 URL: https://issues.apache.org/jira/browse/TUSCANY-1344 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 Priority: Trivial There doesn't appear to be a StAXArtifactProcessor capable of reading and serializing binding.sca / elements in the scdl. -- 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-1345) Many StAXArtifactProcessor implementations read policy but do not write it
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 Affects Versions: Java-SCA-0.90, Java-SCA-0.91 Environment: sca-java-0.90 Reporter: Matthew Sykes Priority: Minor 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]
[jira] Created: (TUSCANY-1346) Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components
Resolution to TUSCANY-1332 assumes a closed top-level composite that does not support addition of new components Key: TUSCANY-1346 URL: https://issues.apache.org/jira/browse/TUSCANY-1346 Project: Tuscany Issue Type: Bug Components: Java SCA Assembly Model, Java SCA Core Runtime, Java SCA Embedded Runtime Affects Versions: Java-SCA-0.90, Java-SCA-0.91 Reporter: Matthew Sykes The resolution to TUSCANY-1332 involved exploitation of the composite include function to include all known deployable composites into the domain such that the components contained within the deployable composites would be wired together when the domain level composite was activated. While this resolved the issues of wiring across multiple composites contained within different contributions, this approach requires that the system know of all composites that may be part of the domain at the time the domain is activated. When embedding Tuscany in a server runtime, however, deployment and activation of composites may occur after the domain is activated. With the current implementation that is contained with EmbeddedSCADomain, runtimes that consume Tuscany would have to stop and restart the domain composite to deploy and activate new components and their services. While this may be appropriate for small systems, it's not workable in complex environments. I believe Tuscany needs a wiring and activation model that is more dynamic such that components can be added to (or removed from) the domain and wired after the domain composite was initially activated. This flexibility would have implications to the way wiring is done and how multiplicity is validated as the shape of the domain changes. -- 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-1331) createSelfReferences resultes in SCA binding references with $self$ style URIs
createSelfReferences resultes in SCA binding references with $self$ style URIs -- Key: TUSCANY-1331 URL: https://issues.apache.org/jira/browse/TUSCANY-1331 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-0.90 Environment: sca-java-0.90, IBM JDK5 Reporter: Matthew Sykes Fix For: Java-SCA-Next, Java-SCA-0.90 During a discussion on the behavior of the implementation of createSelfReference, rfeng had indicated that the URI of the original service binding should have been preserved when creating the reference binding: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL PROTECTED] In the current implementation, SCABinding instances are created based on the generated name of the reference and, as such, the URI from the target service was not preserved. As a quick hack to get around the issue, I've changed CompositeBuilderImpl's createSCABindings to remove the $self$. from the reference binding's URI but I expect this is not an appropriate way to address 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]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. Any ideas on how this could be implemented without forcing the bindings to understand $self$ references? Thanks. ant elder wrote: I think its actually a bug in the jsonrpc binding that its using the component self reference, but that aside, this still seems odd to me. Just because a particular binding is on a service how can it be sure that that same binding will work as a reference? Some binding's don't support references, some have different attributes for services or references, on some binding's the URI may include the reference name so this would end up including $self$ in the URI. ...ant On 5/18/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The self references are created to support the ComponentContext.createSelfReference() in a consistent way as regular references. In your case, if the binding.jsonrpc is declared under the component, then the component can only be assessed over jsonrpc binding (not even SCA binding). And the component will be exposed as a json-rpc service. So invoking the json-rpc reference handler is the correct behavior from the client side. Thanks, Raymond -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CompositeBuilderImpl.createSelfReferences creates a $self$ reference using the service binding
Sebastien, I should say that I'm working on a default binding that replaces the Tuscany implementation. The URI isn't changed but new references are created with target URIs that are unknown to the binding implementation on the service side. CompositeBuilderImpl.createSelfReferences creates new references for each service and sets the name to $self$.servicename. Later wireComposite iterates over each of the references and finds the new $self$ references and associates it with the default binding. On paths where SCARuntime.getService is called, createSelfReference eventually follows and the Reference passed back to the caller is one that holds generated uri. As the reference's target URI doesn't point to a service exposed at that URI, invocations through the reference are failing. I can see how I might work around this in the binding but I'm not sure that I should have to. ;) Thanks. Jean-Sebastien Delfino wrote: Matthew Sykes wrote: I'm actually bumping up against one of the problems that ant has described - the creation of $self$ reference URIs. I don't believe a binding implementation should have to expect to deal with odd URI's that were generated by the runtime and I'm curious how bindings are supposed to know what to do with each of forms that are invented. In the case of the binding implementation I'm working with, the reference binding uses the uri to determine the target service. When the URI is changed it is no longer valid as no service exists with at the modified URI. I'm trying to understand the problem that you're running into, and I'm not sure why the URI would change. A new self reference created in CompositeBuilderImpl.createSelfReferences actually points to the original bindings of the service that the reference is created for. So as far as I can tell, the URI used by the reference is the same (meaning exactly the same object) as the URI declared on the service's binding. So if the URI changes there's a bigger problem, as it's probably going to break the service itself... Are you actually seeing the URI change? do you have a test case that I could use to debug that? Thanks. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Brief guide for extending Tuscany
Raymond, Will this be updated when the 0.90 branch is out? I was going to take a look at it but deferred after reading Ignacio's comment that This guide seems to be obsolete already. Thanks. Raymond Feng wrote: Hi, I uploaded a brief guide for extending Tuscany to the following wiki page. Please review and help improve it. http://cwiki.apache.org/confluence/download/attachments/51879/ExtendingTuscany.ppt Thanks, Raymond - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r531727 - Bring up of helloworld-ws and helloworld-wsclient WS binding samples
...ant [1] http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tuscany Java sca package names
+1 Raymond Feng wrote: Hi, I would suggest that we defer this renaming for two reasons: 1) We're in the middle of settling down the SPIs and core and such as massive renaming will be disturbing. 2) I prefer that we either rename all the packages or none, but not just one module. If we really want to do so for this release, I think the best time would be when we cut the first RC. Thanks, Raymond - Original Message - From: Venkata Krishnan [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 01, 2007 1:31 AM Subject: Re: Tuscany Java sca package names HI, As we had discussed in the IRC, I plan to change the package names in core-spi module to include 'sca'. I plan to do this on Tuesday, 24.00 Hrs - Pacific Time (US Canada) unless I hear of objections to it. Please plan your commits accordingly. Thanks. - Venkat On 5/1/07, Simon Nash [EMAIL PROTECTED] wrote: I can see that the renamed APIs would be more consistent across Tuscany, which is an advantage. It is a matter of balancing this against the work and disruption involved in making the change. I don't feel strongly either way, but on balance I think it would make sense to do this renaming either now or after the next release. Simon Raymond Feng wrote: Hi, I think a massive of package renaming is disturbing at this point. Since SDO and DAS already have the unique prefixes and there won't be any conflicts, I would suggest that we keep the short package name org.apache.tuscany for SCA. Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Monday, April 30, 2007 12:59 AM Subject: Tuscany Java sca package names The DAS and SDO sub projects use Java package names org.apache.tuscany.dasand org.apache.tuscany.sdo but the SCA sub project uses org.apache.tuscany. As the next release is attempting to stabilize all the externals I wondered if we should change this now to be be org.apache.tuscany.sca, does anyone have feelings either way? ...ant - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Monitoring, logging, and exceptions (was: Re: Notifcation of missing extensions)
Hi, As a user and a consumer of Tuscany that has had to debug problems, I have a couple of comments. Raymond Feng wrote: It seems to me that we could use the EventManagement in the core to handle these in the event/listener pattern. If possible, I would like to see Tuscany focus on the higher level event model for component management, on enhancing the exception formatter framework for diagnostics, and improving the wiring, contribution, and assembly validation in a way that would surface errors and an error context to extensions that could be implemented by a consumer. I was referring to the fact that the apsectj-based tracing can be enabled or disabled simply by turning on/off the JVM agent. The annotation-based aspect doesn't require a compiler for the aspectj and it's not invasive. On using aspects for trace, I'm not a huge fan of performing any weaving at runtime during class loading nor in requiring consumers to install an instrumentation agent to turn on trace emission. Not only does dynamic instrumentation lengthen the class load time and effect the benefits of class sharing (in JVM's that support the technology), it assumes that the user has installed the agent because a problem is expected. If aspect weaving is used, I believe it should be an optional part of the build environment and not force fit into the instrumentation agent infrastructure. Thanks. -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit 496794
Ignacio, I think the updated code implements the behavior described in the assembly spec. There was another thread related to callbacks where Dave Booz helped to clarify some of the use cases. http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12874.html I think this update may also resolve TUSCANY-1052. Ignacio Silva-Lepe wrote: Hi Jim, I am not sure I follow the modification to ConnectorImpl. You remove the check for operationHasCallback altogether in the forward direction and add a check for isOneWayOperation in the callback direction. As far I understand, Operation.isNonBlocking (which determines the value of isOneWayOperation) is only true when there is a @OneWay annotation. Are we supposed to use @OneWay explicitly to make forward and callback methods non-blocking now? It seems to me to be the only way in which ConnectorImpl can produce the right outcome as it currently stands. If so, is the spec going to change to require the use of @OneWay for this purpose? At the moment, both the simplecallback and the inner.composite samples do not work properly. -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Callback methods w/ non-void return types
Based on Dave's comments and the current behavior, I've opened http://issues.apache.org/jira/browse/TUSCANY-1052 so we don't lose this discussion. scabooz wrote: I don't understand why we'd force the client to handle responses asyncly if it doesn't want to. It is by choice as you said. In this use case, the client wants a sync response. I think the use case is going to be common, that's why it's in the spec. Dave -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1052) Bi-directional intefaces are assumed to be non-blocking but are not required to be
Bi-directional intefaces are assumed to be non-blocking but are not required to be -- Key: TUSCANY-1052 URL: https://issues.apache.org/jira/browse/TUSCANY-1052 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2, Java-M3 Environment: Tuscany revision 495535 Reporter: Matthew Sykes Fix For: Java-M3 Tuscany assumes that the forward operation of a bi-directional interface is non-blocking with respect to the client while the spec does not require that. Based on this assumption, Tuscany's implementation treats the forward operation as if it never returns anything but void and does not raise exceptions. This assumption generally results in an NPE on the client as the NonBlockingBridgingInterceptor was used in wiring. For further information, please see the development list thread associated http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12511.html . According to that thread, this behavior is not compliant with the Assembly specification. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-1052) Bi-directional intefaces are assumed to be non-blocking but are not required to be
[ https://issues.apache.org/jira/browse/TUSCANY-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Sykes updated TUSCANY-1052: --- Description: Tuscany assumes that the forward operation of a bi-directional interface is non-blocking with respect to the client while the spec does not require that. Based on this assumption, Tuscany's implementation treats the forward operation as if it never returns anything but void and does not raise exceptions. This assumption generally results in an NPE on the client as the NonBlockingBridgingInterceptor was used in wiring. For further information, please see the development list threads associated with http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12511.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12780.html . According to those threads, this behavior is not compliant with the Assembly specification as written. was: Tuscany assumes that the forward operation of a bi-directional interface is non-blocking with respect to the client while the spec does not require that. Based on this assumption, Tuscany's implementation treats the forward operation as if it never returns anything but void and does not raise exceptions. This assumption generally results in an NPE on the client as the NonBlockingBridgingInterceptor was used in wiring. For further information, please see the development list thread associated http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12511.html . According to that thread, this behavior is not compliant with the Assembly specification. Added additional message pointer. Bi-directional intefaces are assumed to be non-blocking but are not required to be -- Key: TUSCANY-1052 URL: https://issues.apache.org/jira/browse/TUSCANY-1052 Project: Tuscany Issue Type: Bug Components: Java SCA Core Affects Versions: Java-M2, Java-M3 Environment: Tuscany revision 495535 Reporter: Matthew Sykes Fix For: Java-M3 Tuscany assumes that the forward operation of a bi-directional interface is non-blocking with respect to the client while the spec does not require that. Based on this assumption, Tuscany's implementation treats the forward operation as if it never returns anything but void and does not raise exceptions. This assumption generally results in an NPE on the client as the NonBlockingBridgingInterceptor was used in wiring. For further information, please see the development list threads associated with http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12511.html and http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg12780.html . According to those threads, this behavior is not compliant with the Assembly specification as written. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Callback methods w/ non-void return types
Jim, I'm interested in the answer to this as well. I think we all understand that non-blocking operations must have void return types. The question really boils down to whether or not bidirectional services are considered non-blocking. I have a simple piece of code that uses a bidirectional service in which the service and callback operations both return data. The code currently fails with an NPE because the ConnectorImpl code uses the NonBlockingBridgingInterceptor when a callback is defined. I can't see anything in the spec that would preclude this. Thanks. Scott Kurz wrote: Jim, OK, but are all callback operations necessarily non-blocking? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Callback methods w/ non-void return types
Ignacio, Thank you for the response. I have a couple more questions and comments that I'll put inline. Ignacio Silva-Lepe wrote: FWIW, I'll try to respond to both Scott and Matt. Say we have a bi- directional interface consisting of FI.cf and BI.cb, where FI is the forward half and BI is the backward half. We agree that both the call forward method cf and the callback method cb return void. I think you made a couple of leaps that I didn't when I was reading the specs. In my case both FI.cf and BI.cb have non-void return types on the defined operations and they may be defined to raise exceptions. I didn't see in the spec where the operations were required to have void types and no exceptions. The client that calls FI.cf is expecting the target service to provide a result from the operation that is not going to be delivered to it via the callback but synchronously when the service operation completes. In this case the callback is used for some other purpose. I'm not saying that this example isn't a bit contrived but I can't see where it is disallowed in the spec. Further, the notion of non-blocking calls seems orthogonal to bidirectional interfaces. If the call to FI.cf blocked, the question then would be until when and what for? The client would block until the service returned the result so the client could get the result of the service. Since the result to cf will be coming in the invocation to cb, there seems to be no purpose in blocking cf, and unblocking it would require some coordination, e.g. with the call to cb, by the system. Here's where you've made another leap that I didn't. In your use-case, the client is basically dropping a piece of work on the service and expecting the service to call back with the response when the work is complete. I believe that's the most likely pattern for this model but I don't believe it's the only one. Based on my interpretation of what exists in the specs today, if this was the desired behavior, FI.cf should have adhered to the requirements of a non-blocking operation and been annotated with @OneWay to indicate it was non-blocking. As for the call to cb (by the service that implements cf) the local implementation is actually blocking, it does not seem to be necessary to spawn another thread for this. Does this address what you were trying to get at? Not really. I think what I'm really trying to find out is if the specs need to be more explicit such that they mandate bidirectional interfaces must adhere to the non-blocking signature pattern where the return types must be void and no exceptions can be thrown. If, however, the information in the 0.95 assembly spec is worded correctly, I don't believe the current Tuscany implementation adheres to it. Given the above, the connector assumes that a bi-directional interface is non-blocking an inserts a NonBlockingBridgingInterceptor, which in turn assumes that the return type of the forward call is void and thus returns a message with a null body, which is probably the cause of your NPE. Agreed. My point is that I don't think the NonBlockingBridgingInterceptor should have been used in my example as the client is expecting a synchronous result from FI.cf. Thanks again. -- Matthew Sykes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Move SCA tools and wsdl-java plugins to SDO tree?
Jeremy, I think where these should end up is dependent how the tools are positioned within the Tuscany project. While the wsdl2java tool currently generates interfaces with SDO parameters, will there ever be extensions to support other data binding types? Considering WSDL is a first class interface definition language in the SCA space, it seems more natural to have these tools available in that space with. Finally, I believe the SCA side of the tree has the Axis2 dependencies while the SDO side does not. The last time I looked at WSDL 2 Java it seemed to delegate most of the function to the Axis2 implementation and simply added a new emitter. Does it make sense to introduce that dependency on the SDO side? -- Matthew Sykes Jeremy Boynes wrote: Looking at modularizing the tree, it seems to me that the tools and java2wsdl/wsdl2java plugins don't actually have any dependency on SCA - they are tools for generating java/wsdl interfaces with SDO DataObjects. In light of that, I think they might be better off as part of the SDO tree - does anyone have any issues with moving them there? -- Jeremy - 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]
[jira] Created: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages
Tuscany WSDL2Java can't handle WSDL fault messages -- Key: TUSCANY-978 URL: http://issues.apache.org/jira/browse/TUSCANY-978 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Environment: Tuscany Java-M2 and current trunk Reporter: Matthew Sykes I've been playing with the BigBank sample and have added a fault to the AccountService's withdraw operation. After changing the AccountService.wsdl (attached), the Tuscany WSDL2Java no longer works: [INFO] Generating Java service interfaces from /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account [INFO] [INFO] Trace java.lang.IllegalArgumentException: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) ... 19 more Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1618) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.loadOperations(AxisServiceBasedMultiLanguageEmitter.java:1533) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:740
[jira] Updated: (TUSCANY-978) Tuscany WSDL2Java can't handle WSDL fault messages
[ http://issues.apache.org/jira/browse/TUSCANY-978?page=all ] Matthew Sykes updated TUSCANY-978: -- Attachment: AccountService.wsdl WSDL in a more convenient form... Tuscany WSDL2Java can't handle WSDL fault messages -- Key: TUSCANY-978 URL: http://issues.apache.org/jira/browse/TUSCANY-978 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-M2 Environment: Tuscany Java-M2 and current trunk Reporter: Matthew Sykes Attachments: AccountService.wsdl I've been playing with the BigBank sample and have added a fault to the AccountService's withdraw operation. After changing the AccountService.wsdl (attached), the Tuscany WSDL2Java no longer works: [INFO] Generating Java service interfaces from /home/sykesm/oss-code/tuscany/sca-java-M2/samples/applications/bigbank/account/src/main/resources/wsdl/AccountService.wsdl [INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account [INFO] [INFO] Trace java.lang.IllegalArgumentException: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:244) at org.apache.tuscany.tools.wsdl2java.plugin.WSDL2JavaGeneratorMojo.execute(WSDL2JavaGeneratorMojo.java:134) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.axis2.wsdl.codegen.CodeGenerationException: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:178) at org.apache.tuscany.tools.wsdl2java.generate.WSDL2JavaGenerator.generateFromWSDL(WSDL2JavaGenerator.java:242) ... 19 more Caused by: org.apache.axis2.wsdl.databinding.UnmatchedTypeException: No type was mapped to the name insufficientFundsFault with namespace http://www.bigbank.com/account at org.apache.axis2.wsdl.databinding.TypeMappingAdapter.getTypeMappingName(TypeMappingAdapter.java:73) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultParamElements(AxisServiceBasedMultiLanguageEmitter.java:1958) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.getFaultElement(AxisServiceBasedMultiLanguageEmitter.java:1867) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.generateMethodElement(AxisServiceBasedMultiLanguageEmitter.java:1618
Tuscany WSDL2Java
(AxisServiceBasedMultiLanguageEmitter.java:1533) at org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.createDOMDocumentForInterface(AxisServiceBasedMultiLanguageEmitter.java:740) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceEmitter.writeInterface(JavaInterfaceEmitter.java:196) at org.apache.tuscany.tools.wsdl2java.generate.JavaInterfaceGenerator.generate(JavaInterfaceGenerator.java:174) ... 20 more -- Matthew Sykes ?xml version=1.0 encoding=UTF-8? !-- * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * License); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, * software distributed under the License is distributed on an * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY * KIND, either express or implied. See the License for the * specific language governing permissions and limitations * under the License. -- wsdl:definitions xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:account=http://www.bigbank.com/account; targetNamespace=http://www.bigbank.com/account; name=AccountService wsdl:types xsd:schema targetNamespace=http://www.bigbank.com/account; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:account=http://www.bigbank.com/account; !-- xmlns:sdojava=commonj.sdo/java sdojava:package=org.apache.tuscany.samples.bigbank.account -- !-- xsd:complexType name=DataGraphRoot xsd:sequence xsd:element name=customerProfileData type=account:CustomerProfileData maxOccurs=unbounded minOccurs=0 / xsd:element name=StockSummaries type=account:StockSummary maxOccurs=unbounded minOccurs=0 / xsd:element name=AccountSummaries type=account:AccountSummary maxOccurs=unbounded minOccurs=0 / xsd:element name=StockLogEntries type=account:StockLogEntry maxOccurs=unbounded minOccurs=0 / xsd:element name=AccountLogEntries type=account:AccountLogEntry maxOccurs=unbounded minOccurs=0 / /xsd:sequence /xsd:complexType-- xsd:element name=getAccountReport xsd:complexType xsd:sequence xsd:element name=customerID type=xsd:int / /xsd:sequence /xsd:complexType /xsd:element xsd:element name=getAccountReportResponse xsd:complexType xsd:sequence xsd:element name=accountReport type=account:AccountReport / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=AccountReport xsd:sequence xsd:element name=accountSummaries type=account:AccountSummary maxOccurs=unbounded / xsd:element name=stockSummaries type=account:StockSummary maxOccurs=unbounded / /xsd:sequence /xsd:complexType xsd:complexType name=AccountSummary xsd:attribute name=accountNumber type=xsd:string / xsd:attribute name=accountType type=xsd:string / xsd:attribute name=balance type=xsd:float / /xsd:complexType xsd:complexType name=StockSummary !-- xsd:attribute name=id type=xsd:int / -- xsd:attribute name=purchaseLotNumber type=xsd:int / !-- unique id for this purchase -- xsd:attribute name=symbol type=xsd:string / xsd:attribute name=quantity type=xsd:int / xsd:attribute name=purchaseDate type=xsd:dateTime / xsd:attribute name=purchasePrice type=xsd:float / xsd:attribute name=currentPrice type=xsd:float / xsd:attribute name=company type=xsd:string / xsd:attribute name=highPrice type=xsd:float / xsd:attribute name=lowPrice type=xsd:float / /xsd:complexType !-- Profile in data base -- xsd:element name=getCustomerProfile xsd:complexType xsd:sequence xsd:element name=loginID type=xsd:string / /xsd:sequence /xsd:complexType /xsd:element xsd:complexType name=CustomerProfileData xsd:sequence xsd:element name=firstName type=xsd:string / xsd:element name=lastName type=xsd:string / xsd:element name=address type=xsd:string / xsd:element name=email type=xsd:string / xsd:element name=loginID type=xsd:string / xsd:element name=password type=xsd:string / xsd:element name=id type=xsd:int / /xsd:sequence /xsd:complexType xsd:element name=getCustomerProfileResponse xsd:complexType xsd:sequence xsd:element name=customerProfile type=account:CustomerProfileData / /xsd:sequence /xsd:complexType /xsd:element xsd:element name=withdraw xsd:complexType xsd:sequence
Re: maven-assembly-plugin version?
If Jervis hit the same issue I did, the problem was that the 2.2-SNAPSHOT is now dependent on org.codehaus.plexus:plexus-archiver:1.0-alpha-7-SNAPSHOT which wasn't available in any of the configured repositories. I ended up pulling it from snapshots.repository.codehaus.org to resolve the dependency. Jeremy Boynes wrote: IIRC the 2.1 version caused the build to be run twice. We have been using the snapshot for a while - what problems did you see? -- Jeremy On Aug 10, 2006, at 2:04 AM, Liu, Jervis wrote: Hi, The maven-assembly-plugin version we used (2.2-SNAPSHOT) caused a lot of problems in my build. Is there any reason why we cant use the stable version 2.1? I have tried 2.1, it works fine. Thanks, Jervis - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: adding an interceptor
Jim, I'd be interested in contributing to this but I'm not sure I know exactly where to begin. If you're willing to spend a bit of time on the QA necessary to describe the intended flow through the bindings, wires invocation handlers, and policy handlers (using some of Jeremy's presentation as a starting point), I'm in. Thanks. Jim Marino wrote: Greg, We don't have this finished yet but it would be a nice project for someone to work on, particularly since it would involve figuring out how we are going to support SCA policy. If you or someone else is interested in tackling this (or part of it) let me know and I'll help out. Jim On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote: I am trying to understand how to add an interceptor to an invocation chain. It looks like at one point this was accomplished by a implementing a TargetPolicyBuilder and registering it with the PolicyBuilderRegistry. However in the current code base it looks to me like the PolicyBuilderRegistry is no longer instantiated. Is this broken or has this been replaced by some other mechanism? Greg Dritschler - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use extensions with the standalone launcher?
FWIW, I think I've been running into a problem at build time because of this exact issue. There's a bit of code in the javascript sample HelloWorldTestCase.java test that gathers up all of the META-INF/sca/default.scdl resources it can find. The test then throws away the first resource in the enumeration assuming it's the application's default.scdl and not the extension's default.scdl. ant elder wrote: I guess it somehow needs to find the URL to the default.scdl for the JavaScript extension, but thats just in a jar on the classpath and there's lots of default.scdl resources on the class path so how does it know which is the JavaScript one? And the once it has that URL it isn't real obvious (to me) how you could use that from the testcase to get the extension registered with the runtime. ...ant While the build generally succeeds, every once in a while the test fails with an UnrecognizedElementException on implementation.js. I added a System.out.println to the test to show which of the resources was thrown away in the following code snippet and found that the extension scdl can be discarded instead of the application scdl. (I'm assuming this is because enumeration that comes back from getResources doesn't have a specfied order.) At this point I guess I have to wonder if the name used for the extensions' scdl should be something different from the default application scdl name? It seems like it might be nice to do something like gather up like all of the visible META-INF/sca/extension.scdl resources and add them to the runtime as extensions. I don't believe this would be at odds with the current extensions mechanism in the DirectoryScanExtender if it went after extension.scdl instead of default.scdl. Just a thought. -- Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-574) URISyntaxException from launcher when jars reside in windows Maven repository
URISyntaxException from launcher when jars reside in windows Maven repository
-
Key: TUSCANY-574
URL: http://issues.apache.org/jira/browse/TUSCANY-574
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core
Environment: Win XP, J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060511
(SR2)
Reporter: Matthew Sykes
Priority: Trivial
When attempting to run maven from various samples directories:
[INFO] [surefire:test]
[INFO] Surefire report directory:
C:\cygwin\home\sykesm\oss-code\tuscany\java\samples\sca\calculator\target\surefire-reports
---
T E S T S
---
Running calculator.CalculatorTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.38 sec
FAILURE!
testCalculator(calculator.CalculatorTestCase) Time elapsed: 0.31 sec
ERROR!
java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:854)
at
org.apache.tuscany.core.launcher.Launcher.getInstallDirectory(Launcher.java:177)
at
org.apache.tuscany.core.launcher.Launcher.bootRuntime(Launcher.java:104)
at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:40)
at calculator.CalculatorTestCase.setUp(CalculatorTestCase.java:32)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 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.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
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.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
Caused by: java.net.URISyntaxException: Illegal character in path at index 18:
file:/C:/Documents and
Settings/sykesm/.m2/repository/org/apache/tuscany/core/1.0-SNAPSHOT/core-1.0-SNAPSHOT.jar
at java.net.URI$Parser.fail(URI.java:2821)
at java.net.URI$Parser.checkChars(URI.java:2994)
at java.net.URI$Parser.parseHierarchical(URI.java:3078)
at java.net.URI$Parser.parse(URI.java:3026)
at java.net.URI.init(URI.java:590)
at java.net.URI.create(URI.java:852)
This appears to be due to how the Launcher teases out the directory containing
the Tuscany code. Since the default location for the maven repository on
windows has spaces in the directory names, the URI that was used was not
valid. In order to get past this I made a very simple change:
$ svn diff
Index: sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
===
--- sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
(revision 425392)
+++ sca/core/src/main/java/org/apache/tuscany/core/launcher/Launcher.java
(working copy)
@@ -168,13 +168,15 @@
if (!jar.equals(url.getProtocol())) {
throw new IllegalStateException(Must be run from a jar: + url);
}
+
String jarLocation = url.toString();
jarLocation = jarLocation.substring(4, jarLocation.lastIndexOf(!/));
if (!jarLocation.startsWith(file:)) {
throw new IllegalStateException(Must be run from a local
filesystem: + jarLocation);
}
+jarLocation = jarLocation.substring(5);
-File jarFile = new File(URI.create(jarLocation));
+File jarFile = new File(jarLocation);
return jarFile.getParentFile().getParentFile();
}
}
This may not be an appropriate change
