Re: Strange problem with conversational service when using binding.ws
shouldn't this be part of FAQ? On 3/31/08, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody( TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected( TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected( BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod( TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java :45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod ( TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run( TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected( TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected( BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run( TestClassRunner.java :52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run( TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests( RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
[jira] Commented: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584039#action_12584039
]
Venkatakrishnan commented on TUSCANY-2171:
--
Yes, that sound cleaner. Am going ahead with it. Thanks Sebastien.
- Venkat
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.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-2178) Deleting a node throws Javascript error in admin
Deleting a node throws Javascript error in admin Key: TUSCANY-2178 URL: https://issues.apache.org/jira/browse/TUSCANY-2178 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Deleting a node in the admin console does not work and throws a Javascript error. That's a timing issue as the admin sends two AJAX requests to first stop the node and then delete it, but in most cases the delete call jumps the line and gets invoked before the stop, causing the stop action to fail. A simple fix is to invoke these two steps from the server side. -- 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-2179) Plugin installation from update site does not say 1.2-incubating
Plugin installation from update site does not say 1.2-incubating Key: TUSCANY-2179 URL: https://issues.apache.org/jira/browse/TUSCANY-2179 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The plugin update site references the Tuscany bin distribution (installed as part of the plugin install) as runtime.jar, causing the install dialog to just say 'runtime.jar' instead of 'apache-tuscany-1.2-incubating'. -- 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]
Fixes for TUSCANY-2178 and TUSCANY-2179 in 1.2
I just made two small fixes for TUSCANY-2178 and 2179, committed in trunk under SVN revisions r643318 and r643319. The fixes are really isolated so I'd like to merge them into the 1.2 branch if possible. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange problem with conversational service when using binding.ws
Why does it run fine when there is a method returning non-void, even though that method is not invoked!! ++Vamsi On Tue, Apr 1, 2008 at 4:09 AM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke ( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody( TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected( TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected( BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod( TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java :45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod ( TestClassMethodsRunner.java:75) at org.junit.internal.runners.TestClassMethodsRunner.run( TestClassMethodsRunner.java:36) at org.junit.internal.runners.TestClassRunner$1.runUnprotected( TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected( BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run( TestClassRunner.java :52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run( JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run( TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(
[jira] Created: (TUSCANY-2180) Cannot invoke method on Service that implements multiple @Remotable interfaces with methods of the same name
Cannot invoke method on Service that implements multiple @Remotable interfaces
with methods of the same name
Key: TUSCANY-2180
URL: https://issues.apache.org/jira/browse/TUSCANY-2180
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
Environment: SVN Revision 643322
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Fix For: Java-SCA-Next
When a Component implementation class implements multiple @Remotable interfaces
which have methods with the same name, it is not possible to invoke the
duplicate method name on the second Remotable interrface.
Consider the following example:
I have two @Remotable services as defined by the following Java interfaces:
@Remotable
public interface LocalTimeService {
Date getCurrentTime();
}
@Remotable
public interface WorldTimeService {
Date getCurrentTime(String timeZone);
}
I have a single Java Component that implements both of these @Remotable
Interfaces:
@Service(interfaces = {LocalTimeService.class, WorldTimeService.class})
public void class TimeServiceImpl implements LocalTimeService, WorldTimeService
{
public Date getCurrentTime() {
// Code not shown
}
public Date getCurrentTime(String timeZone) {
// Code not shown
}
}
If I invoke getCurrentTime(), the code will work
If I invoke getCurrentTime(GMT), the code will fail. The stack trace is:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:266)
at
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:101)
at $Proxy20.getCurrentTime(Unknown Source)
at detail removed.test(BServiceImpl.java:41)
--
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: Strange problem with conversational service when using binding.ws
Thanks Simon for pointing to the JIRA. I will take a look at TUSCANY-2059. ++Vamsi On Tue, Apr 1, 2008 at 3:22 PM, Simon Nash [EMAIL PROTECTED] wrote: Comments inline. Simon Raymond Feng wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. This is the same as TUSCANY-2059. The behaviour that Raymond describes is the default for Axis2. However, Tuscany has code in Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix up the Axis2 Java to WSDL mapping to correct this Axis2 problem. Unfortunately, this code is currently not invoked when all methods of an interface have null argument lists and void return types. See TUSCANY-2059 for more details. Adding @OneWay works around the problem but it changes the semantic behavior. It prevents server-side exceptions from being thrown back to the client, and it allows the client to proceed before the server method has completed. It also requires modifying the existing Java interface, which isn't always possible. This may be useful as a temporary workaround, but we need to fix the underlying problem. Vamsi, are you interested in producing a patch for Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix this problem? The comments for TUSCANY-2059 give some suggestions for what is neeeded. Simon Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody( TestMethodRunner.java:99) at
STP SCA Component - STP SCA Tools sub project
Hi, I'm Stéphane Drapeau from Obeo. I work on tools for SCA and I lead the Eclipse SCA component which is a component of the STP project [1]. Currently, I'm writing a proposal to change the status of the STP SCA * component* to STP/SCA Tools *sub project*. I would like know if I can refer Tuscany community as interested party of our proposal. It's purely administrative. Jean Sebastien told me that the Tuscany community must vote on this issue. So the discussion is open ;) Thanks very much. Best regards Stéphane Drapeau Obeo [1]: http://www.eclipse.org/stp/sca/index.php
Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Jean-Sebastien Delfino wrote: scabooz wrote: Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave And the other trick is to allow processing of artifacts with errors to proceed as well in dev, debug and admin scenarios as well. For example we should be able to load a composite with errors in it, in the admin tool, to show these errors to the administrator and allow him to fix them. Basically it's the same idea as a with Java editor. A Java editor that wouldn't allow you to edit Java classes with errors wouldn't be very useful :) That means: Not throwing an exception that stops everything on the first error, but instead report errors through the monitors that we already have in various places in the code. I agree with this statement that everything should not stop on the first error. To reuse my compiler analogy, I wouldn't like the compiler to report only one error every time I run it. However, this doesn't mean that the faulty class should only produce a warning that allows execution to proceed. It should still produce an error that causes deployment of this application to fail, but the error should be handled in a way that allows it to be batched with other similar errors to give the user a consolidated failure report. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (TUSCANY-2170) Synchronizing the access to SCADefinitions
[ https://issues.apache.org/jira/browse/TUSCANY-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584098#action_12584098 ] Ramkumar Ramalingam commented on TUSCANY-2170: -- Learnt that using Vectors OR Collections.synchronizedList synchronizes your list object. However, the iterators implemented in the java.util Collections classes are fail-fast, which means that if one thread changes a collection while another thread is traversing it through an Iterator, the next Iterator.hasNext() or Iterator.next() call will throw ConcurrentModificationException. If we have to prevent ConcurrentModificationException, we must lock the entire List while you are iterating by wrapping it with a synchronized block, which inturn is costly. As a solution to the above problem, the CopyOnWriteArrayList class from util.concurrent (which will also appear in the java.util.concurrent package in JDK 1.5) is a thread-safe implementation of ArrayList that offers far better concurrency. Multiple reads can almost always execute concurrently, simultaneous reads and writes can usually execute concurrently, and multiple simultaneous writes can often execute concurrently. Also CopyOnWriteArrayList contains a mutable reference to an immutable array, so as long as that reference is held fixed, you get all the thread-safety benefits of immutability without the need for locking. Hence i believe the best solution would be to go with CopyOnWriteArrayList instead of the current ArrayList used to store the list of policy sets, intents, binding types etc. Please suggest me if this one is the right approach. Thanks. Synchronizing the access to SCADefinitions -- Key: TUSCANY-2170 URL: https://issues.apache.org/jira/browse/TUSCANY-2170 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: SVN revision 642920 - Windows Reporter: Ramkumar Ramalingam Priority: Minor Fix For: Java-SCA-Next http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.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] Commented: (TUSCANY-2180) Cannot invoke method on Service that implements multiple @Remotable interfaces with methods of the same name
[
https://issues.apache.org/jira/browse/TUSCANY-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584106#action_12584106
]
Mark Combellack commented on TUSCANY-2180:
--
I've raised this scenario with the OASIS SCA Assembly TC to see if it is valid
to do this. The replies basically said that yes, it is valid.
See http://lists.oasis-open.org/archives/sca-assembly/200803/msg00100.html
Cannot invoke method on Service that implements multiple @Remotable
interfaces with methods of the same name
Key: TUSCANY-2180
URL: https://issues.apache.org/jira/browse/TUSCANY-2180
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
Environment: SVN Revision 643322
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Fix For: Java-SCA-Next
When a Component implementation class implements multiple @Remotable
interfaces which have methods with the same name, it is not possible to
invoke the duplicate method name on the second Remotable interrface.
Consider the following example:
I have two @Remotable services as defined by the following Java interfaces:
@Remotable
public interface LocalTimeService {
Date getCurrentTime();
}
@Remotable
public interface WorldTimeService {
Date getCurrentTime(String timeZone);
}
I have a single Java Component that implements both of these @Remotable
Interfaces:
@Service(interfaces = {LocalTimeService.class, WorldTimeService.class})
public void class TimeServiceImpl implements LocalTimeService,
WorldTimeService {
public Date getCurrentTime() {
// Code not shown
}
public Date getCurrentTime(String timeZone) {
// Code not shown
}
}
If I invoke getCurrentTime(), the code will work
If I invoke getCurrentTime(GMT), the code will fail. The stack trace is:
java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:266)
at
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:101)
at $Proxy20.getCurrentTime(Unknown Source)
at detail removed.test(BServiceImpl.java:41)
--
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: Strange problem with conversational service when using binding.ws
Comments inline. Simon Raymond Feng wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. This is the same as TUSCANY-2059. The behaviour that Raymond describes is the default for Axis2. However, Tuscany has code in Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix up the Axis2 Java to WSDL mapping to correct this Axis2 problem. Unfortunately, this code is currently not invoked when all methods of an interface have null argument lists and void return types. See TUSCANY-2059 for more details. Adding @OneWay works around the problem but it changes the semantic behavior. It prevents server-side exceptions from being thrown back to the client, and it allows the client to proceed before the server method has completed. It also requires modifying the existing Java interface, which isn't always possible. This may be useful as a temporary workaround, but we need to fix the underlying problem. Vamsi, are you interested in producing a patch for Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix this problem? The comments for TUSCANY-2059 give some suggestions for what is neeeded. Simon Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.junit.internal.runners.TestMethodRunner.executeMethodBody( TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected( TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected( BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod( TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java :45) at
Adding OASIS spec changes to the Tuscany SCA implementation (TUSCANY-2164)
TUSCANY-2164 describes an issue that has been resolved in OASIS as ASSEMBLY-27. The current implementation is correct according to the OSOA 1.0 specs, but there are good reasons to change it to align with the OASIS resolution of this issue. This raises the general question of how Tuscany should handle differences between the OSOA and OASIS specs. Changes made by OASIS can fall into the following categories: 1. Fixing clear errors in the spec. 2. Clarfication of ambiguities or inconsistencies. 3. Minor improvements. 4. Major changes. For categories 1 and 2, Tuscany is incorporating these on an ongoing basis. For category 4, I'd suggest that we hold off on these for now until the OASIS work gets further along. For category 3, I think we should look at these changes on a case by case basis and decide whether to incorporate them. For all categories, I think it would be useful to maintain a Wiki page that lists the OASIS issue resolutions that are currently incorporated in the Tuscany SCA Java implementation. For OASIS issue ASSEMBLY-27 (TUSCANY-2164), I think the OASIS change is an improvement and we should implement it in Tuscany. What do others think about any or all of the above? Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @OneWay over binding.ws problems and problems with supporting iTest
Lou Amodeo wrote:
Hi, I am seeing an issue where @OneWay operations over binding.ws are not
having the parameters serialized properly. I tried to verify that an iTest
existed for this case but found that the oneway iTest appears not to be
operational and it wouldn't catch the problem that I am seeing. From the
oneway iTest service impl below you can see that the method argument count
is not being referenced. In my
situation my argument is a string and the value passed into the method is
null resulting in a NPE. I tried uncommenting the
code below to see if count was being de-serialized properly but when i run
the iTest i get a messsage indicatding no tests were found to run. So
this is a 2-part issue. a) are there any working tests using a @OneWay
over binding.ws that prove method parameters are being serialized properly?
b) Is this iTest working?Thanks!
The test case is currently disabled. (We usually do this by renaming
xxxTestCase.java to xxxTestCaseFIXME.java.) I don't know why it was
disabled. I re-enabled it in my test environment and it failed.
I'm looking into what is wrong with it now.
Simon
package org.apache.tuscany.sca.itest.oneway.impl;
import org.apache.tuscany.sca.itest.oneway.OneWayService;
/**
* The service for the oneway itest
*
* @version $Rev: 537240 $ $Date: 2007-05-11 18:35:03 +0100 (Fri, 11 May
2007) $
*/
public class OneWayServiceImpl implements OneWayService {
public static int callCount = 0;
public void doSomething(int count){
synchronized(this){
callCount++;
}
//System.out.println(Service: doSomething + count + callCount = +
callCount);
//System.out.flush();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ApacheCon US submissions
Hi All, Is anyone thinking of submitting an abstract to ApacheCon US? FYI: The deadline is Thursday April 3rd (see http://www.us.apachecon.com/us2008/). A quick search for SOA or Tuscany on the current submissions gave no hits, so I'm assuming there aren't any so far. I was thinking of submitting one talking about the use of Apache Felix for modularizing of Apache Tuscany (lesson learned from applying modularity after the fact...)...giving LOTS of credit to Rajini!! Regards, Graham. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon US submissions
2008/4/1, Graham Charters [EMAIL PROTECTED]: Hi All, Is anyone thinking of submitting an abstract to ApacheCon US? FYI: The deadline is Thursday April 3rd (see http://www.us.apachecon.com/us2008/). A quick search for SOA or Tuscany on the current submissions gave no hits, so I'm assuming there aren't any so far. I was thinking of submitting one talking about the use of Apache Felix for modularizing of Apache Tuscany (lesson learned from applying modularity after the fact...)...giving LOTS of credit to Rajini!! If were in Europe I'll submit my paper about the workpool. Regards, Graham. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ciao, Giorgio. --- Giorgio Zoppi [EMAIL PROTECTED] You're not your job. You're not how much money you have in the bank. You're not the car you drive. You're not the contents of your wallet. You're not your fucking khakis. You're the all-singing, all-dancing crap of the world. - Tyler Durden (Fight Club) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Simon Nash wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave And the other trick is to allow processing of artifacts with errors to proceed as well in dev, debug and admin scenarios as well. For example we should be able to load a composite with errors in it, in the admin tool, to show these errors to the administrator and allow him to fix them. Basically it's the same idea as a with Java editor. A Java editor that wouldn't allow you to edit Java classes with errors wouldn't be very useful :) That means: Not throwing an exception that stops everything on the first error, but instead report errors through the monitors that we already have in various places in the code. I agree with this statement that everything should not stop on the first error. To reuse my compiler analogy, I wouldn't like the compiler to report only one error every time I run it. However, this doesn't mean that the faulty class should only produce a warning that allows execution to proceed. It should still produce an error that causes deployment of this application to fail, but the error should be handled in a way that allows it to be batched with other similar errors to give the user a consolidated failure report. Simon OK that's fair. I still think that preventing any 'deployment' is too strong, but I can live with it for now and we'll see over time how that evolves. So if I understand correctly: a) error checking will proceed allowing reporting of a batch of errors b) deployment will not proceed I may even feel better about it if we precise 'deployment' a bit. Did you mean: - installation of a contribution on the domain - inclusion of a composite in the domain - allocation of components to a node - starting these components What was your idea here? which one would proceed, which one would fail? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vtest] new Jira component
I have added a new jira component named Java SCA Verification Tests and I will start opening issues for specific areas of the Java Annotations and APIs specification that require testing. Thanks, --Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange problem with conversational service when using binding.ws
Hi Simon, I have set a break point in Java2WSDLHelper.processNoArgAndVoidReturnMethods() at line 341. But, with my test case, I am not hitting the condition where types is null as described in the JIRA comments in TUSCANY-2059. ++Vamsi On Tue, Apr 1, 2008 at 3:22 PM, Simon Nash [EMAIL PROTECTED] wrote: Comments inline. Simon Raymond Feng wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. This is the same as TUSCANY-2059. The behaviour that Raymond describes is the default for Axis2. However, Tuscany has code in Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix up the Axis2 Java to WSDL mapping to correct this Axis2 problem. Unfortunately, this code is currently not invoked when all methods of an interface have null argument lists and void return types. See TUSCANY-2059 for more details. Adding @OneWay works around the problem but it changes the semantic behavior. It prevents server-side exceptions from being thrown back to the client, and it allows the client to proceed before the server method has completed. It also requires modifying the existing Java interface, which isn't always possible. This may be useful as a temporary workaround, but we need to fix the underlying problem. Vamsi, are you interested in producing a patch for Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix this problem? The comments for TUSCANY-2059 give some suggestions for what is neeeded. Simon Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at org.apache.tuscany.sca.itest.conversational.ConversationWSDLMyTestCase.testConversation (ConversationWSDLMyTestCase.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at
[jira] Commented: (TUSCANY-2112) Add conversational intents as described in the assembly spec
[ https://issues.apache.org/jira/browse/TUSCANY-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584206#action_12584206 ] Vamsavardhana Reddy commented on TUSCANY-2112: -- http://www.osoa.org/jira/browse/ASSEMBLY-47 seemingly relates to marking operations on the interface with endsConversation, oneWay, etc. Add conversational intents as described in the assembly spec Key: TUSCANY-2112 URL: https://issues.apache.org/jira/browse/TUSCANY-2112 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: All Reporter: Simon Laws Assignee: Vamsavardhana Reddy Priority: Minor Fix For: Java-SCA-Next I've been looking at the parts for the assembly spec that deal with conversational semantics and there are a couple of gaps when compared with the current TUscany implementation. In particular Tuscany only supports annotations in Java interfaces when declaring conversational behaviour. Section 1.5.3 describes the use of policy intents for specifying conversational behaviour 819 interface type. Note that it is also possible for a service or a reference to set the conversational 820 intent when using an interface which is not marked with the conversational intent. This can be 821 useful when reusing an existing interface definition that does not contain SCA information. I assume this meansa service could have a conversational intent component name=ConversationalServiceStateless implementation.java class=org.apache.tuscany.sca.itest.conversational.impl.ConversationalServiceStatelessImpl/ service name=ConversationalService requires=Conversational interface.java interface=org.apache.tuscany.sca.itest.conversational.ConversationalService callbackInterface=org.apache.tuscany.sca.itest.conversational.ConversationalCallback / binding.ws/ callback binding.ws/ /callback /service /component as could a reference component name=ConversationalStatelessClientStatefulService implementation.java class=org.apache.tuscany.sca.itest.conversational.impl.ConversationalClientStatelessImpl/ reference name=conversationalReferenceClient target=ConversationalReferenceClient/ reference name=conversationalService requires=Conversational target=ConversationalServiceStateful interface.java interface=org.apache.tuscany.sca.itest.conversational.ConversationalService callbackInterface=org.apache.tuscany.sca.itest.conversational.ConversationalCallback / binding.ws/ callback binding.ws/ /callback /reference reference name=conversationalService2 target=ConversationalServiceStateful binding.ws/ /reference /component It's not clear from the spec if there should be an EndsConversation intent for operations. These intents would drive the existing underlying conversational functionality by augmenting the interface model will appropriate conversation information. -- 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]
[vTest] Wiki content
I would like to add page to our wiki devoted to vtest development. I see this as a place where we can provide a mapping from the specification set to specific test buckets and also as a place to track progress. Any thoughts? -- Kevin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange problem with conversational service when using binding.ws
Aah... types is not null but types.getExtensibilityElements() is empty which results in document being null as described in the JIRA comments. ++Vamsi On Tue, Apr 1, 2008 at 10:25 PM, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi Simon, I have set a break point in Java2WSDLHelper.processNoArgAndVoidReturnMethods() at line 341. But, with my test case, I am not hitting the condition where types is null as described in the JIRA comments in TUSCANY-2059. ++Vamsi On Tue, Apr 1, 2008 at 3:22 PM, Simon Nash [EMAIL PROTECTED] wrote: Comments inline. Simon Raymond Feng wrote: Hi, The message is a bit misleading and it complains that a fault from WS stack cannot be mapped to a java checked exception. The cause of your issue is: Caused by: org.apache.axis2.AxisFault: An unknown message label has been encountered: In at org.apache.axis2.description.OutOnlyAxisOperationClient.getMessageContext ( OutOnlyAxisOperation.java:215) at I ran into a similar issue before. The problem is that Axis2 maps a java method such as void doSomthing(...) into an oneway WSDL operation. This behavior is not in line with SCA which requires @Oneway annotation. If you add @Oneway to the method, the problem will be gone. This is the same as TUSCANY-2059. The behaviour that Raymond describes is the default for Axis2. However, Tuscany has code in Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix up the Axis2 Java to WSDL mapping to correct this Axis2 problem. Unfortunately, this code is currently not invoked when all methods of an interface have null argument lists and void return types. See TUSCANY-2059 for more details. Adding @OneWay works around the problem but it changes the semantic behavior. It prevents server-side exceptions from being thrown back to the client, and it allows the client to proceed before the server method has completed. It also requires modifying the existing Java interface, which isn't always possible. This may be useful as a temporary workaround, but we need to fix the underlying problem. Vamsi, are you interested in producing a patch for Java2WSDLHelper.processNoArgAndVoidReturnMethods() to fix this problem? The comments for TUSCANY-2059 give some suggestions for what is neeeded. Simon Thanks, Raymond -- From: Vamsavardhana Reddy [EMAIL PROTECTED] Sent: Monday, March 31, 2008 6:38 AM To: tuscany-dev@ws.apache.org Subject: Strange problem with conversational service when using binding.ws Here is a strange problem I am running into. I have a conversational service with all the operations returning void. When I use binding.sca, my test runs fine. But, when I change the binding to binding.ws, I hit an org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null. But, if a add another method to my service to return a String (non-void basically), then my test runs fine even though this newly added method is not invoked!! Stack trace from the failure is given below. org.osoa.sca.ServiceRuntimeException: Target fault type cannot be resolved: null at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke (DataTransformationInterceptor.java:134) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy26.operation1(Unknown Source) at org.apache.tuscany.sca.mytest.MyConvClientImpl.runConversation( MyConvClientImpl.java:21) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke (JavaImplementationInvoker.java:109) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke( SCABindingInvoker.java:61) at org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke ( PassByValueInterceptor.java:108) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:286) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke( JDKInvocationHandler.java:154) at $Proxy25.runConversation(Unknown Source) at
Re: [vTest] Wiki content
+1. It's good to track gaps between Tuscany and SCA specs. Thanks, Raymond -- From: Kevin Williams [EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 10:15 AM To: tuscany-dev@ws.apache.org Subject: [vTest] Wiki content I would like to add page to our wiki devoted to vtest development. I see this as a place where we can provide a mapping from the specification set to specific test buckets and also as a place to track progress. Any thoughts? -- Kevin - 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: [vTest] Wiki content
Kevin Williams wrote: I would like to add page to our wiki devoted to vtest development. I see this as a place where we can provide a mapping from the specification set to specific test buckets and also as a place to track progress. +1 - A page like this would be quite useful. -- Thanks, Dan Becker - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2171) binding.sca bindingType in definitions.xml not used if SCA binding is created during build phase
[
https://issues.apache.org/jira/browse/TUSCANY-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Venkatakrishnan resolved TUSCANY-2171.
--
Resolution: Fixed
Fixed in r643489.
binding.sca bindingType in definitions.xml not used if SCA binding is created
during build phase
Key: TUSCANY-2171
URL: https://issues.apache.org/jira/browse/TUSCANY-2171
Project: Tuscany
Issue Type: Bug
Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Venkatakrishnan
I have a definitions.xml file which defines a bindingType for binding.sca.
bindingType type=sca:binding.sca mayProvide=propagatesTransaction/
I have a composite which uses an intent on a reference.
reference name=daService target=DataAccessComponent
requires=propagatesTransaction/
The reference does not have a binding.sca element. In this case the
binding model object is created by
CompositeConfigurationBuilderImpl.createSCABinding() which is shown below.
private SCABinding createSCABinding() {
SCABinding scaBinding = scaBindingFactory.createSCABinding();
IntentAttachPointType bindingType =
intentAttachPointTypeFactory.createBindingType();
bindingType.setName(BINDING_SCA_QNAME);
bindingType.setUnresolved(true);
((PolicySetAttachPoint)scaBinding).setType(bindingType);
return scaBinding;
}
This method creates an IntentAttachPointType which is unresolved. There is
no code to resolve the IntentAttachPointType to the real one. As a result
the PolicyComputer uses the unresolved IntentAttachPointType model and does
not realize that binding.sca provides the intent needed by the reference.
Discussed on tuscany-dev here:
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28903.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]
Re: Reporting errors for illegal SCA annotations (TUSCANY-2140)
Jean-Sebastien Delfino wrote: Simon Nash wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Hi Folks, +1 for warnings when the application is developed. +1 for Errors when you put the application into production. The trick is to know the difference between deployment for UT vs. deployment for real. :-) Dave And the other trick is to allow processing of artifacts with errors to proceed as well in dev, debug and admin scenarios as well. For example we should be able to load a composite with errors in it, in the admin tool, to show these errors to the administrator and allow him to fix them. Basically it's the same idea as a with Java editor. A Java editor that wouldn't allow you to edit Java classes with errors wouldn't be very useful :) That means: Not throwing an exception that stops everything on the first error, but instead report errors through the monitors that we already have in various places in the code. I agree with this statement that everything should not stop on the first error. To reuse my compiler analogy, I wouldn't like the compiler to report only one error every time I run it. However, this doesn't mean that the faulty class should only produce a warning that allows execution to proceed. It should still produce an error that causes deployment of this application to fail, but the error should be handled in a way that allows it to be batched with other similar errors to give the user a consolidated failure report. Simon OK that's fair. I still think that preventing any 'deployment' is too strong, but I can live with it for now and we'll see over time how that evolves. So if I understand correctly: a) error checking will proceed allowing reporting of a batch of errors b) deployment will not proceed I may even feel better about it if we precise 'deployment' a bit. Did you mean: - installation of a contribution on the domain - inclusion of a composite in the domain - allocation of components to a node - starting these components What was your idea here? which one would proceed, which one would fail? I would say that the error should be reported at the point that is most natural to detect it. This would be when the related artifacts are first broken open by the runtime. In this case, the error is on a service interface, which needs to be introspected as part of building the domain wiring model. I would expect this to happen when the containing composite is included in the domain. If this understanding is correct, I think that's when this error and other errors detected at that stage should be reported. Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ApacheCon US submissions
Graham Charters wrote: Hi All, Is anyone thinking of submitting an abstract to ApacheCon US? FYI: The deadline is Thursday April 3rd (see http://www.us.apachecon.com/us2008/). A quick search for SOA or Tuscany on the current submissions gave no hits, so I'm assuming there aren't any so far. I was thinking of submitting one talking about the use of Apache Felix for modularizing of Apache Tuscany (lesson learned from applying modularity after the fact...)...giving LOTS of credit to Rajini!! For a succcessful submission it's necessary to have a topic that's of broad appeal, which generally means it should provide practical hands-on information that people can use. So you'ld need to use the Tuscany/Felix experience to draw out practical lessons and best practices for modularity that people can apply to their own projects. If this is what you have in mind, I think it's a good candidate for submission. Simon Regards, Graham. - 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: @OneWay over binding.ws problems and problems with supporting iTest
Simon Nash wrote:
Lou Amodeo wrote:
Hi, I am seeing an issue where @OneWay operations over binding.ws
are not
having the parameters serialized properly. I tried to verify that an
iTest
existed for this case but found that the oneway iTest appears not to be
operational and it wouldn't catch the problem that I am seeing. From
the
oneway iTest service impl below you can see that the method argument
count
is not being referenced. In my
situation my argument is a string and the value passed into the method is
null resulting in a NPE. I tried uncommenting the
code below to see if count was being de-serialized properly but when i
run
the iTest i get a messsage indicatding no tests were found to run. So
this is a 2-part issue. a) are there any working tests using a @OneWay
over binding.ws that prove method parameters are being serialized
properly?
b) Is this iTest working?Thanks!
I have a fix for the problems with the test case but I couldn't
apply it because of some svn issue with a file being out of date.
I'm looking into this and should be able to resolve it soon.
I have now resolved the conflicting change that was blocking my
previous commit, and I have committed the fixes needed to get
itest/oneway working. This is revision r643539.
It now runs OK for me but I agree that it doesn't do a great job
of testing parameter marshalling for OneWay methods. Any contributions
to improve it would be most welcome!
Simon
Simon
package org.apache.tuscany.sca.itest.oneway.impl;
import org.apache.tuscany.sca.itest.oneway.OneWayService;
/**
* The service for the oneway itest
*
* @version $Rev: 537240 $ $Date: 2007-05-11 18:35:03 +0100 (Fri, 11 May
2007) $
*/
public class OneWayServiceImpl implements OneWayService {
public static int callCount = 0;
public void doSomething(int count){
synchronized(this){
callCount++;
}
//System.out.println(Service: doSomething + count + callCount = +
callCount);
//System.out.flush();
}
}
-
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: [vtest] new Jira component
I am interested in helping with this. Regards Gilbert Kwan Kevin Williams [EMAIL PROTECTED] il.comTo tuscany-dev@ws.apache.org 04/01/2008 12:16 cc PM[EMAIL PROTECTED] Subject [vtest] new Jira component Please respond to [EMAIL PROTECTED] ache.org I have added a new jira component named Java SCA Verification Tests and I will start opening issues for specific areas of the Java Annotations and APIs specification that require testing. Thanks, --Kevin - 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: ApacheCon US submissions
Hi Simon, what you describe is exactly what I had in mind :-) Regards, Graham. On 01/04/2008, Simon Nash [EMAIL PROTECTED] wrote: Graham Charters wrote: Hi All, Is anyone thinking of submitting an abstract to ApacheCon US? FYI: The deadline is Thursday April 3rd (see http://www.us.apachecon.com/us2008/). A quick search for SOA or Tuscany on the current submissions gave no hits, so I'm assuming there aren't any so far. I was thinking of submitting one talking about the use of Apache Felix for modularizing of Apache Tuscany (lesson learned from applying modularity after the fact...)...giving LOTS of credit to Rajini!! For a succcessful submission it's necessary to have a topic that's of broad appeal, which generally means it should provide practical hands-on information that people can use. So you'ld need to use the Tuscany/Felix experience to draw out practical lessons and best practices for modularity that people can apply to their own projects. If this is what you have in mind, I think it's a good candidate for submission. Simon Regards, Graham. - 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]
[jira] Resolved: (TUSCANY-2175) Plugin does not properly log errors and release its progress monitor
[ https://issues.apache.org/jira/browse/TUSCANY-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2175. - Resolution: Fixed Plugin does not properly log errors and release its progress monitor Key: TUSCANY-2175 URL: https://issues.apache.org/jira/browse/TUSCANY-2175 Project: Tuscany Issue Type: Bug Components: Java SCA Tools Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 That makes it really difficult to investigate errors or even know when it has finished launching a composite. The fix is a simple risk free fix, add calls to log errors and release the progress monitor in a finally block. -- 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: STP SCA Component - STP SCA Tools sub project
Stéphane Drapeau wrote: Hi, I'm Stéphane Drapeau from Obeo. I work on tools for SCA and I lead the Eclipse SCA component which is a component of the STP project [1]. Currently, I'm writing a proposal to change the status of the STP SCA * component* to STP/SCA Tools *sub project*. I would like know if I can refer Tuscany community as interested party of our proposal. It's purely administrative. Jean Sebastien told me that the Tuscany community must vote on this issue. So the discussion is open ;) Thanks very much. Best regards Stéphane Drapeau Obeo [1]: http://www.eclipse.org/stp/sca/index.php Hi Stephane, Thanks for posting here, it'll enable the whole Tuscany community to get involved in the discussion around your SCA editor proposal. Can you tell us a bit more about the proposal? do you have an outline? Also can you help us understand what it means to be listed under interested parties in such a proposal? Any questions or thoughts from others on the list? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2181) Minor fixes to samples README and .html files
Minor fixes to samples README and .html files - Key: TUSCANY-2181 URL: https://issues.apache.org/jira/browse/TUSCANY-2181 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Priority: Minor Fix For: Java-SCA-1.2 While reviewing the 1.2 samples, I'm seeing typos and minor issues with the README and some of the .html files. I'll fix the ones I see carefully as I go through them. I'll make the fixes in both trunk and the 1.2 branch. -- 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: Fixes for TUSCANY-2178 and TUSCANY-2179 in 1.2
Sure, please go ahead and add them to the SCA 1.2 branch. Just make sure we use the proper version for the distribution artifacts in the fix for TUSCANY-2179, as it looks like you have the 1.2-SNAPSHOT version in trunk (where it should be 2.0-SNAPSHOT). On Tue, Apr 1, 2008 at 1:28 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I just made two small fixes for TUSCANY-2178 and 2179, committed in trunk under SVN revisions r643318 and r643319. The fixes are really isolated so I'd like to merge them into the 1.2 branch if possible. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TUSCANY-1974, was Re: [SCA 1.2] Release Status and RC plans
Sure, please go ahead and add the fix to 1.2 branch. On Mon, Mar 31, 2008 at 9:40 AM, ant elder [EMAIL PROTECTED] wrote: Not risky - just that when I added the fix to the jira I'd not done much testing at all other than to confirm it fixed the problem, i've done a bit more testing now and all the samples i've tried seem ok. I'm away right now so cant try every sample and demo we have though sorry. ...ant On Mon, Mar 31, 2008 at 5:19 PM, Luciano Resende [EMAIL PROTECTED] wrote: Hi Ant, In this JIRA, you added a comments that this was little risky, how comfortable are you with adding this into SCA 1.2 ? Have you tested this with other webapps and no side effects ? On Mon, Mar 31, 2008 at 8:31 AM, ant elder [EMAIL PROTECTED] wrote: I've just committed fixes for TUSCANY-1948 and TUSCANY-1974 to trunk in r643022, r643023 and r643024, the changes seem ok from the testing i've done so how about including these in 1.2? ...ant On Mon, Mar 31, 2008 at 8:12 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresendehttp://people.apache.org/%7Elresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SCA 1.2] Release Status and RC plans
Sure, please go ahead and add the fix for the two Jiras to SCA 1.2 branch. On Mon, Mar 31, 2008 at 8:31 AM, ant elder [EMAIL PROTECTED] wrote: I've just committed fixes for TUSCANY-1948 and TUSCANY-1974 to trunk in r643022, r643023 and r643024, the changes seem ok from the testing i've done so how about including these in 1.2? ...ant On Mon, Mar 31, 2008 at 8:12 AM, Luciano Resende [EMAIL PROTECTED] wrote: I'd like to get the following JIRAs fixed before we cut the Java SCA 1.2 RC3. This should give us a much better release candidate, and possible our last one. I'm currently working on TUSCANY-2167, and it looks like Sebastien might be getting TUSCANY-2146 ready... so any help with TUSCANY-2150 and TUSCANY-2166 would be appreciated. As for plans to cut the next RC, I'd like to target tomorrow EOD, if we are ready. Thoughts ? [1] https://issues.apache.org/jira/browse/TUSCANY-2146 [2] https://issues.apache.org/jira/browse/TUSCANY-2150 [3] https://issues.apache.org/jira/browse/TUSCANY-2166 [4] https://issues.apache.org/jira/browse/TUSCANY-2167 -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Parsing the wsdl file,is part element name must equals operation's name?
Hi,all
When Parsing the wsdl file,there is a constraint that the element name of the
part on the operation input messge must equals the operation's name.
I don't find the constraint on the wsdl spec,so I think the constraint should
be removed.
The snippet :
Part part = (Part)parts.iterator().next();
QName elementName = part.getElementName();
if (elementName == null) {
return null;
}
if (!operation.getName().equals(elementName.getLocalPart())) {
return null;
}
If this is a bug,I will put a jira.
--
Wang Feng
2008-04-02
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fixes for TUSCANY-2178 and TUSCANY-2179 in 1.2
Luciano Resende wrote: Sure, please go ahead and add them to the SCA 1.2 branch. Just make sure we use the proper version for the distribution artifacts in the fix for TUSCANY-2179, as it looks like you have the 1.2-SNAPSHOT version in trunk (where it should be 2.0-SNAPSHOT). On Tue, Apr 1, 2008 at 1:28 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I just made two small fixes for TUSCANY-2178 and 2179, committed in trunk under SVN revisions r643318 and r643319. The fixes are really isolated so I'd like to merge them into the 1.2 branch if possible. -- Jean-Sebastien Ah thanks! good catch, I'll merge into the branch then and will fix trunk to use 2.0-incubating-SNAPSHOT. Thanks -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Should I be able to put a WS binding on a service of a component w/ Composite impl?
Should this work? composite name=OuterComposite component name=OuterCalculatorComponent service name=OuterCalculatorService binding.ws wsdlElement=/ /service implementation.composite name=calc:InnerComposite/ /component /composite composite name=InnerComposite service name=OuterCalculatorService promote=CalculatorComponent/CalculatorService/ component name=CalculatorComponent service name=CalculatorService/ implementation.java class=calculator.CalculatorServiceImpl/ /component /composite -- I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget with a Composite impl. This causes a problem when RuntimeWireImpl.initInvocationChains() calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain. Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services? I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet. Thanks, Scott
Re: Parsing the wsdl file,is part element name must equals operation's name?
Hi,
Thank you for looking into this. It's a feature instead of a bug :-).
The code in
org.apache.tuscany.sca.interfacedef.wsdl.impl.WSDLOperationIntrospectorImpl.Wrapper.getInputChildElements()
is to check if the WSDL operation is document-literal-wrapper style per
JAX-WS spec (section 2.3.1.2). If the operation name doesn't match the
wrapper element name, then it is not a wrapper style and we don't care about
child elements in this case.
You are welcome to report any suspicions if you run into any issues with
your WSDL.
Thanks,
Raymond
--
From: Wang Feng [EMAIL PROTECTED]
Sent: Tuesday, April 01, 2008 7:14 PM
To: tuscany-dev tuscany-dev@ws.apache.org
Subject: Parsing the wsdl file,is part element name must equals operation's
name?
Hi,all
When Parsing the wsdl file,there is a constraint that the element name of
the part on the operation input messge must equals the operation's name.
I don't find the constraint on the wsdl spec,so I think the constraint
should be removed.
The snippet :
Part part = (Part)parts.iterator().next();
QName elementName = part.getElementName();
if (elementName == null) {
return null;
}
if (!operation.getName().equals(elementName.getLocalPart())) {
return null;
}
If this is a bug,I will put a jira.
--
Wang Feng
2008-04-02
-
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: Parsing the wsdl file,is part element name must equals operation's name?
Hi,
I believe this check is only a constraint in determining if this WSDL
operation qualifies for wrapped mapping according to the JAX-WS spec. If
this does not hold we can still accept this WSDL, but we'll treat it as
nonwrapped and when mapping to Java, say, we'll use the nonwrapped style
mapping.
Scott
On Tue, Apr 1, 2008 at 10:14 PM, Wang Feng [EMAIL PROTECTED] wrote:
Hi,all
When Parsing the wsdl file,there is a constraint that the element name of
the part on the operation input messge must equals the operation's name.
I don't find the constraint on the wsdl spec,so I think the constraint
should be removed.
The snippet :
Part part = (Part)parts.iterator().next();
QName elementName = part.getElementName();
if (elementName == null) {
return null;
}
if (!operation.getName().equals(elementName.getLocalPart())) {
return null;
}
If this is a bug,I will put a jira.
--
Wang Feng
2008-04-02
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2179) Plugin installation from update site does not say 1.2-incubating
[ https://issues.apache.org/jira/browse/TUSCANY-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2179. - Resolution: Fixed Fixed in trunk and 1.2 branch. Plugin installation from update site does not say 1.2-incubating Key: TUSCANY-2179 URL: https://issues.apache.org/jira/browse/TUSCANY-2179 Project: Tuscany Issue Type: Bug Components: Build System Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The plugin update site references the Tuscany bin distribution (installed as part of the plugin install) as runtime.jar, causing the install dialog to just say 'runtime.jar' instead of 'apache-tuscany-1.2-incubating'. -- 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-2178) Deleting a node throws Javascript error in admin
[ https://issues.apache.org/jira/browse/TUSCANY-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Sebastien Delfino resolved TUSCANY-2178. - Resolution: Fixed Deleting a node throws Javascript error in admin Key: TUSCANY-2178 URL: https://issues.apache.org/jira/browse/TUSCANY-2178 Project: Tuscany Issue Type: Bug Components: Java SCA Domain Management Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 Deleting a node in the admin console does not work and throws a Javascript error. That's a timing issue as the admin sends two AJAX requests to first stop the node and then delete it, but in most cases the delete call jumps the line and gets invoked before the stop, causing the stop action to fail. A simple fix is to invoke these two steps from the server side. -- 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-2182) ClassLoader issues with node2 launcher on WebSphere
ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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-2182) ClassLoader issues with node2 launcher on WebSphere
[ https://issues.apache.org/jira/browse/TUSCANY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584412#action_12584412 ] Jean-Sebastien Delfino commented on TUSCANY-2182: - Also, when running on WebSphere, some of the URLClassLoaders in the classloader hierarchy have getURLs() return null, causing an NPE in NodeImpl. The fix is just to add a test for nulls. ClassLoader issues with node2 launcher on WebSphere --- Key: TUSCANY-2182 URL: https://issues.apache.org/jira/browse/TUSCANY-2182 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 The classloader used by Node2 uses a parent-first loading scheme which does not work on WebSphere application server, as different versions of the Tuscany runtime dependencies are on the classpath of Webapps in the WebSphere environment. The fix for that issue is simply to ensure that the Node2 launcher uses a parent-last classloading scheme to load its runtime classes. -- 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-2183) Sample Catalog JSP does not compile on WebSphere App Server
Sample Catalog JSP does not compile on WebSphere App Server --- Key: TUSCANY-2183 URL: https://issues.apache.org/jira/browse/TUSCANY-2183 Project: Tuscany Issue Type: Bug Components: Java SCA Samples Affects Versions: Java-SCA-1.2 Reporter: Jean-Sebastien Delfino Assignee: Jean-Sebastien Delfino Fix For: Java-SCA-1.2 tutorial/catalog-webapp/webapp/catalog.jsp uses a (for x: collection) construct which is not supported by the WebSphere JSP compiler in its default configuration. Changing to for (i = 0; i n; i++) fixes the JSP compile error. -- 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]
