Re: SCA Java builds are getting very large
On Feb 16, 2008 10:48 PM, Simon Nash [EMAIL PROTECTED] wrote: It isn't long since I could do a complete checkout and build of Tuscany SCA Java in around 400 MB of disk space. Today I was amazed when I ran out of space despite having cleared over a gigabyte before starting. I tend to keep a few builds around for various reasons and the space factor is rapidly becoming more and more of an inhibitor to my development productivity. The full checkout and build that I did a week ago occupied 718 MB on disk. Today's version weighs in at a hefty 1020 MB. I've done some digging around, and there's nothing that seems very easy to eliminate. The biggest files are webapp samples and ActiveMQ logs. This size explosion adds more weight to the evidence that we need to split up the codebase into more modular chunks that can be built and tested independently. Simon The ActiveMQ portion of this has been exasperated recently by the change to use unique broker names so multiple sets of ActiveMQ files are being created. I'll be committing a change shortly that will fix this. ...ant
Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
Clemens Utschig - Utschig wrote: simon - the testcase is quite large - especially the server side to it - as it contains oracle SDO / adfbc libs .. if you tell me where to go debugging, I am happy to help.. Sorry that my request was not clear. Please can you post the client side only, including the Java code, .wsdl file and .composite file that you are using. I would like to see the exact files you are using as this often gives the vital clue that doesn't come out when talking about things. I'm not expecting to run your code as is but I might adapt it so it can run with a mocked up server side that I would create. Simon /clemens -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Saturday, February 16, 2008 7:13 AM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: I got the dynamic wsdl import to work, thx guys - however, the wrong namespace is still sent out to the webservice and hence causes the error reported. Please can you open a JIRA and attach a complete test case including the Java code, .wsdl file and .composite file that you are using. This will allow me to recreate and debug the problem. Simon /clemens -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 12:58 PM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace [EMAIL PROTECTED] wrote: Jean-sebastien, Qualified = target namespace?or wsdl name? Say my wsdl is named aaa.wsdl do I reference it by http://aaa ? Sorry for the slow response. I have been out sick for the last few days. The following definitely works. Other things might work as well, but I haven't tried them. The filename can be anything.wsdl as Sebastien says. (The anything part isn't used by Tuscany.) When you reference the WSDL in your .composite using interface.wsdl interface=mynamespace#wsdl.interface(myporttype) / you need to replace mynamespace and myporttype in the above line to correspond with the actual QName of the portType as defined in your .wsdl file. Simon Thx clemens -Original Message- From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: 2/11/08 6:33 PM Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. - 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]
How to use SDO in tuscany sca?
Hi all,
I do a sample which has a parameter's type is DataObject,and deploy the
component with webservice.
When I invoke the service ,throws an error.
Is my usage wrong?
My sample like this.
helloworld.composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://helloworld;
xmlns:hw=http://helloworld;
name=helloworldws
component name=HelloWorldServiceComponent
implementation.java class=helloworld.HelloWorldImpl /
service name=HelloWorldService
interface.wsdl
interface=http://helloworld#wsdl.interface(HelloWorld) /
binding.ws/
/service
/component
/composite
HelloWorldImpl.java
@Service(HelloWorldService.class)
public class HelloWorldImpl implements HelloWorldService {
public String getGreetings(DataObject name) {
return Hello + name.getString(first) + +
name.getString(last);
}
}
You can download the full testcase on
http://www.blogjava.net/Files/wangfeng/src.zip
Thanks
Wang Feng
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52385projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 07:07:26 -0800 Finished at: Mon 18 Feb 2008 08:04:43 -0800 Total time: 57m 16s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: svkrish @ Mon 18 Feb 2008 06:10:22 -0800 Comment: adding code for resolution of intents and policysets specified in the componentType Files changed: /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/BaseAssemblyProcessor.java ( 628749 ) /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/CompositeProcessor.java ( 628749 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1026 Failures: 0 Total time: 967948 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59) at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:204) ... 11 more Caused by: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128) ... 15 more - To unsubscribe, e-mail: [EMAIL
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52385projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 07:07:26 -0800 Finished at: Mon 18 Feb 2008 08:04:43 -0800 Total time: 57m 16s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: svkrish @ Mon 18 Feb 2008 06:10:22 -0800 Comment: adding code for resolution of intents and policysets specified in the componentType Files changed: /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/BaseAssemblyProcessor.java ( 628749 ) /incubator/tuscany/java/sca/modules/assembly-xml/src/main/java/org/apache/tuscany/sca/assembly/xml/CompositeProcessor.java ( 628749 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1026 Failures: 0 Total time: 967948 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59) at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:204) ... 11 more Caused by: java.lang.InterruptedException at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128) ... 15 more - To unsubscribe, e-mail: [EMAIL
Re: Build fails in transaction itest
Simon Nash wrote:
I did a clean checkout and top-level build today. The build failed in
itest/transaction with the following error. Has anyone else seen this?
I get it consistently from a clean top-level build, but it always seems
to go away when I rebuild just this module.
Simon
With a bit of experimentation I determined that adding a timeout of
1000 milliseconds to the receiveNoWait() call on line 122 of
CheckingAccountServiceImpl.java resolved this intermittent failure
for me. It seems that an immediate receive can sometimes execute
before the message is available.
I committed this change (workaround) in revision 628802. Would anyone
like to look into a more scientific fix?
Simon
[INFO]
[INFO] Building Apache Tuscany SCA Transaction Policy Integration Test
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 8 source files to
F:\tuscany62\sca\itest\transaction\target\cla
sses
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 2 source files to
F:\tuscany62\sca\itest\transaction\target\tes
t-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
F:\tuscany62\sca\itest\transaction\target\sure
fire-reports
---
T E S T S
---
Running
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResourceTestCase
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-1,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-3,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-2,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-4,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-5,5,main] running...
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 24.996 sec
Running org.apache.tuscany.sca.itest.transaction.TransactionTestCase
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: No type specified on component property:
SavingsAccountServiceComponent
/accounts
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: No type specified on component property:
CheckingAccountServiceComponen
t/accounts
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The following are
unfulfilled
intents for component implementation - TransferServiceComponent
Unfulfilled Intents =
[{http://www.osoa.org/xmlns/sca/1.0}managedTransaction.glo
bal]
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The are unfulfilled
intents fo
r binding in reference - savings
Unfulfilled Intents =
[{http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The are unfulfilled
intents fo
r binding in reference - checking
Unfulfilled Intents =
[{http://www.osoa.org/xmlns/sca/1.0}propagatesTransaction]
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The
[jira] Resolved: (TUSCANY-2049) wsdl/xml promotion of interface fails with NPE
[ https://issues.apache.org/jira/browse/TUSCANY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Nash resolved TUSCANY-2049. - Resolution: Fixed Patch applied as revision 628801. Thanks! wsdl/xml promotion of interface fails with NPE -- Key: TUSCANY-2049 URL: https://issues.apache.org/jira/browse/TUSCANY-2049 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Reporter: clemens utschig Assignee: Simon Nash Priority: Blocker Fix For: Java-SCA-1.2 Attachments: WSDLModelResolver.java reference name=empFlexFieldService promote=FlexEmployeeServiceComponent/empFlexFieldService !-- interface.java interface=model.common.serviceinterface.EmpFlexFieldService/ -- interface.wsdl interface=/model/common/#wsdl.interface(EmpFlexFieldService) / binding.ws uri=http://localhost:/Application4710-Model-context-root/EmpFlexFieldService/ /reference Having the above wsdl interface reference, a nullpointer occurs in org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolver - line 338 (nodeMap.getLength()) because nodeMap is null for an element with name #document Null check fixes this -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Hi, Simon.
Are you proposing to have the following?
1) Define a InvokerPropertySet class such as:
public class InvokerPropertySet {
public boolean getAllowsPassByReference() {
...
}
public void setAllowsPassByReference(boolean flag) {
...
}
}
2) Pass it into the Invoker constructors so that invokers can set the
properties. What class is going to keep the property set?
I personally don't like the constructor approach too much because it creates
an implicit contract between the runtime and the Invoker implementation
class (not the Invoker interface).
If we decide to go with the generic property, I would prefer to have the
following:
public interface Configurable {
T T getProperty(String name);
}
Thanks,
Raymond
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino [EMAIL PROTECTED]
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a property sheet object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
I (the invoker) will handle PassByValue semantics. So my naming
suggestion for the method or property is handlesPassByValue.
Simon
-
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] Commented: (TUSCANY-2035) Injected callback references are not resolved at the time of injection
[ https://issues.apache.org/jira/browse/TUSCANY-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569946#action_12569946 ] Simon Nash commented on TUSCANY-2035: - I've checked in some code under revision 628809 to resolve the callback target and reference parameters at the time that the callback reference is created. Could others who have encountered this issue please try this fix to see what results you are getting? Thanks. Injected callback references are not resolved at the time of injection -- Key: TUSCANY-2035 URL: https://issues.apache.org/jira/browse/TUSCANY-2035 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-1.1 Environment: All Reporter: Simon Nash Assignee: Simon Nash Fix For: Java-SCA-Next When a callback reference is injected as a proxy or a CallableReference, the callback target should be resolved at the time of injection to the caller's callback service or the target of any ServiceReference provided by a setCallbackObject() call. Tuscany currently does not do this, but resolves the callback target as the time of use, relative to the current invocation context at that time. For example, if A invokes B and C subsequently invokes the same B instance, any callbacks from the C invocation through references that were injected by the A invocation will go to C instead of going to A as they should. -- 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: Build fails in transaction itest
Hi, Simon.
Thank you for investigating the problem.
I debugged a bit more. The following sequence is failing with ActiveMQ
randomly.
1) Send 3 messages to a queue and commit the session
2) receiveNoWait on one of the three messages
I confirmed that 1) (composite-scoped component with @Init) is always done
before 2).
I assume the session.commit() should return only after the messages are made
available for receive. But it seems that ActiveMQ doesn't guarantee it.
Could it be an ActiveMQ bug?
Adding the timeout as a workaround is fine with me.
Thanks,
Raymond
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 8:47 AM
Subject: Re: Build fails in transaction itest
Simon Nash wrote:
I did a clean checkout and top-level build today. The build failed in
itest/transaction with the following error. Has anyone else seen this?
I get it consistently from a clean top-level build, but it always seems
to go away when I rebuild just this module.
Simon
With a bit of experimentation I determined that adding a timeout of
1000 milliseconds to the receiveNoWait() call on line 122 of
CheckingAccountServiceImpl.java resolved this intermittent failure
for me. It seems that an immediate receive can sometimes execute
before the message is available.
I committed this change (workaround) in revision 628802. Would anyone
like to look into a more scientific fix?
Simon
[INFO]
[INFO] Building Apache Tuscany SCA Transaction Policy Integration Test
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 8 source files to
F:\tuscany62\sca\itest\transaction\target\cla
sses
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Compiling 2 source files to
F:\tuscany62\sca\itest\transaction\target\tes
t-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
F:\tuscany62\sca\itest\transaction\target\sure
fire-reports
---
T E S T S
---
Running
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResourceTestCase
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-1,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-3,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-2,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-4,5,main] running...
16-Feb-2008 16:48:37
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: Thread[Thread-5,5,main] running...
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
16-Feb-2008 16:49:01
org.apache.tuscany.sca.itest.transaction.ConcurrentXAResour
ceTestCase$TestThread run
INFO: 1
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 24.996
sec
Running org.apache.tuscany.sca.itest.transaction.TransactionTestCase
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: No type specified on component property:
SavingsAccountServiceComponent
/accounts
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: No type specified on component property:
CheckingAccountServiceComponen
t/accounts
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The following are
unfulfilled
intents for component implementation - TransferServiceComponent
Unfulfilled Intents =
[{http://www.osoa.org/xmlns/sca/1.0}managedTransaction.glo
bal]
16-Feb-2008 16:49:02
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuild
erImpl$1 problem
WARNING: Theres been an exception related to policies...
org.apache.tuscany.sca.
assembly.builder.impl.PolicyComputationException: The are
Re: How to use SDO in tuscany sca?
Wang,
I'm guessing the problem is probably that you need to register your
app types with the appropriate context established by the Tuscany
runtime.
Tuscany typically does this automatically, now, for static SDO. For
dynamic SDO (i.e. DataObject), you would currently put something like
this in your SCDL ( *.composite) file:
composite ...
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
dbsdo:import.sdo location=wsdl/helloworld.wsdl/
(I looked in your zip and you don't seem to use the types in the XSD,
so I pointed to the WSDL instead... but you can have as multiple
import.sdo elements).
This relation between SCA and SDO scopes is defined by Tuscany, not a
spec, at the moment.
Scott
On Feb 18, 2008 9:15 AM, wang feng [EMAIL PROTECTED] wrote:
Hi all,
I do a sample which has a parameter's type is DataObject,and deploy the
component with webservice.
When I invoke the service ,throws an error.
Is my usage wrong?
My sample like this.
helloworld.composite
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=http://helloworld;
xmlns:hw=http://helloworld;
name=helloworldws
component name=HelloWorldServiceComponent
implementation.java class=helloworld.HelloWorldImpl /
service name=HelloWorldService
interface.wsdl
interface=http://helloworld#wsdl.interface(HelloWorld) /
binding.ws/
/service
/component
/composite
HelloWorldImpl.java
@Service(HelloWorldService.class)
public class HelloWorldImpl implements HelloWorldService {
public String getGreetings(DataObject name) {
return Hello + name.getString(first) + +
name.getString(last);
}
}
You can download the full testcase on
http://www.blogjava.net/Files/wangfeng/src.zip
Thanks
Wang Feng
-
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] Commented: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1257#action_1257
]
clemens utschig commented on TUSCANY-2033:
--
changing the interface to interface.wsdl - does not help - still no recognition
of the new namespace ..
Attached is the complete client testcase.
src dir contains amongst others Runner.java - the main entry class
and EmployeeServiceComponent the implementation.java guy ..
before compilation make sure the whole src/wsdl dir is in your classpath - and
also the libs / classes are included from the /lib dir .. that should do it ..
java interface exposed as service, annoted with
javax.xml.ws.RequestWrapper(...) is ignoring the namespace
--
Key: TUSCANY-2033
URL: https://issues.apache.org/jira/browse/TUSCANY-2033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Priority: Critical
Fix For: Java-SCA-Next
Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl
I have a composite defined that uses an external referenced webservice which
provides SDOs
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/
binding.ws
uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
The java interface that is promoted as service interface / and reflects the
webservice endpoint, contains jaxws annotations for namespaces as below ..
@javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
@javax.jws.WebService(targetNamespace=/model/common/,
name=EmpFlexFieldService,
wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
@oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldService.xsd)
public interface EmpFlexFieldService {
public static final String NAME =
new QName(/model/common/, EmpFlexFieldService).toString();
@javax.jws.WebMethod(action=/model/common/getEmployees1,
operationName=getEmployees1)
@javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1)
@javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1Response)
@javax.jws.WebResult(name=result)
DataObject
getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name=empno)
Integer empno) throws ServiceException;
At runtime - axis generates the following soap message - which is derived
from the base targetNamespace
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
_ns_:getEmployees1 xmlns:_ns_=/model/common/
empno xmlns=/model/common/1/empno
/_ns_:getEmployees1
/soapenv:Body
/soapenv:Envelope
obviously this is wrong - it should be ..
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body xmlns:ns1=/model/common/types/
ns1:getEmployees1
ns1:empno/ns1:empno
/ns1:getEmployees1
/soap:Body
/soap:Envelope
--
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-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clemens utschig updated TUSCANY-2033:
-
Attachment: SDOReferenceBinding.zip
the complete clientside testcase
java interface exposed as service, annoted with
javax.xml.ws.RequestWrapper(...) is ignoring the namespace
--
Key: TUSCANY-2033
URL: https://issues.apache.org/jira/browse/TUSCANY-2033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Priority: Critical
Fix For: Java-SCA-Next
Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl,
SDOReferenceBinding.zip
I have a composite defined that uses an external referenced webservice which
provides SDOs
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/
binding.ws
uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
The java interface that is promoted as service interface / and reflects the
webservice endpoint, contains jaxws annotations for namespaces as below ..
@javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
@javax.jws.WebService(targetNamespace=/model/common/,
name=EmpFlexFieldService,
wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
@oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldService.xsd)
public interface EmpFlexFieldService {
public static final String NAME =
new QName(/model/common/, EmpFlexFieldService).toString();
@javax.jws.WebMethod(action=/model/common/getEmployees1,
operationName=getEmployees1)
@javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1)
@javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1Response)
@javax.jws.WebResult(name=result)
DataObject
getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name=empno)
Integer empno) throws ServiceException;
At runtime - axis generates the following soap message - which is derived
from the base targetNamespace
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
_ns_:getEmployees1 xmlns:_ns_=/model/common/
empno xmlns=/model/common/1/empno
/_ns_:getEmployees1
/soapenv:Body
/soapenv:Envelope
obviously this is wrong - it should be ..
soap:Envelope xmlns:soap=http://schemas.xmlsoap.org/soap/envelope/;
soap:Body xmlns:ns1=/model/common/types/
ns1:getEmployees1
ns1:empno/ns1:empno
/ns1:getEmployees1
/soap:Body
/soap:Envelope
--
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: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace
attache the testcase with interface.wsdl to my original jira (TUSCANY-2033) it contains all the src + a couple libs to be able to compile it, and fixed versions of my other jiras. thx -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Monday, February 18, 2008 5:39 AM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: simon - the testcase is quite large - especially the server side to it - as it contains oracle SDO / adfbc libs .. if you tell me where to go debugging, I am happy to help.. Sorry that my request was not clear. Please can you post the client side only, including the Java code, .wsdl file and .composite file that you are using. I would like to see the exact files you are using as this often gives the vital clue that doesn't come out when talking about things. I'm not expecting to run your code as is but I might adapt it so it can run with a mocked up server side that I would create. Simon /clemens -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Saturday, February 16, 2008 7:13 AM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: I got the dynamic wsdl import to work, thx guys - however, the wrong namespace is still sent out to the webservice and hence causes the error reported. Please can you open a JIRA and attach a complete test case including the Java code, .wsdl file and .composite file that you are using. This will allow me to recreate and debug the problem. Simon /clemens -Original Message- From: Simon Nash [mailto:[EMAIL PROTECTED] Sent: Friday, February 15, 2008 12:58 PM To: tuscany-dev@ws.apache.org Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace [EMAIL PROTECTED] wrote: Jean-sebastien, Qualified = target namespace?or wsdl name? Say my wsdl is named aaa.wsdl do I reference it by http://aaa ? Sorry for the slow response. I have been out sick for the last few days. The following definitely works. Other things might work as well, but I haven't tried them. The filename can be anything.wsdl as Sebastien says. (The anything part isn't used by Tuscany.) When you reference the WSDL in your .composite using interface.wsdl interface=mynamespace#wsdl.interface(myporttype) / you need to replace mynamespace and myporttype in the above line to correspond with the actual QName of the portType as defined in your .wsdl file. Simon Thx clemens -Original Message- From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: 2/11/08 6:33 PM Subject: Re: Tuscany: Axis2 codegen bug? - java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is not honoring the namespace Clemens Utschig - Utschig wrote: shouldn't an include do it, so that I could potentially store the wsdl anywhere .. I'll try that later today - thx for the advise.. You don't even need an include, just place the WSDL file anywhere inside your SCA contribution (JAR or folder), reference its qualified name from your .composite and we should find it. - 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: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Raymond Feng wrote:
Hi, Simon.
Are you proposing to have the following?
1) Define a InvokerPropertySet class such as:
public class InvokerPropertySet {
public boolean getAllowsPassByReference() {
...
}
public void setAllowsPassByReference(boolean flag) {
...
}
}
2) Pass it into the Invoker constructors so that invokers can set the
properties. What class is going to keep the property set?
Invokers are created by the createInvoker() methods of ImplementationProvider
and ReferenceBindingProvider. The InvokerPropertySet could be passed in as
an extra parameter on these calls.
You raise a good point about who will keep the property set information.
Needing the runtime keep hold of a separate InvokerPropertySet instance
for each Invoker instance that it has created seems like a large overhead.
I don't have a good solution for this.
I personally don't like the constructor approach too much because it
creates an implicit contract between the runtime and the Invoker
implementation class (not the Invoker interface).
+1. Passing it on createInvoker() solves this problem.
If we decide to go with the generic property, I would prefer to have the
following:
public interface Configurable {
T T getProperty(String name);
}
Can you say a bit more about how this would work? Is the Configurable
interface implemented by the invoker? How would this approach support
multiple different properties?
Simon
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino [EMAIL PROTECTED]
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to
enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an
allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a property sheet object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
I (the invoker) will handle PassByValue semantics. So my naming
suggestion for the method or property is handlesPassByValue.
Simon
-
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]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52485projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 12:03:33 -0800 Finished at: Mon 18 Feb 2008 13:02:40 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: rfeng @ Mon 18 Feb 2008 11:13:48 -0800 Comment: Clean up the itest and add tests for undeclared exceptions Files changed: /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExceptionTestJAXB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExchangeJaxB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDO.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDOImpl.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/resources/intracomposite.composite ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/test/java/org/apache/tuscany/sca/test/exceptions/IntraCompositeTestCase.java ( 628844 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1028 Failures: 0 Total time: 924269 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
The Configurable interface can be optionally implemented by the Invoker
implementation classes. To support multiple properties, the invoker can
simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
Thanks,
Raymond
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 12:41 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
Hi, Simon.
Are you proposing to have the following?
1) Define a InvokerPropertySet class such as:
public class InvokerPropertySet {
public boolean getAllowsPassByReference() {
...
}
public void setAllowsPassByReference(boolean flag) {
...
}
}
2) Pass it into the Invoker constructors so that invokers can set the
properties. What class is going to keep the property set?
Invokers are created by the createInvoker() methods of
ImplementationProvider
and ReferenceBindingProvider. The InvokerPropertySet could be passed in
as
an extra parameter on these calls.
You raise a good point about who will keep the property set information.
Needing the runtime keep hold of a separate InvokerPropertySet instance
for each Invoker instance that it has created seems like a large overhead.
I don't have a good solution for this.
I personally don't like the constructor approach too much because it
creates an implicit contract between the runtime and the Invoker
implementation class (not the Invoker interface).
+1. Passing it on createInvoker() solves this problem.
If we decide to go with the generic property, I would prefer to have the
following:
public interface Configurable {
T T getProperty(String name);
}
Can you say a bit more about how this would work? Is the Configurable
interface implemented by the invoker? How would this approach support
multiple different properties?
Simon
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Saturday, February 16, 2008 8:23 AM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
ant elder wrote:
On Feb 15, 2008 11:01 PM, Jean-Sebastien Delfino [EMAIL PROTECTED]
wrote:
Raymond Feng wrote:
My preference is to keep PassByValue as the prefix for the following
reasons.
1) The invokers implement this interface only for the cases to
enforece
pass-by-value for remotable interfaces. Invocations over local
interfaces (pass-by-reference) don't even care about this flag.
2) The allowsPassByReference() method basically tells if it's safe to
pass data as-is without violating the pass-by-value semantics.
Having a SomethingPassByValue interface provide an
allowsPassByReference
method is really confusing IMHO.
I think we should use a consistent terminology with either passByValue
or passByReference but not a mix of both.
+1 just to add agreement that its quite confusing like this.
...ant
I can provide lots of suggestions about naming :-) but I'd like to
question whether we even need this new interface. Creating a new
optional SPI to set a single boolean seems quite heavyweight. There
are other examples in the SPIs of this kind of pattern and I think
there's a better approach that's lighter-weight and more flexible.
This boolean is effectively an optional property of the invoker.
As part of creating an invoker, a property sheet object could be
passed to the invoker's constructor for it to fill in with the
optional properties that it supports. This allows invokers to
add support for more properties in future without the need to create
a new SPI interface every time we need a new property. All that
is needed is to add new setter/getter methods to the property sheet.
The same approach could be used to add new properties for other
SPI objects such as binding providers and implementation providers.
In terms of naming (I can't resist), I think this boolean is saying
I (the invoker) will handle PassByValue semantics. So my naming
suggestion for the method or property is handlesPassByValue.
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52485projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 12:03:33 -0800 Finished at: Mon 18 Feb 2008 13:02:40 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: rfeng @ Mon 18 Feb 2008 11:13:48 -0800 Comment: Clean up the itest and add tests for undeclared exceptions Files changed: /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExceptionTestJAXB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExchangeJaxB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDO.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDOImpl.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/resources/intracomposite.composite ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/test/java/org/apache/tuscany/sca/test/exceptions/IntraCompositeTestCase.java ( 628844 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1028 Failures: 0 Total time: 924269 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114) at
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the Invoker
implementation classes. To support multiple properties, the invoker can
simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
Does anyone know why the Continuum builds are failing all the time now with this cancelled exception? Simon Continuum VMBuild Server wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52485projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 12:03:33 -0800 Finished at: Mon 18 Feb 2008 13:02:40 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: rfeng @ Mon 18 Feb 2008 11:13:48 -0800 Comment: Clean up the itest and add tests for undeclared exceptions Files changed: /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExceptionTestJAXB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExchangeJaxB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDO.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDOImpl.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/resources/intracomposite.composite ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/test/java/org/apache/tuscany/sca/test/exceptions/IntraCompositeTestCase.java ( 628844 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1028 Failures: 0 Total time: 924269 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed. at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at
[jira] Commented: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570042#action_12570042
]
Simon Nash commented on TUSCANY-2033:
-
Please try changing your composite file to the following (with wsdlElement
specified on binding.ws), and let me know whether it fixes the problem.
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:flex=http://EmpFlexFieldService;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
!-- interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/ --
interface.wsdl
interface=/model/common/#wsdl.interface(EmpFlexFieldService) /
binding.ws
wsdlElement=/model/common/#wsdl.binding(EmpFlexFieldServiceSoapHttp)
uri=http://localhost:/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
java interface exposed as service, annoted with
javax.xml.ws.RequestWrapper(...) is ignoring the namespace
--
Key: TUSCANY-2033
URL: https://issues.apache.org/jira/browse/TUSCANY-2033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Priority: Critical
Fix For: Java-SCA-Next
Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl,
SDOReferenceBinding.zip
I have a composite defined that uses an external referenced webservice which
provides SDOs
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/
binding.ws
uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
The java interface that is promoted as service interface / and reflects the
webservice endpoint, contains jaxws annotations for namespaces as below ..
@javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
@javax.jws.WebService(targetNamespace=/model/common/,
name=EmpFlexFieldService,
wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
@oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldService.xsd)
public interface EmpFlexFieldService {
public static final String NAME =
new QName(/model/common/, EmpFlexFieldService).toString();
@javax.jws.WebMethod(action=/model/common/getEmployees1,
operationName=getEmployees1)
@javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1)
@javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1Response)
@javax.jws.WebResult(name=result)
DataObject
getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name=empno)
Integer empno) throws ServiceException;
At runtime - axis generates the following soap message - which is derived
from the base targetNamespace
?xml version='1.0' encoding='UTF-8'?
soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
soapenv:Body
_ns_:getEmployees1 xmlns:_ns_=/model/common/
empno xmlns=/model/common/1/empno
/_ns_:getEmployees1
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
We could simply use Object as the return value and then cast it to the type
of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty(AllowsPassByReference);
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message -
From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 3:15 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the Invoker
implementation classes. To support multiple properties, the invoker can
simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
-
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: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project
There is a maximun build time of 1 hour, and looks like we started exceeding this time when building in vmbuild1. Infrastructure team is going to increase this timeout period to 90 mins and we should investigate why our build is taking so long on the vmbuild1 environment. On Feb 18, 2008 3:17 PM, Simon Nash [EMAIL PROTECTED] wrote: Does anyone know why the Continuum builds are failing all the time now with this cancelled exception? Simon Continuum VMBuild Server wrote: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=52485projectId=277 Build statistics: State: Error Previous State: Error Started at: Mon 18 Feb 2008 12:03:33 -0800 Finished at: Mon 18 Feb 2008 13:02:40 -0800 Total time: 59m 7s Build Trigger: Schedule Build Number: 47 Exit code: 0 Building machine hostname: vmbuild.apache.org Operating system : Linux(unknown) Java Home version : java version 1.5.0_12 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) Builder version : Maven version: 2.0.7 Java version: 1.5.0_12 OS name: linux version: 2.6.20-16-server arch: i386 SCM Changes: Changed: rfeng @ Mon 18 Feb 2008 11:13:48 -0800 Comment: Clean up the itest and add tests for undeclared exceptions Files changed: /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExceptionTestJAXB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockExchangeJaxB.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDO.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/java/org/apache/tuscany/sca/test/exceptions/impl/StockTraderSDOImpl.java ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/main/resources/intracomposite.composite ( 628844 ) /incubator/tuscany/java/sca/itest/exceptions-cross-binding-ws/src/test/java/org/apache/tuscany/sca/test/exceptions/IntraCompositeTestCase.java ( 628844 ) Dependencies Changes: No dependencies changed Build Defintion: POM filename: pom.xml Goals: -Pdistribution clean install Arguments: --batch-mode Build Fresh: false Always Build: false Default Build Definition: true Schedule: DEFAULT_SCHEDULE Profile Name: Java 5, Large Memory Description: Test Summary: Tests: 1028 Failures: 0 Total time: 924269 Build Error: org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:216) at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:149) at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:140) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:417) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:156) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at
Re: Tuscany with Weblogic
Dave Sowerby wrote: Hey, Absolutely, feel free to copy/translate/whatever you need to do with it, though it'd be nice if you could still link back/acknowledge me in some small way ;) Yes, we'll need to keep a link to your blog. Just for my 2p on the weblogic situation I agree that the META-INF directory is the wrong place for the composite files to live long-term, there's every chance that users of Tuscany may have several contributions within a webapp, which are all organised into suitable jars. Yes exactly, and I suppose that the issue with .composites extends to .wsdl, .xsd, .bpel etc and it would feel really odd to have all these artifacts under META-INF :) -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolving Component type files
Luciano Resende wrote: Do you want to restrict this to file ? Some bindings, like binding.http can point to a specific folder, that's why I thought import.resource would be more appropriate name for this new import ? You're right we need to support folders too, import.resource is better. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to the
type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty(AllowsPassByReference);
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 3:15 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the
Invoker implementation classes. To support multiple properties, the
invoker can simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
Sorry, but after looking at this again I think that it's getting way too
complicated. Can we please keep this SPI simple?
I'd like to propose two options:
1) Add methods to Invoker, mirroring what's described in the spec.
interface Invoker {
boolean allowsPassByReference();
// and another similar method which we'll need to handle
// non-blocking calls
boolean isOneWay();
}
2) or if we want to preserve binary compatibility for now, create
interface Invoker2 extends Invoker {
boolean allowsPassByReference();
boolean isOneWay();
}
IMHO it's OK to ask Invoker implementors to add two empty methods when
they port their code to the next release, so I'll prefer option (1) as
it's simpler.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classloading code in core contribution processing
ant elder wrote: On Feb 16, 2008 12:56 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: snip For now I have to make a copy of the contribution code without this stuff to make progress. Could the people who worked on this classloading code please help clean it up and move it out of the core contribution modules? This doesn't feel good to me, we've had so much trouble in the past with code forks, isn't there some way to work with whats there instead of just starting afresh with your own version? We should not confuse nonlinear development and forking, or confuse starting afresh and copying existing code and refactoring it to reuse it without some of its dependencies or coupling with classloading. What do you intend to do with the copy of the contribution code? Is the copy going to be functionally equivalent to whats there at the moment? What is it that you're trying to do, is there some specific functionality you're trying to add or enhance? ...ant I'm trying to implement the contribution workspace described in [1]. I need to reuse some of the logic in contribution-impl but that code is coupling reading/processing/classloading/resolving, which I need to decouple and provide as separate functions. If there's no objection I'm planning to commit an implementation of the contribution workspace described in [1] to trunk in the next two days, implemented with a mix of code copied from contribution-impl and new code. If you have objections I'll do it outside of trunk and ask the community to review it later. However, I'd prefer to do this work in trunk as it has already been discussed on this list and trunk is where new development happens. [1] http://marc.info/?l=tuscany-devm=120202180130866 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
Sebastian,
it works :) thank you very much .. would you kindly explain what this changed
in the behavior?
thx clemens
-Original Message-
From: Simon Nash (JIRA) [mailto:[EMAIL PROTECTED]
Sent: Monday, February 18, 2008 3:11 PM
To: tuscany-dev@ws.apache.org
Subject: [jira] Commented: (TUSCANY-2033) java interface exposed as
service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the
namespace
[
https://issues.apache.org/jira/browse/TUSCANY-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570042#action_12570042
]
Simon Nash commented on TUSCANY-2033:
-
Please try changing your composite file to the following (with wsdlElement
specified on binding.ws), and let me know whether it fixes the problem.
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:flex=http://EmpFlexFieldService;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
!-- interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/ --
interface.wsdl
interface=/model/common/#wsdl.interface(EmpFlexFieldService) /
binding.ws
wsdlElement=/model/common/#wsdl.binding(EmpFlexFieldServiceSoapHttp)
uri=http://localhost:/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
java interface exposed as service, annoted with
javax.xml.ws.RequestWrapper(...) is ignoring the namespace
--
Key: TUSCANY-2033
URL: https://issues.apache.org/jira/browse/TUSCANY-2033
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-1.0.1
Reporter: clemens utschig
Priority: Critical
Fix For: Java-SCA-Next
Attachments: EmpFlexFieldService.java, EmpFlexFieldService.wsdl,
SDOReferenceBinding.zip
I have a composite defined that uses an external referenced webservice which
provides SDOs
?xml version=1.0 encoding=UTF-8?
composite xmlns=http://www.osoa.org/xmlns/sca/1.0;
targetNamespace=/model/common/
xmlns:dbsdo=http://tuscany.apache.org/xmlns/sca/databinding/sdo/1.0;
name=FlexEmployeeComposite xmlns:tns=/model/common/types/
xmlns:types=/model/common/types/
xmlns:errors=http://xmlns.oracle.com/adf/svc/errors/;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
component name=FlexEmployeeServiceComponent
implementation.java
class=com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent/
reference name=empFlexFieldService/
/component
reference name=empFlexFieldService
promote=FlexEmployeeServiceComponent/empFlexFieldService
interface.java
interface=model.common.serviceinterface.EmpFlexFieldService/
binding.ws
uri=http://localhost:1234/Application4710-Model-context-root/EmpFlexFieldService/
/reference
/composite
The java interface that is promoted as service interface / and reflects the
webservice endpoint, contains jaxws annotations for namespaces as below ..
@javax.jws.soap.SOAPBinding(parameterStyle=javax.jws.soap.SOAPBinding.ParameterStyle.WRAPPED,
style=javax.jws.soap.SOAPBinding.Style.DOCUMENT)
@javax.jws.WebService(targetNamespace=/model/common/,
name=EmpFlexFieldService,
wsdlLocation=model/common/serviceinterface/EmpFlexFieldService.wsdl)
@oracle.j2ee.ws.common.sdo.SchemaLocation(value=model/common/serviceinterface/EmpFlexFieldServicexsd)
public interface EmpFlexFieldService {
public static final String NAME =
new QName(/model/common/, EmpFlexFieldService).toString();
@javax.jws.WebMethod(action=/model/common/getEmployees1,
operationName=getEmployees1)
@javax.xml.ws.RequestWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1)
@javax.xml.ws.ResponseWrapper(targetNamespace=/model/common/types/,
localName=getEmployees1Response)
@javax.jws.WebResult(name=result)
DataObject
getEmployees1(@javax.jws.WebParam(mode=javax.jws.WebParam.Mode.IN,
name=empno)
Integer empno) throws ServiceException;
At runtime - axis generates
RE: [jira] Commented: (TUSCANY-2033) java interface exposed as service, annoted with javax.xml.ws.RequestWrapper(...) is ignoring the namespace
after my little happyness .. I get the next one one deserializing my SDO .. [EMAIL PROTECTED] Exception in thread main org.apache.tuscany.sca.databinding.TransformationException: org.apache.tuscany.sca.databinding.TransformationException: java.lang.RuntimeException: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri '/model/common/' not found. at org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:199) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:175) at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:158) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:249) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:146) at $Proxy11.getEmployees1(Unknown Source) at com.oracle.soa.test.tuscany.impl.EmployeeServiceComponent.getEmployees1(EmployeeServiceComponent.java:28) 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:105) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:249) at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:146) at $Proxy11.getEmployees1(Unknown Source) at com.oracle.soa.test.tuscany.Runner.main(Runner.java:26) Caused by: org.apache.tuscany.sca.databinding.TransformationException: java.lang.RuntimeException: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri '/model/common/' not found. at org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:53) at org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:34) at org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint$LazyPullTransformer.transform(DefaultTransformerExtensionPoint.java:199) at org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:73) at org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:192) ... 16 more Caused by: java.lang.RuntimeException: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri '/model/common/' not found. at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.loadDocument(XMLStreamHelperImpl.java:145) at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.loadObject(XMLStreamHelperImpl.java:98) at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.loadObject(XMLStreamHelperImpl.java:102) at org.apache.tuscany.sca.databinding.sdo.XMLStreamReader2DataObject.transform(XMLStreamReader2DataObject.java:49) ... 20 more Caused by: org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Package with uri '/model/common/' not found. at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl$SDOXMLLoadImpl.load(SDOXMLResourceImpl.java:489) at org.apache.tuscany.sdo.util.resource.SDOXMLResourceImpl.load(SDOXMLResourceImpl.java:598) at org.apache.tuscany.sdo.helper.XMLDocumentImpl.load(XMLDocumentImpl.java:248) at org.apache.tuscany.sdo.helper.XMLStreamHelperImpl.loadDocument(XMLStreamHelperImpl.java:136) ... 23 more Caused by: org.eclipse.emf.ecore.xmi.PackageNotFoundException: Package with uri '/model/common/' not found. at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getPackageForURI(XMLHandler.java:2350) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.getFactoryForPrefix(XMLHandler.java:2188) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectFromTypeName(XMLHandler.java:1828) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObject(XMLHandler.java:1787) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleFeature(XMLHandler.java:1569) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createDocumentRoot(XMLHandler.java:1237) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createObjectByType(XMLHandler.java:1165) at org.eclipse.emf.ecore.xmi.impl.XMLHandler.createTopObject(XMLHandler.java:1247) at
Re: svn commit: r628163 - in /incubator/tuscany/java/sca: itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/ itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces
+1 on Option 1) which is something I'm scared to propose these days as we
want to keep the SPIs binary compatible :-). I prefer to have an explict,
clean and strongly-typed contract.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 6:50 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
We could simply use Object as the return value and then cast it to the
type of the property.
The caller code could perform the test as follows:
if(invoker instanceof Configurable) {
boolean allowsPBR = ((Configurable)
invoker).getProperty(AllowsPassByReference);
if(allowsPBR) {
// do something here
}
}
Thanks,
Raymond
- Original Message - From: Simon Nash [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 18, 2008 3:15 PM
Subject: Re: svn commit: r628163 - in /incubator/tuscany/java/sca:
itest/interfaces/src/main/java/org/apache/tuscany/sca/itest/interfaces/
itest/interfaces/src/test/java/org/apache/tuscany/sca/itest/interfaces/
modules/binding-ejb/src/main/java/org/apache/tus
Raymond Feng wrote:
The Configurable interface can be optionally implemented by the Invoker
implementation classes. To support multiple properties, the invoker can
simply do this:
public class MyInvokerImpl implements Invoker, Configurable {
...
T public T getProperty(String name) {
if(AllowsPassByReference.equals(name) {
return true;
} else if(AnotherProperty.equals(name) {
return StringValue;
} else {
return null;
}
}
}
This way, the property set is kept at the invoker instances.
I didn't know that generics could do this, with multiple return
types from a single method. (Seems like I need to go back to
Java school!) What does the code invoking the magical getProperty()
method look like?
Simon
Sorry, but after looking at this again I think that it's getting way too
complicated. Can we please keep this SPI simple?
I'd like to propose two options:
1) Add methods to Invoker, mirroring what's described in the spec.
interface Invoker {
boolean allowsPassByReference();
// and another similar method which we'll need to handle
// non-blocking calls
boolean isOneWay();
}
2) or if we want to preserve binary compatibility for now, create
interface Invoker2 extends Invoker {
boolean allowsPassByReference();
boolean isOneWay();
}
IMHO it's OK to ask Invoker implementors to add two empty methods when
they port their code to the next release, so I'll prefer option (1) as
it's simpler.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
