RE: Release 1.3?

[Mark Combellack]

Hi Simon,

In your original comments, you mentioned that you wanted to remove the old
domain modules that we are no longer using.  I was interested as to whether
you had a provisional list of modules that you were going to remove. I've
not seen a follow-up email on this subject.

Thanks,

Mark

 -Original Message-
 From: Simon Laws [mailto:[EMAIL PROTECTED]
 Sent: 06 June 2008 09:21
 To: tuscany-dev
 Subject: Release 1.3?

snip

 I'd also like to have a bit of a tidy up for this release and remove the
 old
 domain modules we are no longer using (I'll post on this separately)
 
 What else has been added or changed?
 
 I think the things I would like to get done can be closed off next week
 ready to cut a branch.
 
 Thoughts?
 
 Simon

[jira] Resolved: (TUSCANY-2213) Cannot Serialize and deserailize a CallableReference injected using a @Callback - Is this a valid use case?

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2213.
--

Resolution: Fixed

I've updated tuscany-core to add support for Serializing Stateless and 
Conversational CallbackReferences

I've re-enabled the @ignored test in itest-serialization and added a new test 
for Conversational CallbackReferences.

SVN commit 660874 added support for Serializing Stateless CallbackReferences.
SVN commit 660961 added support for Serializing Conversational 
CallbackReferences.

Marking this issue as fixed.

 Cannot Serialize and deserailize a CallableReference injected using a 
 @Callback - Is this a valid use case?
 ---

 Key: TUSCANY-2213
 URL: https://issues.apache.org/jira/browse/TUSCANY-2213
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn trunk revision 645821
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 I've got a bidirectional Service that uses @Callback to inject a 
 CalalbleReference 
 When a method is called on the Service, I Serialise and then deserialise the 
 CallableReference before it is used to invoke the client. I do this to 
 simulate persisting the CallableReference and then using it again later.
 The stack trace I get is:
 java.io.IOException
   at 
 org.apache.tuscany.sca.core.context.CallableReferenceImpl.writeExternal(CallableReferenceImpl.java:361)
   at 
 java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
   at 
 org.apache.tuscany.sca.itest.servicereference.utils.ServiceReferenceUtils.serialize(ServiceReferenceUtils.java:57)
   at 
 org.apache.tuscany.sca.itest.servicereference.StatelessServiceImpl.triggerCallback(StatelessServiceImpl.java:70)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
   at $Proxy14.triggerCallback(Unknown Source)
   at 
 org.apache.tuscany.sca.itest.servicereference.SCAManagedClientImpl.testSerializeCallbackToStatelessServiceInsideSCA(SCAManagedClientImpl.java:126)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
   at $Proxy13.testSerializeCallbackToStatelessServiceInsideSCA(Unknown 
 Source)
   at 
 org.apache.tuscany.sca.itest.servicereference.SerializeServiceReferenceTestCase.testSerializeCallbackToStatelessServiceInsideSCA(SerializeServiceReferenceTestCase.java:103)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
   at 
 org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected

How do I get my Continuum build server account unlocked?

[Mark Combellack]

Hi,

 

I've just tried accessing the Continuum build server [1] and have discovered
that my account is locked. How do I go about getting my account unlocked?
Can anyone do this for me? My account id is mcombellack.

 

Thanks,

 

Mark

 

[1] http://vmbuild.apache.org/continuum/

 

 

 

RE: How do I get my Continuum build server account unlocked?

[Mark Combellack]

 -Original Message-
 From: Simon Laws [mailto:[EMAIL PROTECTED]
 Sent: 23 May 2008 11:01
 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
 Subject: Re: How do I get my Continuum build server account unlocked?
 
 On Fri, May 23, 2008 at 10:55 AM, Mark Combellack [EMAIL PROTECTED]
 wrote:
 
  Hi,
 
 
 
  I've just tried accessing the Continuum build server [1] and have
  discovered
  that my account is locked. How do I go about getting my account
 unlocked?
  Can anyone do this for me? My account id is mcombellack.
 
 
 
  Thanks,
 
 
 
  Mark
 
 
 
  [1] http://vmbuild.apache.org/continuum/
 
 
 
 
 
 
 
 
 And an additional question. How did you get the account in the first
 place.
 I'd like to be able to kick off builds etc and I'm assuming I need an
 account to be able to do that. How does one go about getting one?
 
 Simon

I did this many months ago so I am a bit vague on the exact detail. 

To get my account, I clicked the register link on the page and created an
account. I then posted a request to the Tuscany dev list to be added to the
Tuscany build group. Someone then did something and some time later I could
then see and start Tuscany builds. 

Mark

RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[Mark Combellack]

Hi,

 

I've just tried building the latest trunk of Tuscany and I'm getting a
compile failure in the new endpoint module. The error I am getting is:

 

[INFO]


[INFO] Error for project: Apache Tuscany SCA Default Endpoint Implementation
(during install)

[INFO]


[INFO] Compilation failure

 

/home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan
y/sca/binding/sca/EndpointTestCase.java:[109,32] package
org.apache.xml.serialize does not exist

 

/home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tuscan
y/sca/binding/sca/EndpointTestCase.java:[110,32] package
org.apache.xml.serialize does not exist

 

 

Is anyone else seeing this issue or is it just me?

 

Thanks,

 

Mark

 

 -Original Message-

 From: Simon Laws [mailto:[EMAIL PROTECTED]

 Sent: 16 May 2008 09:26

 To: tuscany-dev@ws.apache.org

 Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed

 operation and extension implementations - was: Re: Request to propogate

 the value of a references target= attribute on its associated bindings

 model object

 

 ...snip

 

 

  The two sets of SPIs could co-exist for a while with BindingProviders

  working with bindings and ServiceProviders (I just made up that name)

 with

  service endpoints.

  --

  Jean-Sebastien

 

 

 At r656959 I've just enabled some changes to take a step toward using an

 Endpoint representation in the model as an alternative to using cloned

 bindings as the representation of valid reference targets. It's not

 replacing the cloned binding approach just yet, to avoid breaking

 anything,

 but is the first step on the road. This is what I have done.

 

 Made a new Endpoint model type

 Created a separate factory for it (separate as I though the model may need

 to be pluggable as some point)

 Created a new EndpointProvider type and associated factory.

 Created an Endpoint module to provide a provider implementation.

 Created an Endpoint wire to trap attempted calls over unresolved endpoints

 Separated off the Endpoint builder code into a new builder class. Same

 code

 but easier to identify.

 Added an endpoint collection to references

 Used the Endpoint in the wire builder in place of the old internal target

 structure. The logic is weaved in to the existing logic as follows.

   For references with no target, put the binding into reference binding as

 before

   Create an Endpoint for all explicit reference targets

   For resolved endpoints (Endpoints where the target is resolved) put the

 binding into reference bindings, i.e. the same as before

   For unresolved endpoints create an endpoint provider and a wire. We

 don't

 have unresolved targets in tuscany (except in the sca binding test) so

 should not happen. If you do put a target name in that can't be matched

 with

 a service you'll get a warning.

 

 If there is no Endpoint module on the classpath it will not create a

 provider or a wire hence disabling any Endpoint based processing. The

 Endpoint model will still be used though

 

 As part of this change I've updated the logic that looks for target names

 in

 binding uri. It's now applied to all binding types which I believe is what

 the spec says, There is though an issue here. I'll raise a separate

 thread.

 

 There are also a couple of thoughts I had.

 

 Can we make the CompositeBuilderImpl have just one constructor?

 Should builders be pluggable?

 I've used some of the CompoisteActivator functions in the EndpointWire

 that

 could do with moving into the activator interface.

 

 Simon

  _  

RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bin

[Mark Combellack]

This problem has now been fixed in SVN revision r657009


Thanks,

Mark

 -Original Message-
 From: Mark Combellack [mailto:[EMAIL PROTECTED]
 Sent: 16 May 2008 11:26
 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
 Subject: RE: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed
 operation and extension implementations - was: Re: Request to propogate
 the value of a references target= attribute on its associated bindings
 model object
 
 Hi,
 
 
 
 I've just tried building the latest trunk of Tuscany and I'm getting a
 compile failure in the new endpoint module. The error I am getting is:
 
 
 
 [INFO]
 
 
 [INFO] Error for project: Apache Tuscany SCA Default Endpoint
 Implementation
 (during install)
 
 [INFO]
 
 
 [INFO] Compilation failure
 
 
 
 /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc
 an
 y/sca/binding/sca/EndpointTestCase.java:[109,32] package
 org.apache.xml.serialize does not exist
 
 
 
 /home/mcc/dev/apache/tuscany/modules/endpoint/src/test/java/org/apace/tusc
 an
 y/sca/binding/sca/EndpointTestCase.java:[110,32] package
 org.apache.xml.serialize does not exist
 
 
 
 
 
 Is anyone else seeing this issue or is it just me?
 
 
 
 Thanks,
 
 
 
 Mark
 
 
 
  -Original Message-
 
  From: Simon Laws [mailto:[EMAIL PROTECTED]
 
  Sent: 16 May 2008 09:26
 
  To: tuscany-dev@ws.apache.org
 
  Subject: Endpoints was: Re: [BRAINSTORM] Flexibility in distributed
 
  operation and extension implementations - was: Re: Request to propogate
 
  the value of a references target= attribute on its associated bindings
 
  model object
 
 
 
  ...snip
 
 
 
  
 
   The two sets of SPIs could co-exist for a while with BindingProviders
 
   working with bindings and ServiceProviders (I just made up that name)
 
  with
 
   service endpoints.
 
   --
 
   Jean-Sebastien
 
 
 
 
 
  At r656959 I've just enabled some changes to take a step toward using an
 
  Endpoint representation in the model as an alternative to using cloned
 
  bindings as the representation of valid reference targets. It's not
 
  replacing the cloned binding approach just yet, to avoid breaking
 
  anything,
 
  but is the first step on the road. This is what I have done.
 
 
 
  Made a new Endpoint model type
 
  Created a separate factory for it (separate as I though the model may
 need
 
  to be pluggable as some point)
 
  Created a new EndpointProvider type and associated factory.
 
  Created an Endpoint module to provide a provider implementation.
 
  Created an Endpoint wire to trap attempted calls over unresolved
 endpoints
 
  Separated off the Endpoint builder code into a new builder class. Same
 
  code
 
  but easier to identify.
 
  Added an endpoint collection to references
 
  Used the Endpoint in the wire builder in place of the old internal
 target
 
  structure. The logic is weaved in to the existing logic as follows.
 
For references with no target, put the binding into reference binding
 as
 
  before
 
Create an Endpoint for all explicit reference targets
 
For resolved endpoints (Endpoints where the target is resolved) put
 the
 
  binding into reference bindings, i.e. the same as before
 
For unresolved endpoints create an endpoint provider and a wire. We
 
  don't
 
  have unresolved targets in tuscany (except in the sca binding test) so
 
  should not happen. If you do put a target name in that can't be matched
 
  with
 
  a service you'll get a warning.
 
 
 
  If there is no Endpoint module on the classpath it will not create a
 
  provider or a wire hence disabling any Endpoint based processing. The
 
  Endpoint model will still be used though
 
 
 
  As part of this change I've updated the logic that looks for target
 names
 
  in
 
  binding uri. It's now applied to all binding types which I believe is
 what
 
  the spec says, There is though an issue here. I'll raise a separate
 
  thread.
 
 
 
  There are also a couple of thoughts I had.
 
 
 
  Can we make the CompositeBuilderImpl have just one constructor?
 
  Should builders be pluggable?
 
  I've used some of the CompoisteActivator functions in the EndpointWire
 
  that
 
  could do with moving into the activator interface.
 
 
 
  Simon
 
   _

RE: Test Failures in Tutorial - Anyone else seeing these?

[Mark Combellack]

Hi Mike,

I've just done a partial branch build and did not see the error you were
having. I did the following:

svn up modules tutorial
cd modules
mvn clean install
cd tutorial
mvn clean install

I did not see any errors reported. Odd.

Mark

 -Original Message-
 From: Mike Edwards [mailto:[EMAIL PROTECTED]
 Sent: 15 May 2008 14:26
 To: tuscany-dev
 Subject: Test Failures in Tutorial - Anyone else seeing these?
 
 Folks,
 
 Trying to run a build of trunk at the moment and I am getting test
 failures in tutorial\store-test -
 is anyone else seeing these?
 
 The failure I'm getting is
 
 SEVERE: SCA Node could not be created
 java.lang.reflect.InvocationTargetException
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
  at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcc
 essorImpl.java:
 39)
  at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstr
 uctorAccessorIm
 pl.java:27)
  at
 java.lang.reflect.Constructor.newInstance(Constructor.java:494)
  at
 org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUti
 l.java:297)
  at
 org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.
 java:60)
  at
 test.StoreSupplierTestCase.setup(StoreSupplierTestCase.java:58)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
 snip...
 
 Caused by: org.osoa.sca.ServiceRuntimeException: java.io.IOException:
 Server returned HTTP response
 code: 500 for URL: http://localhost:9990/composite-
 resolved/composite:store-supplier;http://store;st
 ore-supplier
  at
 org.apache.tuscany.sca.node.impl.NodeImpl.init(NodeImpl.java:155)
  at
 org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactory
 Impl.java:37)
  at
 org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLaun
 cherBootstrap.
 init(NodeImplementationLauncherBootstrap.java:94)
  ... 31 more
 Caused by: java.io.IOException: Server returned HTTP response code: 500
 for URL: http://localhost:99
 90/composite-resolved/composite:store-supplier;http://store;store-supplier
  at
 sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnecti
 on.java:1170)
  at java.net.URL.openStream(URL.java:1007)
  at
 org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:306)
  at
 org.apache.tuscany.sca.node.impl.NodeImpl.init(NodeImpl.java:152)
  ... 33 more
 Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 5.718 sec
  FAILURE!
 
 
 Any help gratefully received,
 
 
 Yours,  Mike.

RE: Test Failures in Tutorial - Anyone else seeing these?

[Mark Combellack]

I'm running on Linux with JDK 1.5. I've not cleaned out my .m2 repository
for ages. I'll give that a go and see what happens.

Mark
 -Original Message-
 From: Mike Edwards [mailto:[EMAIL PROTECTED]
 Sent: 15 May 2008 17:00
 To: tuscany-dev@ws.apache.org
 Subject: Re: Test Failures in Tutorial - Anyone else seeing these?
 
 ant elder wrote:
  I had a build going fine this morning but updated after you posted this
 and
  now I also get a HTTP 500 failure but in tutorial\catalog-mediation.
 
 ...ant
 
  On Thu, May 15, 2008 at 2:26 PM, Mike Edwards 
  [EMAIL PROTECTED] wrote:
 
 Ant,
 
 Thanks for letting us know that you're seeing a similar problem.
 
 I can confirm that with the very latest from trunk as of 15:30 GMT, I
 still get the same failures in
 store-tests.
 
 I wonder what is different between our systems and Mark's?
 
 I'm using Windows and JDK 1.5.0_14.
 
 What else might be different?  I assume we're using the same level of
 Jetty?
 
 
 Yours, Mike

RE: Test Failures in Tutorial - Anyone else seeing these?

[Mark Combellack]

Hi Mike,

I've just done a clean of my .m2 repository and a complete rebuild from
incubator/tuscany/java with SVN revision 656738. I can build the modules but
I get a failure in the helloworld-bpel sample (see [1] below). I've built it
several times and it reliably fails for me.

I then went into the samples directory and rebuilt them 10+ times and I
still do not get any failures.


Following on from ant's comment of it being an intermittent fault, it might
be a timing issue. The machine I am building on is fairly quick. It is a 4
core 3.8 GHz RedHat Enterprise 5 Linux server. Perhaps my machine is fast
enough not to show the problem?

Thanks,

Mark


[1] Test failure in helloworld-bpel


---
 T E S T S
---
Running helloworld.BPELHelloWorldTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 10.329 sec
 FAILURE!
testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 10.304 sec  
ERROR!
org.apache.tuscany.sca.databinding.TransformationException: No wrapper
handler is provided for databinding: null
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.
getWrapperHandler(Input2InputTransformer.java:206)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.
transform(Input2InputTransformer.java:112)
at
org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.
transform(Input2InputTransformer.java:45)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.ja
va:79)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.t
ransform(DataTransformationInterceptor.java:186)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.i
nvoke(DataTransformationInterceptor.java:76)
at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingI
nvoker.java:61)
at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
assByValueInterceptor.java:103)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:286)
at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:154)
at $Proxy20.hello(Unknown Source)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35
)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62
)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Ab
stractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD
irectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB
ooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879
)


Results :

Tests in error: 
  testInvoke(helloworld.BPELHelloWorldTestCase)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0


 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 15 May 2008 19:03
 To: tuscany-dev@ws.apache.org
 Subject: Re: Test Failures in Tutorial - Anyone else seeing these?
 
 It seems to be intermittent, I've had two of the failures but mostly it
 works.
 
...ant
 
 On Thu, May 15, 2008 at 6:19 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:
 
  Mark Combellack wrote:
 
  I'm running on Linux with JDK 1.5. I've not cleaned out my .m2
 repository
  for ages. I'll give that a go and see what happens.
 
  Mark

[jira] Reopened: (TUSCANY-2297) Add support for data Collection interface to the implementation-data-xml

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack reopened TUSCANY-2297:
--


It appears that applying the patch for this JIRA has broken the 
implementation-data-xml project. When I do a clean build on the project, I now 
get JUnit test failures (see below) 

The project is also failing on the Continuum server which is preventing Tuscany 
SCA from building.

If I roll back the project to before the patch for this Jira was applied, the 
project builds without error.


The errors I am getting are:

Running 
org.apache.tuscany.sca.implementation.data.DATAImplementationProcessorTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.394 sec
Running org.apache.tuscany.sca.implementation.data.DATACollectionTestCase
testInsert
Number of rows inserted: 2
testGet
?xml version='1.0' encoding='UTF-8'?resultSetrecordcolumn 
name=ID1/columncolumn name=NAMEACME 
Publishing/column/recordrecordcolumn name=ID2/columncolumn 
name=NAMEDo-rite plumbing/column/recordrecordcolumn 
name=ID3/columncolumn 
name=NAMEMegaCorp/column/recordrecordcolumn 
name=ID4/columncolumn name=NAMENew Coorporation 
I/column/recordrecordcolumn name=ID5/columncolumn name=NAMENew 
Coorporation II/column/record/resultSet
testUpdate
testGetByID
?xml version='1.0' encoding='UTF-8'?resultSetrecordcolumn 
name=ID4/columncolumn name=NAMEUpdate 
Coorporation/column/record/resultSet
testDeleteByID
testDelete
recreating database...
done!
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.657 sec
Running org.apache.tuscany.sca.implementation.data.DATATestCase
testInsert
Number of rows inserted: 2
testGet
?xml version='1.0' encoding='UTF-8'?resultSetrecordcolumn 
name=ID6/columncolumn name=NAMENew Coorporation 
I/column/recordrecordcolumn name=ID7/columncolumn name=NAMENew 
Coorporation II/column/record/resultSet
testUpdate
testGetByID
?xml version='1.0' encoding='UTF-8'?resultSet /
testDeleteByID
testDelete
Tests run: 6, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 1.394 sec  
FAILURE!
testUpdate(org.apache.tuscany.sca.implementation.data.DATATestCase)  Time 
elapsed: 0.229 sec   FAILURE!
junit.framework.AssertionFailedError: expected:0 but was:1
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at 
org.apache.tuscany.sca.implementation.data.DATATestCase.testUpdate(DATATestCase.java:94)
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 junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

testDeleteByID(org.apache.tuscany.sca.implementation.data.DATATestCase)  Time 
elapsed: 0.227 sec   FAILURE!
junit.framework.AssertionFailedError: expected:0 but was:1
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195

[jira] Commented: (TUSCANY-2297) Add support for data Collection interface to the implementation-data-xml

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596784#action_12596784
 ] 

Mark Combellack commented on TUSCANY-2297:
--

Looking into it in more detail, the problem is that this patch introduces a new 
test case called DATACollectionTestCase that is a duplicate of DataTestCase. 
The problem is that these two test cases will not run one after the other.

What happens is:

1) Initially, the test data is loaded into the database by the Maven build 
script.
2) The DATACollectionTestCase runs which will delete the data from the database 
in the testDelete() test case.
3) The DataTestCase now runs. However, it will fail since the data has already 
been deleted by DATACollectionTestCase



I notice that in both JUnit test classes, the testDelete() suggests that it 
re-creates the database:

System.out.println(recreating database...);
//Helper.createDB();
System.out.println(done!);

However, the above code is not going to restore the database.

 Add support for data Collection interface to the implementation-data-xml
 

 Key: TUSCANY-2297
 URL: https://issues.apache.org/jira/browse/TUSCANY-2297
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Java Implementation Extension
Reporter: Douglas Siqueira Leite
Assignee: Luciano Resende
 Fix For: Java-SCA-Next

 Attachments: DATAInvoker.java, tuscany2297_douglas_2008_05_06.patch


 Add support for data Collection interface from implementation-data to the 
 implementation-data-xml module

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TUSCANY-2297) Add support for data Collection interface to the implementation-data-xml

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596785#action_12596785
 ] 

Mark Combellack commented on TUSCANY-2297:
--

What I have done to work around this issue is to rename DATACollectionTestCase 
to DATACollectionTestCaseFIXME. This will hopefully allow the main Continuum 
build to complete.

Deleting   
implementation-data-xml/src/test/java/org/apache/tuscany/sca/implementation/data/DATACollectionTestCase.java
Adding 
implementation-data-xml/src/test/java/org/apache/tuscany/sca/implementation/data/DATACollectionTestCaseFIXME.java
Transmitting file data .
Committed revision 656307.

 Add support for data Collection interface to the implementation-data-xml
 

 Key: TUSCANY-2297
 URL: https://issues.apache.org/jira/browse/TUSCANY-2297
 Project: Tuscany
  Issue Type: New Feature
  Components: Java SCA Java Implementation Extension
Reporter: Douglas Siqueira Leite
Assignee: Luciano Resende
 Fix For: Java-SCA-Next

 Attachments: DATAInvoker.java, tuscany2297_douglas_2008_05_06.patch


 Add support for data Collection interface from implementation-data to the 
 implementation-data-xml module

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)

[Mark Combellack]

Get's my +1 too.

Mark

 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 10 May 2008 08:17
 To: tuscany-dev
 Subject: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
 
 Restarting the graduation vote with the updated proposal words, please
 vote
 on the proposal below to graduate Tuscany to a TLP.
 
 +1 from me.
 
...ant
 
  X. Establish the Apache Tuscany Project
 
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Project Management Committee charged with
 the creation and maintenance of open-source software for
 distribution at no charge to the public, that simplifies the
 development, deployment and management of distributed applications
 built as compositions of service components. These components
 may be implemented with a range of technologies and connected
 using a variety of communication protocols. This software will
 implement relevant open standards including, but not limited to,
 the Service Component Architecture standard defined by the OASIS
 OpenCSA member section, and related technologies.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tuscany Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby is
 responsible for the creation and maintenance of software
 related to Apache Tuscany;
 and be it further
 
 RESOLVED, that the office of Vice President, Apache Tuscany be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Tuscany Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Tuscany Project; and be it further
 
 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tuscany Project:
 
 * Adriano Crestani adrianocrestani at apache dot org
 * ant elder antelder at apache dot org
 * Brady Johnson bjohnson at apache dot org
 * Frank Budinsky frankb at apache dot org
 * Ignacio Silva-Lepe isilval at apache dot org
 * Jean-Sebastien Delfino jsdelfino at apache dot org
 * kelvin goodson kelvingoodson at apache dot org
 * Luciano Resende lresende at apache dot org
 * Mark Combellack mcombellack at apache dot org
 * Matthieu Riou mriou at apache dot org
 * Mike Edwards edwardsmj at apache dot org
 * Paul Fremantle pzf at apache dot org
 * Pete Robbins robbinspg at apache dot org
 * Raymond Feng rfeng at apache dot org
 * Simon Laws slaws at apache dot org
 * Simon Nash nash at apache dot org
 * Venkata Krishnan svkrish at apache dot org
 
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
 be appointed to the office of Vice President, Apache Tuscany, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Tuscany podling; and be it further
 
 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Tuscany podling encumbered upon the Apache Incubator
 Project are hereafter discharged.

RE: [VOTE] Graduate Apache Tuscany as a Top Level Project

[Mark Combellack]

Here's my +1 for Tuscany to graduate as a TLP.

Thanks,

Mark

 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 28 April 2008 19:16
 To: tuscany-dev
 Subject: [VOTE] Graduate Apache Tuscany as a Top Level Project
 
 We've done a lot of work since last October. We now have a diverse
 community
 of contributors and have demonstrated the ability to attract new
 committers
 to create an even more diverse community, we have shown we can do releases
 based on Apache guidelines, and we have shown we conduct our discussions
 in
 public within full view of the community and can resolve disagreements on
 the lists. I think we're ready, so please vote on the proposal below to
 graduate Tuscany to a TLP.
 
 +1 from me.
 
...ant
 
 X. Establish the Apache Tuscany Project
 
 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Project Management Committee charged with
 the creation and maintenance of open-source software that
 simplifies the development and deployment of service oriented
 applications and provides a managed service-oriented runtime
 based on the standards defined by the OASIS OpenCSA group,
 for distribution at no charge to the public.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Tuscany Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby is
 responsible for the creation and maintenance of software
 related to Apache Tuscany;
 and be it further
 
 RESOLVED, that the office of Vice President, Apache Tuscany be
 and hereby is created, the person holding such office to
 serve at the direction of the Board of Directors as the chair
 of the Apache Tuscany Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache Tuscany Project; and be it further
 
 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Tuscany Project:
 
- Adriano Crestani adrianocrestani at apache dot org
- ant elder antelder at apache dot org
- Brady Johnson bjohnson at apache dot org
- Frank Budinsky frankb at apache dot org
- Ignacio Silva-Lepe isilval at apache dot org
- Jean-Sebastien Delfino jsdelfino at apache dot org
- kelvin goodson kelvingoodson at apache dot org
- Luciano Resende lresende at apache dot org
- Mark Combellack mcombellack at apache dot org
- Matthieu Riou mriou at apache dot org
- Mike Edwards edwardsmj at apache dot org
- Paul Fremantle pzf at apache dot org
- Pete Robbins robbinspg at apache dot org
- Raymond Feng rfeng at apache dot org
- Simon Laws slaws at apache dot org
- Simon Nash nash at apache dot org
- Venkata Krishnan svkrish at apache dot org
 
  NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
 be appointed to the office of Vice President, Apache Tuscany, to
 serve in accordance with and subject to the direction of the
 Board of Directors and the Bylaws of the Foundation until
 death, resignation, retirement, removal or disqualification,
 or until a successor is appointed; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Tuscany podling; and be it further
 
 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Tuscany podling encumbered upon the Apache Incubator
 Project are hereafter discharged.

RE: Adding SVN version to Java files

[Mark Combellack]

Hi,

It looks like the discussions on adding SVN version to Java files has gone
quiet again so I'll give it a little prod :-)

Previously, the question was asked as to what was the justification for
adding the SVN version. I hope I have answered this question satisfactorily.


Generally people seemed to be happy with adding SVN version to the Java
files. However, ant, would prefer not to do this.

ant, has the recent justification emails provided you with enough of a
reason to convince you that they should be added?

Thanks,

Mark

 -Original Message-
 From: Mark Combellack [mailto:[EMAIL PROTECTED]
 Sent: 24 April 2008 09:55
 To: tuscany-dev@ws.apache.org
 Subject: RE: Adding SVN version to Java files
 
 Hi,
 
 
 
 The main reasons that I like the SVN details in the header of the files
 include:
 
 
 
 * You can look at the source file and see what revision it is
 without having to use SVN commands
 
 * Typically, developers will do an SVN checkout of the code using
 SVN so they can get the information via SVN commands or via the headers
 
 * Typically, users do not do an SVN checkout of the source code
 and
 will not have SVN installed. They are typically provided with a jar file
 containing the source code. They will not be able to run SVN command to
 work
 out which versions of source code they are running
 
 * Typically, there are many, many more users than there are
 developers
 
 * If a source file is printed out or attached as an email as part
 of
 a bug report or published on a web server, the source code will contain
 the
 SVN revision number. This makes the bug easier to fix as you know the
 revision number. The SVN commands will not be able to tell you the
 revision
 number in these scenarios.
 
 
 
 
 
 The nice thing about the SVN keyword substitution is that a Developer is
 free to choose whether they want them or not as the expansion is done on
 the
 client side. If a Developer wants the $Date$ and $Revision$ expanded, then
 they have to update their SVN configuration to do so. If they do not, then
 they don't need to do anything as it is disabled in SVN by default. The
 key
 thing is that @version $Date$ $Revision$ is in the header to provide this
 choice.
 
 
 
 
 
 
 
 At the end of the day, from my personal opinion, using @version $Date$
 $Revision$ is a nice to have feature in the source code. I would like to
 have it there. However, I would rather go without it if its presence is
 going to cause disharmony amongst the Tuscany Developers.
 
 
 
 Thanks,
 
 
 
 Mark
 
 
 
  -Original Message-
 
  From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED]
 
  Sent: 24 April 2008 08:04
 
  To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
 
  Subject: Re: Adding SVN version to Java files
 
 
 
  I would like to know the last revision and date at which a particular
 file
 
  is updated just by opening the file in any editor and without having to
 do
 
  anything extra, for e.g., like installing a plugin for eclipse, opening
 a
 
  command prompt to issue an svn info command (note that the source I have
 
  need not always be from svn, it could be a source archive for a release
 
  downloaded separately), etc.  I found this info very useful while
 
  investigating JIRAs.
 
 
 
  ++Vamsi
 
 
 
  On Thu, Apr 24, 2008 at 11:12 AM, ant elder [EMAIL PROTECTED] wrote:
 
 
 
   On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy
 
  [EMAIL PROTECTED]
 
   wrote:
 
  
 
   snip
 
  
 
  From the above, we have 4 +1s and no -1s - although we have a
 
   preference not
 
  
 
  to do this from ant. So, the consensus is to make this change.
 
 
 
   We haven't held a formal vote, so I don't think we should be
 
  trying
 
 to decide this based on a count of +1s and -1s.
 
   
 
Agreed.  We should hold a formal vote.
 
   
 
   
 
   We do consensus based development. Voting can be a useful gauging
 
   consensus
 
   but voting does not make consensus. Its obvious from this thread that
 
   there
 
   is not (yet) consensus so we don't need a vote, how about instead
 trying
 
   to
 
   convince us by explaining the value of adding this?
 
  
 
 ...ant
 
  

RE: Adding SVN version to Java files

[Mark Combellack]

Fantastic news ant :-)

Thanks for your offer of help to update the templates. I appreciate that.

All we need now is SVN commit access and I can get started.

Thanks,

Mark

 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 29 April 2008 13:54
 To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
 Subject: Re: Adding SVN version to Java files
 
 Yes i think we have consensus to do this now, and as a sign of good faith
 i'll help by (as soon as we get SVN write access back) adding the keywords
 to the IDE templates we have in SVN and adding text to the developer guide
 on what is required to set up our SVN clients to correctly set the svn
 properties on new files.
 
...ant
 
 On Tue, Apr 29, 2008 at 1:46 PM, Mark Combellack [EMAIL PROTECTED]
 wrote:
 
 
  Hi,
 
  It looks like the discussions on adding SVN version to Java files has
 gone
  quiet again so I'll give it a little prod :-)
 
  Previously, the question was asked as to what was the justification for
  adding the SVN version. I hope I have answered this question
  satisfactorily.
 
 
  Generally people seemed to be happy with adding SVN version to the Java
  files. However, ant, would prefer not to do this.
 
  ant, has the recent justification emails provided you with enough of a
  reason to convince you that they should be added?
 
  Thanks,
 
  Mark
 
   -Original Message-
   From: Mark Combellack [mailto:[EMAIL PROTECTED]
   Sent: 24 April 2008 09:55
   To: tuscany-dev@ws.apache.org
   Subject: RE: Adding SVN version to Java files
  
   Hi,
  
  
  
   The main reasons that I like the SVN details in the header of the
 files
   include:
  
  
  
   * You can look at the source file and see what revision it is
   without having to use SVN commands
  
   * Typically, developers will do an SVN checkout of the code
  using
   SVN so they can get the information via SVN commands or via the
 headers
  
   * Typically, users do not do an SVN checkout of the source
 code
   and
   will not have SVN installed. They are typically provided with a jar
 file
   containing the source code. They will not be able to run SVN command
 to
   work
   out which versions of source code they are running
  
   * Typically, there are many, many more users than there are
   developers
  
   * If a source file is printed out or attached as an email as
  part
   of
   a bug report or published on a web server, the source code will
 contain
   the
   SVN revision number. This makes the bug easier to fix as you know the
   revision number. The SVN commands will not be able to tell you the
   revision
   number in these scenarios.
  
  
  
  
  
   The nice thing about the SVN keyword substitution is that a Developer
 is
   free to choose whether they want them or not as the expansion is done
 on
   the
   client side. If a Developer wants the $Date$ and $Revision$ expanded,
  then
   they have to update their SVN configuration to do so. If they do not,
  then
   they don't need to do anything as it is disabled in SVN by default.
 The
   key
   thing is that @version $Date$ $Revision$ is in the header to provide
  this
   choice.
  
  
  
  
  
  
  
   At the end of the day, from my personal opinion, using @version $Date$
   $Revision$ is a nice to have feature in the source code. I would like
 to
   have it there. However, I would rather go without it if its presence
 is
   going to cause disharmony amongst the Tuscany Developers.
  
  
  
   Thanks,
  
  
  
   Mark
  
  
  
-Original Message-
  
From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED]
  
Sent: 24 April 2008 08:04
  
To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
  
Subject: Re: Adding SVN version to Java files
  
   
  
I would like to know the last revision and date at which a
 particular
   file
  
is updated just by opening the file in any editor and without having
  to
   do
  
anything extra, for e.g., like installing a plugin for eclipse,
  opening
   a
  
command prompt to issue an svn info command (note that the source I
  have
  
need not always be from svn, it could be a source archive for a
  release
  
downloaded separately), etc.  I found this info very useful while
  
investigating JIRAs.
  
   
  
++Vamsi
  
   
  
On Thu, Apr 24, 2008 at 11:12 AM, ant elder [EMAIL PROTECTED]
  wrote:
  
   
  
 On Wed, Apr 23, 2008 at 5:52 PM, Vamsavardhana Reddy
  
[EMAIL PROTECTED]
  
 wrote:
  

  
 snip
  

  
From the above, we have 4 +1s and no -1s - although we have a
  
 preference not
  

  
to do this from ant. So, the consensus is to make this
 change.
  
   
  
 We haven't held a formal vote, so I don't think we should
 be
  
trying
  
   to decide this based on a count of +1s and -1s.
  
 
  
  Agreed.  We should hold a formal vote.
  
 
  
 
  
 We do consensus

RE: [NOTICE] Mario Antollini voted as Tuscany committer

[Mark Combellack]

Congratulations Mario. Welcome aboard.

Mark

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
 Luciano Resende
 Sent: 25 April 2008 16:47
 To: tuscany-dev
 Cc: Antollini, Mario
 Subject: [NOTICE] Mario Antollini voted as Tuscany committer
 
 The Tuscany PPMC and Incubator PMC have voted for Mario Antollini to
 become a Tuscany committer.
 
 Please spend sometime to get familiar with Apache developer's pages
 [1], the Apache Incubator site [2] and to the Incubator Committers
 Guide [3]. Also, could you please submit an Apache CLA so we can get
 your userid and access sorted out, you can find out about the
 Contributor License Agreement at [4].
 
 Congratulations and welcome Mario!
 
 [1] http://www.apache.org/dev/
 [2] http://incubator.apache.org/
 [3] http://incubator.apache.org/guides/committer.html
 [4] http://www.apache.org/licenses/#clas
 
 --
 Luciano Resende
 Apache Tuscany Committer
 http://people.apache.org/~lresende
 http://lresende.blogspot.com/

RE: SVN version keyword expansion

[Mark Combellack]

Hi Simon,

Have you recently changed your Subversion configuration file to enable SVN
keyword expansion? The file in question is located:

Windows  %USERPROFILE%\Application Data\Subversion\config
Linux   ~/.subversion/config

The value in question is enable-auto-props. If this is set to yes then it
will expand keywords. By default this value is set to no.

There were discussions on the dev list about this around the end of March
beginning of April. See:

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29637.html
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg29781.html 

These discussions suggested changing the SVN config to enable keyword
expansion.

Perhaps this is the cause of the problem?

Mark

 -Original Message-
 From: Simon Nash [mailto:[EMAIL PROTECTED]
 Sent: 23 April 2008 10:16
 To: tuscany-dev
 Subject: SVN version keyword expansion
 
 On April 1, I checked out a file from SVN.  Its version keywords
 were not expanded in my local copy.  Yesterday I checked out the
 same file and the version keywords were expanded.  This caused my
 attempt to apply a patch (derived from the previous checkout)
 to fail.
 
 The file when viewed in SVN contains the header line
   * @version $Rev$ $Date$
 My previous local checkout had the identical line.  My current
 local checkout has the line
   * @version $Rev: 643696 $ $Date: 2008-04-02 04:24:11 +0100 (Wed, 02 Apr
 2008) $
 
 What is causing this line to now get expanded in my local checked out
 copy, and why wasn't it expanded when I checked it out previously?
 
Simon
 

RE: Adding SVN version to Java files

[Mark Combellack]

 -Original Message-
 From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
 Sent: 15 April 2008 02:59
 To: tuscany-dev@ws.apache.org
 Subject: Re: Adding SVN version to Java files
 
 Mark Combellack wrote:
  Hi,
 
  I've been looking through the Tuscany source code and noticed that some
  files have a @version containing the SVN revision number in their
 JavaDoc
  headers but others do not.
 
  As an example, @version might look like:
 
  /**
   * Some JavaDoc for the class
   *
   * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
  2007) $
   */
 
  I would like to go through the Tuscany source code and add this header
 where
  it is missing. This would involve a large number of minor changes to the
  Tuscany tree so I wanted to run it by everyone to make sure no-one had a
  problem with me doing this at this time.
 
  I'll probably start this next week unless there is an objection.
 
  Thanks,
 
  Mark
 
 
 
 I'm replying again to the original message in this thread, as there
 doesn't seem to be any conclusion yet. Does anybody understand where we
 are with this?
 
 I'm usually adding the SVN rev tag to the files I touch when I see that
 it's missing. I guess I can continue like that but it doesn't sound
 ideal, so I'm still +1 on Mark's proposal.
 
 Anyway, Mark Thanks for volunteering to do this. I was hoping it'd take
 less than 3 weeks to reach consensus on changes like that which don't
 break anything...
 --
 Jean-Sebastien
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


This topic appears to have gone quiet. I guess this means that we have a
consensus since there appears to be no active debate on this subject.

In summary of this thread, we have:

+1 from Mark, Vasmi, Luciano and Sebastian.

ant prefers not to do this

Simon says he would find it useful.


From the above, we have 4 +1s and no -1s - although we have a preference not
to do this from ant. So, the consensus is to make this change.

I'll hold off making the changes for a few days and then start later this
week.

Thanks,

Mark

RE: svn commit: r648763 - /incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tuscany/sca/databinding/impl/DirectedGraph.java

[Mark Combellack]

I'm looking to fix this issue now

I'm testing a fix and about to commit.

Mark


 -Original Message-
 From: Simon Laws [mailto:[EMAIL PROTECTED]
 Sent: 17 April 2008 09:42
 To: tuscany-dev@ws.apache.org
 Subject: Re: svn commit: r648763 -
 /incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/t
 uscany/sca/databinding/impl/DirectedGraph.java
 
 On Wed, Apr 16, 2008 at 6:31 PM, [EMAIL PROTECTED] wrote:
 
  Author: rfeng
  Date: Wed Apr 16 10:31:00 2008
  New Revision: 648763
 
  URL: http://svn.apache.org/viewvc?rev=648763view=rev
  Log:
  Fix for TUSCANY-2069
 
  Modified:
 
 
 incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tu
 scany/sca/databinding/impl/DirectedGraph.java
 
  Modified:
 
 incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tu
 scany/sca/databinding/impl/DirectedGraph.java
  URL:
 
 http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/databindin
 g/src/main/java/org/apache/tuscany/sca/databinding/impl/DirectedGraph.java
 ?rev=648763r1=648762r2=648763view=diff
 
 
 ==
 
  ---
 
 incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tu
 scany/sca/databinding/impl/DirectedGraph.java
  (original)
  +++
 
 incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tu
 scany/sca/databinding/impl/DirectedGraph.java
  Wed Apr 16 10:31:00 2008
  @@ -26,6 +26,7 @@
   import java.util.List;
   import java.util.Map;
   import java.util.Set;
  +import java.util.concurrent.ConcurrentHashMap;
 
   /**
   * Directed, weighted graph
  @@ -72,7 +73,8 @@
 
  }
 
  -private final MapVertexPair, Path paths = new HashMapVertexPair,
  Path();
  +// Fix for TUSCANY-2069, making the map concurrent
  +private final MapVertexPair, Path paths = new
  ConcurrentHashMapVertexPair, Path();
 
  /**
   * Vertex of a graph
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 Hi
 
 Don't know if anyone else is seeing this but this change is causing a NPE
 in
 DirectedGraphTestCase for me. Am looking at it now.
 
 Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (TUSCANY-2069) Missing serialization in DirectedGraph

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack reopened TUSCANY-2069:
--


The fix is actually causing a Null PointerException in the Unit Tests for 
databinding.

Running org.apache.tuscany.sca.databinding.impl.DirectedGraphTestCase
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.352 sec  
FAILURE!
testGraph(org.apache.tuscany.sca.databinding.impl.DirectedGraphTestCase)  Time 
elapsed: 0.244 sec   ERROR!
java.lang.NullPointerException
at 
java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:846)
at 
org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:319)
at 
org.apache.tuscany.sca.databinding.impl.DirectedGraphTestCase.testGraph(DirectedGraphTestCase.java:79)
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 junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)




This is caused by the type of the collection chainging from HashMap to 
ConcurrentHashMap. The difference is that a HashMap will allow null key and 
values whereas a ConcurrentHashMap does not.

The test is attempting to add a null as a value for one of the keys.

To get this to build, I am going to add a null check around the offending point 
so it does not attempt to put a null in the ConcurrentHashMap.

 Missing serialization in DirectedGraph
 --

 Key: TUSCANY-2069
 URL: https://issues.apache.org/jira/browse/TUSCANY-2069
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 I have a service with a web service binding that processes its input using an 
 SDO.  The service works fine with one client.  It also works fine if it is 
 driven once by one client and then driven by multiple clients.  But if it is 
 driven initially by multiple clients (2 is enough), various failures occur in 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph.  It appears there is a 
 lack of synchronization in this class.
 Failure 1 - NPE
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph$Node.access$400(DirectedGraph.java:188)
   at 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:314)
   at 
 org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76)
   at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183)
   at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88

[jira] Commented: (TUSCANY-2069) Missing serialization in DirectedGraph

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589872#action_12589872
 ] 

Mark Combellack commented on TUSCANY-2069:
--

I've added the null check and the unit tests now pass.

However, this does introduce a change to the code. Previously, if a 
getPath(someNode) returned null, this lookup was cached. With the new code, 
this getPath(someNode) lookup is not cached. Depending on how often this 
getPath(someNode) lookup returns null, this may have an adverse affect on 
performance.

 Missing serialization in DirectedGraph
 --

 Key: TUSCANY-2069
 URL: https://issues.apache.org/jira/browse/TUSCANY-2069
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Data Binding Runtime
Affects Versions: Java-SCA-1.0.1
Reporter: Greg Dritschler
Assignee: Raymond Feng
 Fix For: Java-SCA-Next


 I have a service with a web service binding that processes its input using an 
 SDO.  The service works fine with one client.  It also works fine if it is 
 driven once by one client and then driven by multiple clients.  But if it is 
 driven initially by multiple clients (2 is enough), various failures occur in 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph.  It appears there is a 
 lack of synchronization in this class.
 Failure 1 - NPE
 java.lang.NullPointerException
   at 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph$Node.access$400(DirectedGraph.java:188)
   at 
 org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:314)
   at 
 org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76)
   at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183)
   at 
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59)
   at 
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:88)
   at 
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:192)
   at 
 org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:89)
   at 
 com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.invokeNextInterceptor(RuntimeExtensionManager.java:211)
   at 
 com.ibm.ws.soa.sca.runtime.impl.RuntimeExtensionManager.processMessage(RuntimeExtensionManager.java:96)
   at 
 com.ibm.ws.soa.sca.runtime.impl.RuntimeTuscanyInterceptor.invoke(RuntimeTuscanyInterceptor.java:154)
   at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceProvider.invokeTarget(Axis2ServiceProvider.java:852)
   at 
 org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceInOutSyncMessageReceiver.invokeBusinessLogic(Axis2ServiceInOutSyncMessageReceiver.java:119)
   at 
 org.apache.axis2.receivers.AbstractInOutSyncMessageReceiver.invokeBusinessLogic(AbstractInOutSyncMessageReceiver.java:42)
   at 
 org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:96)
   at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:147)
   at 
 org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:275)
 Failure 2 - timeout (code is probably looping)
 WTRN0124I: When the timeout occurred the thread with which the transaction 
 is, or was most recently, associated was Thread[WebContainer : 0,5,main]. The 
 stack trace of this thread when the timeout occurred was: 
   java.util.HashMap.findNonNullKeyEntry(Unknown Source)
   java.util.HashMap.putImpl(Unknown Source)
   java.util.HashMap.put(Unknown Source)
   
 org.apache.tuscany.sca.databinding.impl.DirectedGraph.getShortestPath(DirectedGraph.java:296)
   
 org.apache.tuscany.sca.databinding.DefaultTransformerExtensionPoint.getTransformerChain(DefaultTransformerExtensionPoint.java:302)
   
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.getTransformerChain(MediatorImpl.java:162)
   
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:76)
   
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:183)
   
 org.apache.tuscany.sca.core.databinding.transformers.Input2InputTransformer.transform(Input2InputTransformer.java:59)
   
 org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java

RE: svn commit: r648763 - /incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tuscany/sca/databinding/impl/DirectedGraph.java

[Mark Combellack]

I've committed a fix that checks for null before doing the insert. This
means that the unit tests now pass.

I've re-opened TUSCANY-2069 so the change can be validated. If the code
really must insert null then we need to do something different - e.g. revert
collection or add a marker value to represent null.

Mark

 -Original Message-
 From: Ramkumar R [mailto:[EMAIL PROTECTED]
 Sent: 17 April 2008 09:52
 To: tuscany-dev@ws.apache.org
 Subject: Re: svn commit: r648763 -
 /incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/t
 uscany/sca/databinding/impl/DirectedGraph.java
 
 Hi Simon,
 I am also facing this issue, here Raymond have used ConcurrentHashMap to
 resolve the issue as mentioned in TUSCANY-2069, but we can't be using
 ConcurrentHashMap in this case as this collection (ConcurrentHashMap) does
 not allow null value to be inserted in the Map. Since the
 DirectedGraph.java
 class explicitly tries to insert null value in its getShortestPath()
 method
 we see this exception. For now we can revert to the old code of having
 HashMap to resolve this issue.
 
 --
 Thanks  Regards,
 Ramkumar Ramalingam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2225) RuntimeExceptions thrown by @OneWay methods are not logged anywhere

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2225.
--

Resolution: Fixed

The exception is now being logged to the JDK Logger.

The fix was committed in SVN revision 649060

A unit test was committed in SVN revision 649064



 RuntimeExceptions thrown by @OneWay methods are not logged anywhere
 ---

 Key: TUSCANY-2225
 URL: https://issues.apache.org/jira/browse/TUSCANY-2225
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: trunk svn revision 647147
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If a @OneWay method throws a RuntimeException, the exception is lost. It is 
 not logged anywhere and there is no way to tell it has happened. This makes 
 it extremely hard for a developer to debug problems with @OneWay methods in 
 their applications.
 The client code that invokes the @OneWay method will not be told of the 
 failure as per the contract of the @OneWay scemantics.
 However, the fact that the exception occurred should be recorded somwhere so 
 the developer can attempt to diagnose the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Latest continuum builds are failing due to test failures in itest/osgi-implementation with new test cases helloworld.sdo

[Mark Combellack]

Hi Rajini,

Thanks for fixing the osgi-implementation build break so quickly. It is
working for me now.

The build then failed on osgi-contribution. However, I see that you have
already committed a fix for this one too :-)

The build is currently running on the Continuum server so we should
hopefully see a successful build soon.

Thanks,

Mark


 -Original Message-
 From: Rajini Sivaram [mailto:[EMAIL PROTECTED]
 Sent: 15 April 2008 21:13
 To: tuscany-dev@ws.apache.org
 Subject: Re: Latest continuum builds are failing due to test failures in
 itest/osgi-implementation with new test cases helloworld.sdo
 
 Sorry about that. I have committed a fix under revision 648396.
 
 Due to a difference in classloading between the IBM JDK that I was using
 for
 testing and the Sun(?) JDK on Continuum, an additional class was required
 to
 be visible from the test bundle, resulting in the NoClassDefFoundError.
 
 I was expecting to see a build failure report if the Continuum build
 failed
 after I checked in code. Is that completely turned off now?
 
 
 On 4/15/08, Mark Combellack [EMAIL PROTECTED] wrote:
 
  Hi,
 
 
 
  Over the last few days, the continuum build has been failing for the
 trunk
  of Tuscany. The problem is that two tests are failing in
  itest/osgi-implementation. The relevant error messages are:
 
 
 
 
 
  testJavaToOSGi(helloworld.sdo.SdoTestCase)  Time elapsed: 0.424 sec  
  ERROR!
 
  java.lang.NoClassDefFoundError
 
   at
 
 
 helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldCli
 en
  tComponent.java:33)
 
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
   at
 
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
 39
  )
 
   at
 
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
 pl
  .java:25)
 
   at java.lang.reflect.Method.invoke(Method.java:585)
 
   at
 
 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationIn
 vo
  ker.invoke(JavaImplementationInvoker.java:109)
 
   at
 
 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke
 (P
  assByValueInterceptor.java:108)
 
   at
 
 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindin
 gI
  nvoker.java:61)
 
   at
 
 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke
 (P
  assByValueInterceptor.java:108)
 
   at
 
 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvo
 ca
  tionHandler.java:286)
 
   at
 
 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvo
 ca
  tionHandler.java:154)
 
   at $Proxy141.getGreetings(Unknown Source)
 
   at helloworld.sdo.SdoTestCase.testJavaToOSGi(SdoTestCase.java:81)
 
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
   at
 
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
 39
  )
 
   at
 
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
 pl
  .java:25)
 
   at java.lang.reflect.Method.invoke(Method.java:585)
 
   at junit.framework.TestCase.runTest(TestCase.java:168)
 
   at junit.framework.TestCase.runBare(TestCase.java:134)
 
   at junit.framework.TestResult$1.protect(TestResult.java:110)
 
   at junit.framework.TestResult.runProtected(TestResult.java:128)
 
   at junit.framework.TestResult.run(TestResult.java:113)
 
   at junit.framework.TestCase.run(TestCase.java:124)
 
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
 
   at junit.framework.TestSuite.run(TestSuite.java:227)
 
   at
 
 
 org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:
 35
  )
 
   at
 
 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:
 62
  )
 
   at
 
 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(
 Ab
  stractDirectoryTestSuite.java:138)
 
   at
 
 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abstrac
 tD
  irectoryTestSuite.java:125)
 
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
 
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 
   at
 
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
 39
  )
 
   at
 
 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
 pl
  .java:25)
 
   at java.lang.reflect.Method.invoke(Method.java:585)
 
   at
 
 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Surefir
 eB
  ooter.java:308)
 
   at
 
 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:8
 79
  )
 
 
 
  testOSGiToJava(helloworld.sdo.SdoTestCase)  Time elapsed: 0.278 sec  
  ERROR!
 
  java.lang.NoClassDefFoundError
 
   at
 
 
 helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldCli
 en
  tComponent.java:33

RE: [NOTICE] Wang Feng voted as Tuscany committer

[Mark Combellack]

Congratulations Wang Feng and Welcome!

Mark

 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 16 April 2008 09:55
 To: tuscany-dev
 Cc: [EMAIL PROTECTED]
 Subject: [NOTICE] Wang Feng voted as Tuscany committer
 
 The Tuscany PPMC and Incubator PMC have voted for Wang Feng to become a
 Tuscany committer.
 
 Congratulations and welcome Wang Feng!
 
...ant


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Adding SVN version to Java files

[Mark Combellack]

 -Original Message-
 From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
 Sent: 15 April 2008 02:59
 To: tuscany-dev@ws.apache.org
 Subject: Re: Adding SVN version to Java files
 
 Mark Combellack wrote:
  Hi,
 
  I've been looking through the Tuscany source code and noticed that some
  files have a @version containing the SVN revision number in their
 JavaDoc
  headers but others do not.
 
  As an example, @version might look like:
 
  /**
   * Some JavaDoc for the class
   *
   * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
  2007) $
   */
 
  I would like to go through the Tuscany source code and add this header
 where
  it is missing. This would involve a large number of minor changes to the
  Tuscany tree so I wanted to run it by everyone to make sure no-one had a
  problem with me doing this at this time.
 
  I'll probably start this next week unless there is an objection.
 
  Thanks,
 
  Mark
 
 
 
 I'm replying again to the original message in this thread, as there
 doesn't seem to be any conclusion yet. Does anybody understand where we
 are with this?
 
 I'm usually adding the SVN rev tag to the files I touch when I see that
 it's missing. I guess I can continue like that but it doesn't sound
 ideal, so I'm still +1 on Mark's proposal.
 
 Anyway, Mark Thanks for volunteering to do this. I was hoping it'd take
 less than 3 weeks to reach consensus on changes like that which don't
 break anything...
 --
 Jean-Sebastien
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


I'm still happy to make this change but I held off doing so since there does
not seem to be a consensus on the subject at the moment.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2228) Setting an Integer Property with a non-number throws NumberFormatException - but for which Property?

[Mark Combellack (JIRA)]

Setting an Integer Property with a non-number throws NumberFormatException - 
but for which Property?


 Key: TUSCANY-2228
 URL: https://issues.apache.org/jira/browse/TUSCANY-2228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision 648161
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


If I define a Property on my Component as type int and then attempt to set the 
property value in the XML to a non-number (e.g. the String Hello), Tuscany 
will throw the following exception:

org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
input string: 
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
stack trace snipped here
Caused by: java.lang.NumberFormatException: For input string: 
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.parseInt(Integer.java:497)
at 
org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
at 
org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
at 
org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
at 
org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
at 
org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
at 
org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
at 
org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
at 
org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
at 
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
at 
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
at 
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)



The big problem with this exception is that it does not tell you which field is 
invalid

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2228) Setting an Integer Property with a non-number throws NumberFormatException - but for which Property?

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589075#action_12589075
 ] 

Mark Combellack commented on TUSCANY-2228:
--

The cause of this issue is that the class JavaPropertyValueObjectFactory in 
implementation-java-runtime calls the 
simpleTypeMapper.toJavaObject() method which will throw NumberFormatException 
or IllegalArgumentException if the data it is attempting to convert is not 
valid.

The fix for this issue is to add try/catch block for these two exceptions and 
make sure the Property name is in the exception.

 Setting an Integer Property with a non-number throws NumberFormatException - 
 but for which Property?
 

 Key: TUSCANY-2228
 URL: https://issues.apache.org/jira/browse/TUSCANY-2228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision 648161
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If I define a Property on my Component as type int and then attempt to set 
 the property value in the XML to a non-number (e.g. the String Hello), 
 Tuscany will throw the following exception:
 org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
 input string: 
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
 stack trace snipped here
 Caused by: java.lang.NumberFormatException: For input string: 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Integer.parseInt(Integer.java:468)
 at java.lang.Integer.parseInt(Integer.java:497)
 at 
 org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
 at 
 org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
 at 
 org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
 at 
 org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
 at 
 org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
 at 
 org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 The big problem with this exception is that it does not tell you which field 
 is invalid

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2228) Setting an Integer Property with a non-number throws NumberFormatException - but for which Property?

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589076#action_12589076
 ] 

Mark Combellack commented on TUSCANY-2228:
--

I've committed a fix to handle the extra exceptions in SVN revision 648251.

The exception now looks like:

org.apache.tuscany.sca.core.factory.ObjectCreationException: Failed to create 
instance for property intField with value 
at 
org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:226)
stack trace snipped here 
Caused by: java.lang.NumberFormatException: For input string: 
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:468)
at java.lang.Integer.parseInt(Integer.java:497)
at 
org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
at 
org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
at 
org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:224)
... 22 more


 Setting an Integer Property with a non-number throws NumberFormatException - 
 but for which Property?
 

 Key: TUSCANY-2228
 URL: https://issues.apache.org/jira/browse/TUSCANY-2228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision 648161
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If I define a Property on my Component as type int and then attempt to set 
 the property value in the XML to a non-number (e.g. the String Hello), 
 Tuscany will throw the following exception:
 org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
 input string: 
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
 stack trace snipped here
 Caused by: java.lang.NumberFormatException: For input string: 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Integer.parseInt(Integer.java:468)
 at java.lang.Integer.parseInt(Integer.java:497)
 at 
 org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
 at 
 org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
 at 
 org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
 at 
 org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
 at 
 org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
 at 
 org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 The big problem with this exception is that it does not tell you which field 
 is invalid

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online

[jira] Resolved: (TUSCANY-2228) Setting an Integer Property with a non-number throws NumberFormatException - but for which Property?

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2228.
--

Resolution: Fixed

Added unti test for JavaPropertyValueObjectFactory in SVN revision 648256.

Marking bug as fixed.

 Setting an Integer Property with a non-number throws NumberFormatException - 
 but for which Property?
 

 Key: TUSCANY-2228
 URL: https://issues.apache.org/jira/browse/TUSCANY-2228
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision 648161
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If I define a Property on my Component as type int and then attempt to set 
 the property value in the XML to a non-number (e.g. the String Hello), 
 Tuscany will throw the following exception:
 org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
 input string: 
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
 stack trace snipped here
 Caused by: java.lang.NumberFormatException: For input string: 
 at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
 at java.lang.Integer.parseInt(Integer.java:468)
 at java.lang.Integer.parseInt(Integer.java:497)
 at 
 org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
 at 
 org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
 at 
 org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
 at 
 org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
 at 
 org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
 at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
 at 
 org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
 at 
 org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
 at 
 org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:109)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 The big problem with this exception is that it does not tell you which field 
 is invalid

-- 
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]

Latest continuum builds are failing due to test failures in itest/osgi-implementation with new test cases helloworld.sdo

[Mark Combellack]

Hi,

 

Over the last few days, the continuum build has been failing for the trunk
of Tuscany. The problem is that two tests are failing in
itest/osgi-implementation. The relevant error messages are:

 

 

testJavaToOSGi(helloworld.sdo.SdoTestCase)  Time elapsed: 0.424 sec  
ERROR!

java.lang.NoClassDefFoundError

  at
helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien
tComponent.java:33)

  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.JavaImplementationInvo
ker.invoke(JavaImplementationInvoker.java:109)

  at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
assByValueInterceptor.java:108)

  at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingI
nvoker.java:61)

  at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
assByValueInterceptor.java:108)

  at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:286)

  at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:154)

  at $Proxy141.getGreetings(Unknown Source)

  at helloworld.sdo.SdoTestCase.testJavaToOSGi(SdoTestCase.java:81)

  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 junit.framework.TestCase.runTest(TestCase.java:168)

  at junit.framework.TestCase.runBare(TestCase.java:134)

  at junit.framework.TestResult$1.protect(TestResult.java:110)

  at junit.framework.TestResult.runProtected(TestResult.java:128)

  at junit.framework.TestResult.run(TestResult.java:113)

  at junit.framework.TestCase.run(TestCase.java:124)

  at junit.framework.TestSuite.runTest(TestSuite.java:232)

  at junit.framework.TestSuite.run(TestSuite.java:227)

  at
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35
)

  at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62
)

  at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Ab
stractDirectoryTestSuite.java:138)

  at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD
irectoryTestSuite.java:125)

  at org.apache.maven.surefire.Surefire.run(Surefire.java:132)

  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

  at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

  at java.lang.reflect.Method.invoke(Method.java:585)

  at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB
ooter.java:308)

  at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879
)

 

testOSGiToJava(helloworld.sdo.SdoTestCase)  Time elapsed: 0.278 sec  
ERROR!

java.lang.NoClassDefFoundError

  at
helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien
tComponent.java:33)

  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.osgi.invocation.OSGiTargetInvoker.invo
keMethod(OSGiTargetInvoker.java:171)

  at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.i
nvokeMethod(OSGiRemotableInvoker.java:75)

  at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo
keTarget(OSGiTargetInvoker.java:143)

  at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo
ke(OSGiTargetInvoker.java:188)

  at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
assByValueInterceptor.java:103)

  at
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingI
nvoker.java:61)

  at
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
assByValueInterceptor.java:103)

  at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:286)

  at
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
tionHandler.java:154)

  at $Proxy141.getGreetings(Unknown 

[jira] Commented: (TUSCANY-2225) RuntimeExceptions thrown by @OneWay methods are not logged anywhere

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588532#action_12588532
 ] 

Mark Combellack commented on TUSCANY-2225:
--

The problem actually comes from the use of the 
org.apache.tuscany.sca.core.invocation.NonBlockingInterceptor from the core 
module.

The code contains the following in the invoke method:

workScheduler.scheduleWork(new Runnable() {
public void run() {
Message context = 
ThreadMessageContext.setMessageContext(msg);
try {
next.invoke(msg);
} finally {
ThreadMessageContext.setMessageContext(context);
}
}
});

The code will:

1) Use the WorkSchedular to run the @OneWay operation in a separate thread. 
2) That separate thread will call next.invoke(msg) which will return the result 
of running the @OneWay invocation
3) The return value from next.invoke() will be the result message (will call it 
result). Since the @OneWay method threw an Exception, result.isFault() is true
4) The above code does not bother to check the result to see if it is an 
exception. It just completely ignores the return value.



What the code should do is check whether the return value from  
next.invoke(msg) indicates an exception. If it does, then it should handle it 
appropriately.

 RuntimeExceptions thrown by @OneWay methods are not logged anywhere
 ---

 Key: TUSCANY-2225
 URL: https://issues.apache.org/jira/browse/TUSCANY-2225
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: trunk svn revision 647147
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If a @OneWay method throws a RuntimeException, the exception is lost. It is 
 not logged anywhere and there is no way to tell it has happened. This makes 
 it extremely hard for a developer to debug problems with @OneWay methods in 
 their applications.
 The client code that invokes the @OneWay method will not be told of the 
 failure as per the contract of the @OneWay scemantics.
 However, the fact that the exception occurred should be recorded somwhere so 
 the developer can attempt to diagnose the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2225) RuntimeExceptions thrown by @OneWay methods are not logged anywhere

[Mark Combellack (JIRA)]

RuntimeExceptions thrown by @OneWay methods are not logged anywhere
---

 Key: TUSCANY-2225
 URL: https://issues.apache.org/jira/browse/TUSCANY-2225
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: trunk svn revision 647147
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


If a @OneWay method throws a RuntimeException, the exception is lost. It is not 
logged anywhere and there is no way to tell it has happened. This makes it 
extremely hard for a developer to debug problems with @OneWay methods in their 
applications.

The client code that invokes the @OneWay method will not be told of the failure 
as per the contract of the @OneWay scemantics.

However, the fact that the exception occurred should be recorded somwhere so 
the developer can attempt to diagnose the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2225) RuntimeExceptions thrown by @OneWay methods are not logged anywhere

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588551#action_12588551
 ] 

Mark Combellack commented on TUSCANY-2225:
--

I've updated the code in 
org.apache.tuscany.sca.core.invocation.NonBlockingInterceptor to check for 
exceptions as a result of invoke(). The code will now throw 
ServiceRuntimeException. This is now propogated up to the ThreadPoolWorkManager.

The ThreadPoolWorkManager now detects the Exception being thrown and calls the 
workCompleted() with the exception that was thrown. This will then lookup the 
listener and notify it of the failure.

The problem is that Tuscany does not register a listener so the Exception is 
still ignored!

 RuntimeExceptions thrown by @OneWay methods are not logged anywhere
 ---

 Key: TUSCANY-2225
 URL: https://issues.apache.org/jira/browse/TUSCANY-2225
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: trunk svn revision 647147
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 If a @OneWay method throws a RuntimeException, the exception is lost. It is 
 not logged anywhere and there is no way to tell it has happened. This makes 
 it extremely hard for a developer to debug problems with @OneWay methods in 
 their applications.
 The client code that invokes the @OneWay method will not be told of the 
 failure as per the contract of the @OneWay scemantics.
 However, the fact that the exception occurred should be recorded somwhere so 
 the developer can attempt to diagnose the problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Error Logging - how should it done in Tuscany?

[Mark Combellack]

Hi,

Whilst fixing a bug[1] I wanted to log an error message. I've realised that
I'm not clear on Tuscany's policy on how this should be done.

I've had a look through the developer guides [2] and [3] (we have more than
1?) but neither mention anything about logging.


To narrow the scope of this question a little bit, I am not talking about
tracing execution (method entry/exit). I am talking about logging runtime
errors.


Having a scan through the Developer Mailing List, I could not find anything
conclusive on the subject. There was a discussion in August 2007 [4] that
seems to suggest the use of AOP and JDK Logging although no formal decision
seems to have been made.

Looking through the code, there appears to be a few strategies for logging:

   *) Don't do any logging
   *) Log to the Console - e.g. e.printStackTrace()
   *) Use JDK logging.



The scenario I ran into in the bug [1] was that a @OneWay invocation has
thrown a RuntimeException (e.g. NullPointerException). The original invoking
client is no longer around as a new Thread has been used to invoke the
@OneWay operation. The exception could just ripple up through and kill the
thread but this is not very nice. What I want to do is log the Exception so
the fact it happened can be recorded in a log.



From a personal perspective, I think we could consider using something like
SL4J [5]. Tuscany is very likely to be integrated into other
applications/containers (e.g. Tomcat, WebSphere, etc) so SL4J would allow
the same Tuscany logging code to use different logging back ends (e.g.
log4j, JDK Logging, console, etc) depending on the environment in which it
is running.



So  (takes a step back as he fears he might be opening a can of
worms) what is the general opinion on how logging should be done in
Tuscany?

Thanks,

Mark

[1] https://issues.apache.org/jira/browse/TUSCANY-2225
[2] http://cwiki.apache.org/TUSCANY/sca-java-development.html
[3] http://cwiki.apache.org/TUSCANY/java-sca-developer-guide.html
[4] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21735.html
[5] http://www.slf4j.org/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: SCA 2.0, was Re: Next SCA release

[Mark Combellack]

 -Original Message-
 From: ant elder [mailto:[EMAIL PROTECTED]
 Sent: 10 April 2008 12:26
 To: tuscany-dev@ws.apache.org
 Subject: Re: SCA 2.0, was Re: Next SCA release
 
 On Thu, Apr 10, 2008 at 12:01 PM, Simon Laws [EMAIL PROTECTED]
 wrote:
 
  On Thu, Apr 10, 2008 at 8:12 AM, ant elder [EMAIL PROTECTED] wrote:
 
   On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino 
   [EMAIL PROTECTED] wrote:
  
   snip
  
  
1.3 sounds good to me. I'm assuming that we'll cut that branch out
 of
trunk?
   
I'm asking because I'm interested in working on some improvements of
  1.2
in the next few weeks. This shouldn't delay any 2.0 work however,
  which
   can
go in parallel.
   
   
   That sounds scary.
  
   Are you saying you don't think its the right time for 2.0? I started
  this
   discussion to see if there was consensus to move to 2.0, if there's
 not
   consensus then we should not do it. The last thing we need is dev
 going
  on
   in multiple branches as happened in the old days.
  
 ...ant
  
 
  Maybe this means we should consider the trunk to be 1.X and branch for
 2.0
  at the point at which someone wants to start investigating 2.0. I've
 been
  thinking of this 2.0 exercise as investigative in the first instance
 hence
  [1]. By that I mean that I would fully expect us to do other 1.X
 releases
  before any 2.0 features appear in released form.
 
  B.t.w - have copied in the user list as we neglected to do this and this
  is
  as much a user discussion as a developer discussion.
 
  Simon
 
 
 Keeping maintenance branches going and porting fixes from trunk back to
 them
 seems fine but as has been demonstrated several times in Tuscany's history
 we are not able to maintain a consensus based approach to development when
 new development is going on in multiple branches. If we're not ready to
 make
 backward compatibility breaking changes to the trunk code then IMHO we
 should just wait.
 
...ant


It all depends on the development focus. I am presuming that:

   * Version 2.x will be the main focus
  * Most of the development effort happens on Version 2.x
  * We will make API changes which means that it will not be backwards
compatible with version 1
   * Version 1.x will go into maintenance mode.
  * May get some bug fixes and minor updates

If my presumptions are correct then, from my point of view, we should keep
the trunk as the most up to date version - i.e. Version 2.
 
Any maintenance for previous Version 1.x release should be done on their own
branches.



ant also makes an interesting point about timing. Without clear goals and
objectives for Version 2.x, perhaps we should hold off on branching.

Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2216) DefaultContextFactoryExtensionPoint handling of null should be improved

[Mark Combellack (JIRA)]

DefaultContextFactoryExtensionPoint handling of null should be improved
---

 Key: TUSCANY-2216
 URL: https://issues.apache.org/jira/browse/TUSCANY-2216
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 644847
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


The JavaDoc for DefaultContextFactoryExtensionPoint is inclear as to what will 
happen if a null is passed into the methods. What actually happens is that it 
throws a NullPointerException.

After discussions in:

http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30064.html

I'm going to add a null check and throw IllegalArgumentException

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2216) DefaultContextFactoryExtensionPoint handling of null should be improved

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587765#action_12587765
 ] 

Mark Combellack commented on TUSCANY-2216:
--

Updated DefaultContextFactoryExtensionPoint to check for null in SVN revision 
646939

 DefaultContextFactoryExtensionPoint handling of null should be improved
 ---

 Key: TUSCANY-2216
 URL: https://issues.apache.org/jira/browse/TUSCANY-2216
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 644847
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 The JavaDoc for DefaultContextFactoryExtensionPoint is inclear as to what 
 will happen if a null is passed into the methods. What actually happens is 
 that it throws a NullPointerException.
 After discussions in:
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30064.html
 I'm going to add a null check and throw IllegalArgumentException

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2216) DefaultContextFactoryExtensionPoint handling of null should be improved

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2216.
--

Resolution: Fixed

Added unit test for DefaultContextFactoryExtensionPoint in 646940

 DefaultContextFactoryExtensionPoint handling of null should be improved
 ---

 Key: TUSCANY-2216
 URL: https://issues.apache.org/jira/browse/TUSCANY-2216
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 644847
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 The JavaDoc for DefaultContextFactoryExtensionPoint is inclear as to what 
 will happen if a null is passed into the methods. What actually happens is 
 that it throws a NullPointerException.
 After discussions in:
 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30064.html
 I'm going to add a null check and throw IllegalArgumentException

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2213) Cannot Serialize and deserailize a CallableReference injected using a @Callback - Is this a valid use case?

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587144#action_12587144
 ] 

Mark Combellack commented on TUSCANY-2213:
--

I've added an iTest for testing Serializing ServiceRefernces and 
CallableReferences in SVN revision 646273.

Currently, Serializing the ServiceReference works. Serializing the 
CallableReference fails so the test is marked as @Ignore

 Cannot Serialize and deserailize a CallableReference injected using a 
 @Callback - Is this a valid use case?
 ---

 Key: TUSCANY-2213
 URL: https://issues.apache.org/jira/browse/TUSCANY-2213
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn trunk revision 645821
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 I've got a bidirectional Service that uses @Callback to inject a 
 CalalbleReference 
 When a method is called on the Service, I Serialise and then deserialise the 
 CallableReference before it is used to invoke the client. I do this to 
 simulate persisting the CallableReference and then using it again later.
 The stack trace I get is:
 java.io.IOException
   at 
 org.apache.tuscany.sca.core.context.CallableReferenceImpl.writeExternal(CallableReferenceImpl.java:361)
   at 
 java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310)
   at 
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288)
   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
   at 
 org.apache.tuscany.sca.itest.servicereference.utils.ServiceReferenceUtils.serialize(ServiceReferenceUtils.java:57)
   at 
 org.apache.tuscany.sca.itest.servicereference.StatelessServiceImpl.triggerCallback(StatelessServiceImpl.java:70)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
   at $Proxy14.triggerCallback(Unknown Source)
   at 
 org.apache.tuscany.sca.itest.servicereference.SCAManagedClientImpl.testSerializeCallbackToStatelessServiceInsideSCA(SCAManagedClientImpl.java:126)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
   at $Proxy13.testSerializeCallbackToStatelessServiceInsideSCA(Unknown 
 Source)
   at 
 org.apache.tuscany.sca.itest.servicereference.SerializeServiceReferenceTestCase.testSerializeCallbackToStatelessServiceInsideSCA(SerializeServiceReferenceTestCase.java:103)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
   at 
 org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
   at 
 org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75

[jira] Created: (TUSCANY-2213) Cannot Serialize and deserailize a CallableReference injected using a @Callback - Is this a valid use case?

[Mark Combellack (JIRA)]

Cannot Serialize and deserailize a CallableReference injected using a @Callback 
- Is this a valid use case?
---

 Key: TUSCANY-2213
 URL: https://issues.apache.org/jira/browse/TUSCANY-2213
 Project: Tuscany
  Issue Type: Task
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn trunk revision 645821
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


I've got a bidirectional Service that uses @Callback to inject a 
CalalbleReference 

When a method is called on the Service, I Serialise and then deserialise the 
CallableReference before it is used to invoke the client. I do this to simulate 
persisting the CallableReference and then using it again later.

The stack trace I get is:

java.io.IOException
at 
org.apache.tuscany.sca.core.context.CallableReferenceImpl.writeExternal(CallableReferenceImpl.java:361)
at 
java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310)
at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at 
org.apache.tuscany.sca.itest.servicereference.utils.ServiceReferenceUtils.serialize(ServiceReferenceUtils.java:57)
at 
org.apache.tuscany.sca.itest.servicereference.StatelessServiceImpl.triggerCallback(StatelessServiceImpl.java:70)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at 
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy14.triggerCallback(Unknown Source)
at 
org.apache.tuscany.sca.itest.servicereference.SCAManagedClientImpl.testSerializeCallbackToStatelessServiceInsideSCA(SCAManagedClientImpl.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at 
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
at $Proxy13.testSerializeCallbackToStatelessServiceInsideSCA(Unknown 
Source)
at 
org.apache.tuscany.sca.itest.servicereference.SerializeServiceReferenceTestCase.testSerializeCallbackToStatelessServiceInsideSCA(SerializeServiceReferenceTestCase.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at 
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at 
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at 
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
at 
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
at 
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34

[jira] Created: (TUSCANY-2208) ComponentContext.createSelfReference() does not create a ServiceReference to the correct Conversation

[Mark Combellack (JIRA)]

ComponentContext.createSelfReference() does not create a ServiceReference to 
the correct Conversation
-

 Key: TUSCANY-2208
 URL: https://issues.apache.org/jira/browse/TUSCANY-2208
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 645782
Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


I've been trying to create a ServiceReference to a Conversational Component 
using the ComponentContext.createSelfReference() method. The code correctly 
creates a ServiceReference but when I call ServiceReference.getService(), it 
creates a new instance of the Component rather than returning to the original 
instance.

I am speculating that the Conversation ID is not being added to the 
ServiceReference that is being created by the 
ComponentContext.createSelfReference() method.

I've created an iTest that illustrates this problem that I will commit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2029) Multiple levels of Nested Composite References do not work as they are using the wrong URI in the binding

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2029.
--

Resolution: Fixed

Fixed in SVN revision 645827.

 Multiple levels of Nested Composite References do not work as they are using 
 the wrong URI in the binding
 -

 Key: TUSCANY-2029
 URL: https://issues.apache.org/jira/browse/TUSCANY-2029
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision #619319
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 When using a reference to a nested composite containing another nested 
 composite, the binding is using the wrong URI so it does not find the target.
 For example, in the case of a reference to a nested nested composite, the 
 service has the URI of:
 SomeComposite/SomeOtherComposite/SomeComponent/SomeService
 But the reference lookup is using the URI of the component service and is 
 ignoring the nesting
 SomeComponent/SomeService 
 This means that references to nested nested composites do not work.
 Previously, I fixed nested nested composite services as part of TUSCANY-2027. 
 This is the other half of the problem to get references to work.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2208) ComponentContext.createSelfReference() does not create a ServiceReference to the correct Conversation

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586723#action_12586723
 ] 

Mark Combellack commented on TUSCANY-2208:
--

I've had a look at the code and I cannot work out how to fix this one.

 ComponentContext.createSelfReference() does not create a ServiceReference to 
 the correct Conversation
 -

 Key: TUSCANY-2208
 URL: https://issues.apache.org/jira/browse/TUSCANY-2208
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 645782
 Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


 I've been trying to create a ServiceReference to a Conversational Component 
 using the ComponentContext.createSelfReference() method. The code correctly 
 creates a ServiceReference but when I call ServiceReference.getService(), it 
 creates a new instance of the Component rather than returning to the original 
 instance.
 I am speculating that the Conversation ID is not being added to the 
 ServiceReference that is being created by the 
 ComponentContext.createSelfReference() method.
 I've created an iTest that illustrates this problem that I will commit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2208) ComponentContext.createSelfReference() does not create a ServiceReference to the correct Conversation

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586722#action_12586722
 ] 

Mark Combellack commented on TUSCANY-2208:
--

I've added two new tests:

Validate createSelfReference using ConversationID()

   1) Create new Conversational Component
   2) Test case stores ConversationID created in step 1
   3) Conversational Component creates a Self Reference
   4) Test case uses Self Reference created in Step 3 to reget Conversational 
Component
   5) Test case re-gets the Conversation ID.
   6) Conversation ID from step 2 and step 5 should be the same.

Validate createSelfReference using Application Data

   1) Create new Conversational Component
   2) Test case stores some application data in the Conversational Component
   3) Conversational Component creates a Self Reference
   4) Test case uses Self Reference created in Step 3 to reget Conversational 
Component
   5) Test case re-gets the application data
   6) Application data from step 2 and step 5 should be the same.

I've committed the iTest in SVN revision 645808.

Note: The tests are disabled as they do not pass. To enable the tests, just 
remove the // from @Test in the class  CallableReferenceConversationalTestCase

 ComponentContext.createSelfReference() does not create a ServiceReference to 
 the correct Conversation
 -

 Key: TUSCANY-2208
 URL: https://issues.apache.org/jira/browse/TUSCANY-2208
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 645782
 Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


 I've been trying to create a ServiceReference to a Conversational Component 
 using the ComponentContext.createSelfReference() method. The code correctly 
 creates a ServiceReference but when I call ServiceReference.getService(), it 
 creates a new instance of the Component rather than returning to the original 
 instance.
 I am speculating that the Conversation ID is not being added to the 
 ServiceReference that is being created by the 
 ComponentContext.createSelfReference() method.
 I've created an iTest that illustrates this problem that I will commit.

-- 
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-2190) Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server as it uses port 8080

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack updated TUSCANY-2190:
-

Assignee: (was: Mark Combellack)

 Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum 
 server as it uses port 8080
 

 Key: TUSCANY-2190
 URL: https://issues.apache.org/jira/browse/TUSCANY-2190
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Demos
Affects Versions: Java-SCA-1.2
 Environment: Tuscany 1.2 branch
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


 The demos/alert-aggregator-webapp project uses port 8080 for the demo. This 
 port is in use on the Continuum server so the build fails.
 Some extracts from the build log.
 2008-04-02 12:41:00.187::INFO:  Extract 
 jar:file:/home/continuum/data/working-directory/557/demos/alert-aggregator-webapp/target/cargo-jetty/cargocpc.war!/
  to /tmp/Jetty_0_0_0_0_8080_cargocpc.war__cargocpc__xflgf3/webapp
 2008-04-02 12:41:02.245::WARN:  failed SelectChannelConnector @ 0.0.0.0:8080
 java.net.BindException: Address already in use
 at sun.nio.ch.Net.bind(Native Method)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] Failed to start the Jetty 6.x Embedded container.
 Deployable [http://localhost:8080/cargocpc/index.html] failed to finish 
 deploying within the timeout period [12]. The Deployable state is thus 
 unknown.
 [INFO] 
 
 [INFO] Trace
 org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 
 6.x Embedded container.
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:160)
 at 
 org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:61)
 at 
 org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:243)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:155)
 ... 20 more
 org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212

How should parameters be validate for methods on the core-SPI? - Document in JavaDoc and: Throw IllegalArgumentException? Do nothing? Use Asserts?

[Mark Combellack]

Hi,

 

I was using the core-spi project and ran into a NullPointerException because
I passed a null into a method. Reading the JavaDoc for the method, it did
not say that I was not allowed to pass a null into the method.

 

 

The case that I ran into of the
ContextFactoryExtensionPoint.addFactory(Object factory) method. The JavaDoc
says:

 

  /**

   * Add a context factory extension.

   *

   * @param factory The factory to add

   */

 

The problem is that it does not provide any details of what happens if a
null value is passed in for the factory parameter. What actually happens in
the code is that it throws a NullPointerException.

 

 

As the core-spi is a public API, we should be very clear to the developers
that use it what will happen.

 

 

 

My question is how should we handle this? The JavaDoc should be updated to
include information about what will happen if a null is passed in. The
question is - what should the Tuscany code do? Options include:

 

 

1) Do an if check and throw an IllegalArgumentException.

 

2) Don't do anything else - just document it in the JavaDoc. If the user is
stupid enough to pass null into a method that should not be passed a null
then they deserve what they get.

 

3) Use Java Asserts. When things start going wrong, enable Asserts and the
error will be spotted. Since it is an Assert, it has no cost a runtime if
Asserts are off.

 

 

Personally, I would update the JavaDoc and do option 1 - throw
IllegalArgumentException.

 

 

I'm interested in what other people think and if there is a current policy
for handling this kind of error in Tuscany?

 

Assuming that people are in general agreement with doing option 1, I will
update the core-spi accordingly.

 

Thanks,

 

Mark

 

[jira] Commented: (TUSCANY-2198) Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum build server

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585475#action_12585475
 ] 

Mark Combellack commented on TUSCANY-2198:
--

This error only occurs ocassionally on the Continuum server. It builds without 
issue on my local machine.

Investigating further, the code does:

customer.purchaseBooks();
assertFalse(customer.hasOutstandingOrders());

The purchaseBooks method calls several methods and then the notifyShipment() 
method is called to notify the customer that the order has been shipped. In the 
notifyShipment() method, the order is cleared from the list of Outstanding 
Orders

The issue is that the notifyShipment() method is @OneWay so is executed 
asynchronously. When the Continuum server is heavily loaded, the assert in the 
code above is executed before the notifyShipment() method is called. As a 
result, the assert fails.


To fix this bug, we must allow some time for the notifyShipment() method to 
complete before doing the assert.

 Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum 
 build server
 -

 Key: TUSCANY-2198
 URL: https://issues.apache.org/jira/browse/TUSCANY-2198
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 The build of itest/osgi-implementation has jsut failed on the Continuum build 
 server.
 The build output is at:
 http://vmbuild.apache.org/continuum/buildResult.action?buildId=73096projectId=277
 The relevant fragment is:
 Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
 Activated OSGiCustomerComponentImpl bundle 
 OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL 
 PROTECTED]
 Activated OSGiRetailerComponentImpl bundle 
 OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL 
 PROTECTED]
 JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL 
 PROTECTED]
 Activated OSGiShipperComponentImpl bundle 
 OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL 
 PROTECTED]
 Deactivated OSGiShipperComponentImpl bundle 
 Deactivated OSGiCustomerComponentImpl bundle 
 Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
 Activated OSGiCustomerComponentImpl bundle 
 Deactivated OSGiCustomerComponentImpl bundle 
 Deactivated OSGiRetailerComponentImpl bundle 
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.713 sec  
 FAILURE!
 test(supplychain.factory.DSFactoryTestCase)  Time elapsed: 0.701 sec   
 FAILURE!
 junit.framework.AssertionFailedError: null
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertFalse(Assert.java:34)
   at junit.framework.Assert.assertFalse(Assert.java:41)
   at supplychain.factory.FactoryTestCase.test(FactoryTestCase.java:42)
   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 junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
 org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
   at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308

[jira] Created: (TUSCANY-2198) Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum build server

[Mark Combellack (JIRA)]

Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum 
build server
-

 Key: TUSCANY-2198
 URL: https://issues.apache.org/jira/browse/TUSCANY-2198
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


The build of itest/osgi-implementation has jsut failed on the Continuum build 
server.

The build output is at:

http://vmbuild.apache.org/continuum/buildResult.action?buildId=73096projectId=277


The relevant fragment is:

Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
Activated OSGiCustomerComponentImpl bundle 
OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL PROTECTED]
Activated OSGiRetailerComponentImpl bundle 
OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL PROTECTED]
JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL PROTECTED]
Activated OSGiShipperComponentImpl bundle 
OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL PROTECTED]
Deactivated OSGiShipperComponentImpl bundle 
Deactivated OSGiCustomerComponentImpl bundle 
Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
Activated OSGiCustomerComponentImpl bundle 
Deactivated OSGiCustomerComponentImpl bundle 
Deactivated OSGiRetailerComponentImpl bundle 
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.713 sec  
FAILURE!
test(supplychain.factory.DSFactoryTestCase)  Time elapsed: 0.701 sec   
FAILURE!
junit.framework.AssertionFailedError: null
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertFalse(Assert.java:34)
at junit.framework.Assert.assertFalse(Assert.java:41)
at supplychain.factory.FactoryTestCase.test(FactoryTestCase.java:42)
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 junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at 
org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2198) Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum build server

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2198.
--

Resolution: Fixed

I've committed a fix that will wait up to 10 seconds for the @OneWay callback 
to happen. (SVN revision 644682)

Marking as fixed.

 Apache Tuscany SCA OSGi-SCA Integration Tests fail to build on the Continuum 
 build server
 -

 Key: TUSCANY-2198
 URL: https://issues.apache.org/jira/browse/TUSCANY-2198
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA OSGi Integration
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 The build of itest/osgi-implementation has jsut failed on the Continuum build 
 server.
 The build output is at:
 http://vmbuild.apache.org/continuum/buildResult.action?buildId=73096projectId=277
 The relevant fragment is:
 Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
 Activated OSGiCustomerComponentImpl bundle 
 OSGiCustomerComponentImpl.purchaseBooks, retailer1 is [Proxy - [EMAIL 
 PROTECTED]
 Activated OSGiRetailerComponentImpl bundle 
 OSGiRetailerComponentImpl.submitOrder , warehouse is [Proxy - [EMAIL 
 PROTECTED]
 JavaWarehouseComponentImpl.fulfillOrder : shipper is [Proxy - [EMAIL 
 PROTECTED]
 Activated OSGiShipperComponentImpl bundle 
 OSGiShipperComponentImpl.processShipment, customer is [Proxy - [EMAIL 
 PROTECTED]
 Deactivated OSGiShipperComponentImpl bundle 
 Deactivated OSGiCustomerComponentImpl bundle 
 Created OSGiCustomerComponentImpl [EMAIL PROTECTED]
 Activated OSGiCustomerComponentImpl bundle 
 Deactivated OSGiCustomerComponentImpl bundle 
 Deactivated OSGiRetailerComponentImpl bundle 
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.713 sec  
 FAILURE!
 test(supplychain.factory.DSFactoryTestCase)  Time elapsed: 0.701 sec   
 FAILURE!
 junit.framework.AssertionFailedError: null
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertFalse(Assert.java:34)
   at junit.framework.Assert.assertFalse(Assert.java:41)
   at supplychain.factory.FactoryTestCase.test(FactoryTestCase.java:42)
   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 junit.framework.TestCase.runTest(TestCase.java:168)
   at junit.framework.TestCase.runBare(TestCase.java:134)
   at junit.framework.TestResult$1.protect(TestResult.java:110)
   at junit.framework.TestResult.runProtected(TestResult.java:128)
   at junit.framework.TestResult.run(TestResult.java:113)
   at junit.framework.TestCase.run(TestCase.java:124)
   at junit.framework.TestSuite.runTest(TestSuite.java:232)
   at junit.framework.TestSuite.run(TestSuite.java:227)
   at 
 org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35)
   at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585038#action_12585038
 ] 

Mark Combellack commented on TUSCANY-2192:
--

Looking at the code, the key output is:

Finished callCount = 99 

This value should be 100.

I think the problem is that the unit test is not well coded to handle the case 
where the build server is heavily loaded as it has a sleep of 2 seconds and 
expects all @OneWay operations to complete in this time.

The test case needs to be updated to improve how it waits for all the @OneWay 
operations to complete.

 iTest/OneWay has just failed on the Continuum server and has blocked the 
 build on the root
 --

 Key: TUSCANY-2192
 URL: https://issues.apache.org/jira/browse/TUSCANY-2192
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277
 The Continuum build has failed in the Apache Tuscany SCA OneWay Integration 
 Tests
 The error output is:
 Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:50976/OneWayServiceComponent
 Finished callCount = 99
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec 
  FAILURE!
 testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)  Time elapsed: 
 45.55 sec   FAILURE!
 junit.framework.AssertionFailedError: expected:100 but was:99
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.failNotEquals(Assert.java:277)
   at junit.framework.Assert.assertEquals(Assert.java:64)
   at junit.framework.Assert.assertEquals(Assert.java:195)
   at junit.framework.Assert.assertEquals(Assert.java:201)
   at 
 org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
   at 
 org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
   at 
 org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
   at 
 org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
   at 
 org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
   at 
 org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
   at 
 org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
   at 
 org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
   at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
 Results :
 Failed tests: 
   testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2192.
--

Resolution: Fixed

I've improved the way in which the waiting for the @OnwWay methods to takes 
place. Instead of waiting for a fixed 2 seconds, it waits in a loop until all 
the @OneWay operations complete or 10 seconds passes.

These changes will speed up the tests since it does not need to wait the 
original 2 seconds on a fast computer and allows extra time for the @OneWay 
methods to complete on a slower computer.

Fixed in SVN revision 644255

 iTest/OneWay has just failed on the Continuum server and has blocked the 
 build on the root
 --

 Key: TUSCANY-2192
 URL: https://issues.apache.org/jira/browse/TUSCANY-2192
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277
 The Continuum build has failed in the Apache Tuscany SCA OneWay Integration 
 Tests
 The error output is:
 Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer 
 addServletMapping
 INFO: Added Servlet mapping: 
 http://vmbuild.apache.org:50976/OneWayServiceComponent
 Finished callCount = 99
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec 
  FAILURE!
 testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)  Time elapsed: 
 45.55 sec   FAILURE!
 junit.framework.AssertionFailedError: expected:100 but was:99
   at junit.framework.Assert.fail(Assert.java:47)
   at junit.framework.Assert.failNotEquals(Assert.java:277)
   at junit.framework.Assert.assertEquals(Assert.java:64)
   at junit.framework.Assert.assertEquals(Assert.java:195)
   at junit.framework.Assert.assertEquals(Assert.java:201)
   at 
 org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
   at 
 org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
   at 
 org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
   at 
 org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
   at 
 org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
   at 
 org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
   at 
 org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
   at 
 org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
   at 
 org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
   at 
 org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
   at 
 org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
   at 
 org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
 Results :
 Failed tests: 
   testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)
 Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2192) iTest/OneWay has just failed on the Continuum server and has blocked the build on the root

[Mark Combellack (JIRA)]

iTest/OneWay has just failed on the Continuum server and has blocked the build 
on the root
--

 Key: TUSCANY-2192
 URL: https://issues.apache.org/jira/browse/TUSCANY-2192
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Integration Tests
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


http://vmbuild.apache.org/continuum/buildResult.action?buildId=72567projectId=277

The Continuum build has failed in the Apache Tuscany SCA OneWay Integration 
Tests

The error output is:

Apr 2, 2008 6:31:23 PM org.apache.tuscany.sca.http.jetty.JettyServer 
addServletMapping
INFO: Added Servlet mapping: 
http://vmbuild.apache.org:50976/OneWayServiceComponent
Finished callCount = 99
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 45.584 sec  
FAILURE!
testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)  Time elapsed: 
45.55 sec   FAILURE!
junit.framework.AssertionFailedError: expected:100 but was:99
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at 
org.apache.tuscany.sca.itest.oneway.OneWayTestCase.testOneWay(OneWayTestCase.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at 
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at 
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at 
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
at 
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
at 
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)


Results :

Failed tests: 
  testOneWay(org.apache.tuscany.sca.itest.oneway.OneWayTestCase)

Tests run: 1, Failures: 1, Errors: 0, Skipped: 0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585136#action_12585136
 ] 

Mark Combellack commented on TUSCANY-2194:
--

The problem is actually in the 
org.apache.tuscany.sca.interfacedef.OverloadedOperationException class itself. 
The constructor takes the Opeation as a parameter but it does not specify a 
detailed message for the exception. Therefore, the exception will just output 
the exception name and no details about the overloaded method.

 When a @Remotable interface a duplicate operation, it does not list the class 
 name or method in the exception that is thrown
 

 Key: TUSCANY-2194
 URL: https://issues.apache.org/jira/browse/TUSCANY-2194
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 644273 on the root
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 When a @Remotable interface contains two methods with the same name, Tuscany 
 will throw an OverloadedOperationException. The only problem is that when 
 this exception is output to the console, it does not list the method name or 
 class that has the problem. This makes finding the issue very hard as you 
 don't know where to start.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown

[Mark Combellack (JIRA)]

When a @Remotable interface a duplicate operation, it does not list the class 
name or method in the exception that is thrown


 Key: TUSCANY-2194
 URL: https://issues.apache.org/jira/browse/TUSCANY-2194
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 644273 on the root
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


When a @Remotable interface contains two methods with the same name, Tuscany 
will throw an OverloadedOperationException. The only problem is that when this 
exception is output to the console, it does not list the method name or class 
that has the problem. This makes finding the issue very hard as you don't know 
where to start.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2194) When a @Remotable interface a duplicate operation, it does not list the class name or method in the exception that is thrown

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2194.
--

Resolution: Fixed

I've updated the text for the the OperationOverloadedException to include the 
method and class names. This should make fixing this issue easier for the user.

The fix is in SVN revision 644358 in modules/interface

I've also added a unit test in SVN revision 644365 in modules/interface-java

Note: These changes are on the root. I have not rippled them up to the 1.2 
branch

 When a @Remotable interface a duplicate operation, it does not list the class 
 name or method in the exception that is thrown
 

 Key: TUSCANY-2194
 URL: https://issues.apache.org/jira/browse/TUSCANY-2194
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN revision 644273 on the root
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 When a @Remotable interface contains two methods with the same name, Tuscany 
 will throw an OverloadedOperationException. The only problem is that when 
 this exception is output to the console, it does not list the method name or 
 class that has the problem. This makes finding the issue very hard as you 
 don't know where to start.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2185) Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS samples

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584473#action_12584473
 ] 

Mark Combellack commented on TUSCANY-2185:
--

I think the problem is due to activemq should be a compile dependency in the 
pom.xml.

The following commit makes the change on the root but this has not been rippled 
into the 1.2 branch

http://svn.apache.org/viewvc?view=revsortby=daterevision=643527

the pom.xml changes in 
http://svn.apache.org/viewvc?view=revsortby=daterevision=629037


 Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS 
 samples
 ---

 Key: TUSCANY-2185
 URL: https://issues.apache.org/jira/browse/TUSCANY-2185
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Reporter: ant elder
Priority: Blocker
 Fix For: Java-SCA-1.2


 I get the following compile errors when building the samples in the 1.2 
 branch:
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Web Service JMS 
 Sample (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.
 broker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[32,21]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,38]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[43,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Service JMS Sample 
 (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.bro
 ker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[24,44]
  package org.apache.tuscany.sca.
 host.embedded does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class SCADomain
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,24]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,51]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[42,36]
  cannot find symbol
 symbol  : variable SCADomain
 location: class helloworld.HelloWorldServer

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2185) Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS samples

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584469#action_12584469
 ] 

Mark Combellack commented on TUSCANY-2185:
--

I've noticed that the Continuum build currently fails because of this issue.

I've just done a full rebuild of the Tuscany root with an empty Maven 
repository and it builds without this error. Looks like it is specific to the 
1.2 branch
  



 Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS 
 samples
 ---

 Key: TUSCANY-2185
 URL: https://issues.apache.org/jira/browse/TUSCANY-2185
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Reporter: ant elder
Priority: Blocker
 Fix For: Java-SCA-1.2


 I get the following compile errors when building the samples in the 1.2 
 branch:
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Web Service JMS 
 Sample (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.
 broker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[32,21]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,38]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[43,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Service JMS Sample 
 (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.bro
 ker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[24,44]
  package org.apache.tuscany.sca.
 host.embedded does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class SCADomain
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,24]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,51]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[42,36]
  cannot find symbol
 symbol  : variable SCADomain
 location: class helloworld.HelloWorldServer

-- 
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] Assigned: (TUSCANY-2185) Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS samples

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack reassigned TUSCANY-2185:


Assignee: Mark Combellack

 Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS 
 samples
 ---

 Key: TUSCANY-2185
 URL: https://issues.apache.org/jira/browse/TUSCANY-2185
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Reporter: ant elder
Assignee: Mark Combellack
Priority: Blocker
 Fix For: Java-SCA-1.2


 I get the following compile errors when building the samples in the 1.2 
 branch:
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Web Service JMS 
 Sample (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.
 broker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[32,21]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,38]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[43,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Service JMS Sample 
 (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.bro
 ker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[24,44]
  package org.apache.tuscany.sca.
 host.embedded does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class SCADomain
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,24]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,51]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[42,36]
  cannot find symbol
 symbol  : variable SCADomain
 location: class helloworld.HelloWorldServer

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2185) Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS samples

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584538#action_12584538
 ] 

Mark Combellack commented on TUSCANY-2185:
--

I've committed fixes for this problem. The projects build locally without 
issue. Waiting for Continuum build to complete to verify fix.

 Compile errors in the HelloWorld Web Service JMS and HelloWorld Service JMS 
 samples
 ---

 Key: TUSCANY-2185
 URL: https://issues.apache.org/jira/browse/TUSCANY-2185
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Samples
Affects Versions: Java-SCA-1.2
Reporter: ant elder
Assignee: Mark Combellack
Priority: Blocker
 Fix For: Java-SCA-1.2


 I get the following compile errors when building the samples in the 1.2 
 branch:
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Web Service JMS 
 Sample (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.
 broker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[32,21]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,38]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-ws-service-jms\src\main\java\helloworld\HelloWorldServer.java:[43,8]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 [INFO] 
 
 [INFO] Error for project: Apache Tuscany SCA HelloWorld Service JMS Sample 
 (during install)
 [INFO] 
 
 [INFO] Compilation failure
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[23,34]
  package org.apache.activemq.bro
 ker does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[24,44]
  package org.apache.tuscany.sca.
 host.embedded does not exist
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[33,8]
  cannot find symbol
 symbol  : class SCADomain
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,24]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[35,51]
  cannot find symbol
 symbol  : class BrokerService
 location: class helloworld.HelloWorldServer
 C:\Tuscany\SVN\1.2-BRN\samples\helloworld-service-jms\src\main\java\helloworld\HelloWorldServer.java:[42,36]
  cannot find symbol
 symbol  : variable SCADomain
 location: class helloworld.HelloWorldServer

-- 
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: Adding SVN version to Java files

[Mark Combellack]

I was wondering if we are any closer to a consensus on me adding @version to
the headers. I realise ant has said he would prefer not to do this.

Should I start adding them or should I not bother with this change?

Thanks,

Mark

-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] 
Sent: 31 March 2008 20:01
To: tuscany-dev@ws.apache.org
Subject: Re: Adding SVN version to Java files

ant elder wrote:
 On Mon, Mar 31, 2008 at 7:27 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:
 
 Mark Combellack wrote:
 Hi,

 I've been looking through the Tuscany source code and noticed that some
 files have a @version containing the SVN revision number in their
 JavaDoc
 headers but others do not.

 As an example, @version might look like:

 /**
  * Some JavaDoc for the class
  *
  * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
 2007) $
  */

 I would like to go through the Tuscany source code and add this header
 where
 it is missing. This would involve a large number of minor changes to the
 Tuscany tree so I wanted to run it by everyone to make sure no-one had a
 problem with me doing this at this time.

 I'll probably start this next week unless there is an objection.

 Thanks,

 Mark

 We're next week now :)

 Here's a summary of what I've seen in that thread so far:
 - Mark would like to help add SVN revision headers to all files
 - Vamsi +0.5 and suggests to set up to add headers to new files
 - Luciano +1 and agrees to set up SVN and IDE for this
 - Ant prefers not to this, not useful and clutters up the code
 - Sebastien +1 and also suggests to set up our IDEs for this
 - Simon would it find useful and also happy to set up his IDE

 5 people seem to be reaching consensus, 1 prefers not to do it.

 Ant, do you still have any objections against doing this?


 Yep, I don't think we should do it.
 
 No one has given any even vaguely compelling reasons for using them but
for
 them to have the very occasional usefulness _everyone_ has to always have
it
 set up which will inevitably go wrong occasionally for someone which makes
 them completely unreliable anyway - how do you  know that src you're
looking
 at isn't one of the files which has been corrupted by someone with a bad
 environment? And it adds just another cause of negative emails to the ML
 when complaining that someone has done it wrong. All that is exactly what
 used to happen in the bad old days when we did use them.
 
 Doesn't using svn info work as a replacement in a lot of circumstances
 anyway? And if not then what are the circumstances where you're having to
 look at src out of version control or out of a released distro? This _is_
 open source so its normal to have access to the version control system not
 like in closed src dev when its more likely there'll be uncontrolled src
 floating around.
 
 And its yet another burden to place on Tuscany development, i just don't
 understand the feeling that somehow things would be better if we had more
 formal processes and procedures in place - not having many of those it
what
 I like about developing at Apache.
 
...ant
 

Are you saying that we should remove them? What if I want to add them to 
the new files I'm editing (which is what I'm doing at the moment). Are 
you going to object to these commits?

-- 
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]

RE: Adding SVN version to Java files

[Mark Combellack]

Personally, I would prefer not to do it incrementally as it relies on the
developers remembering to check whether each file they edit contains a
@version tag. This may not happen when you are concentrating on fixing a bug
that has nothing to do with a @version JavaDoc annotation

 

One other issue with doing it incrementally is that could be months/years
before we actually have the @version annotation on most/all files. Depending
on your point of view this may not be an issue.

 

Mark

 

  _  

From: Vamsavardhana Reddy [mailto:[EMAIL PROTECTED] 
Sent: 02 April 2008 14:58
To: tuscany-dev@ws.apache.org; [EMAIL PROTECTED]
Subject: Re: Adding SVN version to Java files

 

Can we add the missing headers as we modify existing files (not modify just
to add there headers) and add the headers as we create new files?

++Vamsi

On Wed, Apr 2, 2008 at 7:21 PM, Mark Combellack [EMAIL PROTECTED]
wrote:

I was wondering if we are any closer to a consensus on me adding @version to
the headers. I realise ant has said he would prefer not to do this.

Should I start adding them or should I not bother with this change?

Thanks,

Mark


-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED]
Sent: 31 March 2008 20:01
To: tuscany-dev@ws.apache.org
Subject: Re: Adding SVN version to Java files

ant elder wrote:
 On Mon, Mar 31, 2008 at 7:27 PM, Jean-Sebastien Delfino 
 [EMAIL PROTECTED] wrote:

 Mark Combellack wrote:
 Hi,

 I've been looking through the Tuscany source code and noticed that some
 files have a @version containing the SVN revision number in their
 JavaDoc
 headers but others do not.

 As an example, @version might look like:

 /**
  * Some JavaDoc for the class
  *
  * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
 2007) $
  */

 I would like to go through the Tuscany source code and add this header
 where
 it is missing. This would involve a large number of minor changes to the
 Tuscany tree so I wanted to run it by everyone to make sure no-one had a
 problem with me doing this at this time.

 I'll probably start this next week unless there is an objection.

 Thanks,

 Mark

 We're next week now :)

 Here's a summary of what I've seen in that thread so far:
 - Mark would like to help add SVN revision headers to all files
 - Vamsi +0.5 and suggests to set up to add headers to new files
 - Luciano +1 and agrees to set up SVN and IDE for this
 - Ant prefers not to this, not useful and clutters up the code
 - Sebastien +1 and also suggests to set up our IDEs for this
 - Simon would it find useful and also happy to set up his IDE

 5 people seem to be reaching consensus, 1 prefers not to do it.

 Ant, do you still have any objections against doing this?


 Yep, I don't think we should do it.

 No one has given any even vaguely compelling reasons for using them but
for
 them to have the very occasional usefulness _everyone_ has to always have
it
 set up which will inevitably go wrong occasionally for someone which makes
 them completely unreliable anyway - how do you  know that src you're
looking
 at isn't one of the files which has been corrupted by someone with a bad
 environment? And it adds just another cause of negative emails to the ML
 when complaining that someone has done it wrong. All that is exactly what
 used to happen in the bad old days when we did use them.

 Doesn't using svn info work as a replacement in a lot of circumstances
 anyway? And if not then what are the circumstances where you're having to
 look at src out of version control or out of a released distro? This _is_
 open source so its normal to have access to the version control system not
 like in closed src dev when its more likely there'll be uncontrolled src
 floating around.

 And its yet another burden to place on Tuscany development, i just don't
 understand the feeling that somehow things would be better if we had more
 formal processes and procedures in place - not having many of those it
what
 I like about developing at Apache.

...ant


Are you saying that we should remove them? What if I want to add them to
the new files I'm editing (which is what I'm doing at the moment). Are
you going to object to these commits?

--
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]

 

FW: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project

[Mark Combellack]

I've just tried to run a Tuscany SCA 1.2 branch build on the Continuum
server and it appears that the build was cancelled after 53 minutes of
runtime.

Does anyone have any ideas as to why the build might have been cancelled?

Thanks,

Mark

-Original Message-
From: Continuum VMBuild Server [mailto:[EMAIL PROTECTED] 
Sent: 02 April 2008 15:20
To: [EMAIL PROTECTED]
Subject: [continuum] BUILD ERROR: Apache Tuscany SCA Implementation Project

Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=72457project
Id=557

Build statistics:
  State: Error
  Previous State: Failed
  Started at: Wed 2 Apr 2008 06:06:18 -0700
  Finished at: Wed 2 Apr 2008 06:59:58 -0700
  Total time: 53m 39s
  Build Trigger: Forced
  Build Number: 19
  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: mcombellack @ Wed 2 Apr 2008 04:17:21 -0700
Comment: TUSCANY-2185 Fixed compilation problem by coping changes from SVN
revision 643527 from the root
Files changed:
 
/incubator/tuscany/branches/sca-java-1.2/samples/helloworld-service-jms/pom.
xml ( 643848 )

Changed: mcombellack @ Wed 2 Apr 2008 04:21:49 -0700
Comment: TUSCANY-2185 Fixed compilation problem by coping changes from SVN
revision 643527 from the root
Files changed:
 
/incubator/tuscany/branches/sca-java-1.2/samples/helloworld-ws-service-jms/p
om.xml ( 643850 )


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: 



Build Error:

org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The
build was cancelled
at
org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellComma
nd(AbstractBuildExecutor.java:216)
at
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(Ma
venTwoBuildExecutor.java:149)
at
org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute
(ExecuteBuilderContinuumAction.java:140)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAct
ion(DefaultBuildController.java:417)
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(Defa
ultBuildController.java:156)
at
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeT
ask(BuildProjectTaskExecutor.java:50)
at
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRu
nnable$1.run(ThreadedTaskQueueExecutor.java:116)
at
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.cal
l(Executors.java:442)
at
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.jav
a:176)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
Task(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(CommandLine
Utils.java:164)
at
org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLine
Utils.java:89)
at
org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShel
lCommand(DefaultShellCommandHelper.java:114)
at
org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShel
lCommand(DefaultShellCommandHelper.java:59)
at
org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellComma
nd(AbstractBuildExecutor.java:204)
... 11 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native 

[jira] Resolved: (TUSCANY-2180) Cannot invoke method on Service that implements multiple @Remotable interfaces with methods of the same name

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2180.
--

Resolution: Fixed

Fix and unit test for this issue committed to the root as SVN revision 643925

Marking as fixed.

 Cannot invoke method on Service that implements multiple @Remotable 
 interfaces with methods of the same name
 

 Key: TUSCANY-2180
 URL: https://issues.apache.org/jira/browse/TUSCANY-2180
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
 Environment: SVN Revision 643322
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 When a Component implementation class implements multiple @Remotable 
 interfaces which have methods with the same name, it is not possible to 
 invoke the duplicate method name on the second Remotable interrface.
 Consider the following example:
 I have two @Remotable services as defined by the following Java interfaces:
 @Remotable
 public interface LocalTimeService {
 Date getCurrentTime();
 }
 @Remotable
 public interface WorldTimeService {
 Date getCurrentTime(String timeZone);
 }
 I have a single Java Component that implements both of these @Remotable 
 Interfaces:
 @Service(interfaces = {LocalTimeService.class, WorldTimeService.class})
 public void class TimeServiceImpl implements LocalTimeService, 
 WorldTimeService {
 public Date getCurrentTime() {
 // Code not shown
 }
 public Date getCurrentTime(String timeZone) {
 // Code not shown
 }
 }
 If I invoke getCurrentTime(), the code will work
 If I invoke getCurrentTime(GMT), the code will fail. The stack trace is:
 java.lang.IllegalArgumentException: argument type mismatch
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:266)
   at 
 org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:101)
   at $Proxy20.getCurrentTime(Unknown Source)
   at detail removed.test(BServiceImpl.java:41)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2190) Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server as it uses port 8080

[Mark Combellack (JIRA)]

Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server 
as it uses port 8080


 Key: TUSCANY-2190
 URL: https://issues.apache.org/jira/browse/TUSCANY-2190
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Demos
Affects Versions: Java-SCA-1.2
 Environment: Tuscany 1.2 branch
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-1.2


The demos/alert-aggregator-webapp project uses port 8080 for the demo. This 
port is in use on the Continuum server so the build fails.

Some extracts from the build log.


2008-04-02 12:41:00.187::INFO:  Extract 
jar:file:/home/continuum/data/working-directory/557/demos/alert-aggregator-webapp/target/cargo-jetty/cargocpc.war!/
 to /tmp/Jetty_0_0_0_0_8080_cargocpc.war__cargocpc__xflgf3/webapp
2008-04-02 12:41:02.245::WARN:  failed SelectChannelConnector @ 0.0.0.0:8080
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)



[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Failed to start the Jetty 6.x Embedded container.
Deployable [http://localhost:8080/cargocpc/index.html] failed to finish 
deploying within the timeout period [12]. The Deployable state is thus 
unknown.
[INFO] 
[INFO] Trace
org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 6.x 
Embedded container.
at 
org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:160)
at 
org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:61)
at 
org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:243)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.codehaus.cargo.container.ContainerException: Deployable 
[http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
the timeout period [12]. The Deployable state is thus unknown.
at 
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
at 
org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212)
at 
org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:155)
... 20 more
org.codehaus.cargo.container.ContainerException: Deployable 
[http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
the timeout period [12]. The Deployable state is thus unknown.
at 
org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
at 
org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212)
at 
org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:155)
at 
org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:61)
at 
org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:243

[jira] Commented: (TUSCANY-2190) Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server as it uses port 8080

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584750#action_12584750
 ] 

Mark Combellack commented on TUSCANY-2190:
--

I've updated the port number to 8085. Waiting for Continuum build to re-run to 
verify fix

 Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum 
 server as it uses port 8080
 

 Key: TUSCANY-2190
 URL: https://issues.apache.org/jira/browse/TUSCANY-2190
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Demos
Affects Versions: Java-SCA-1.2
 Environment: Tuscany 1.2 branch
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-1.2


 The demos/alert-aggregator-webapp project uses port 8080 for the demo. This 
 port is in use on the Continuum server so the build fails.
 Some extracts from the build log.
 2008-04-02 12:41:00.187::INFO:  Extract 
 jar:file:/home/continuum/data/working-directory/557/demos/alert-aggregator-webapp/target/cargo-jetty/cargocpc.war!/
  to /tmp/Jetty_0_0_0_0_8080_cargocpc.war__cargocpc__xflgf3/webapp
 2008-04-02 12:41:02.245::WARN:  failed SelectChannelConnector @ 0.0.0.0:8080
 java.net.BindException: Address already in use
 at sun.nio.ch.Net.bind(Native Method)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] Failed to start the Jetty 6.x Embedded container.
 Deployable [http://localhost:8080/cargocpc/index.html] failed to finish 
 deploying within the timeout period [12]. The Deployable state is thus 
 unknown.
 [INFO] 
 
 [INFO] Trace
 org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 
 6.x Embedded container.
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:160)
 at 
 org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:61)
 at 
 org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:243)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:155)
 ... 20 more
 org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111

[jira] Commented: (TUSCANY-2190) Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server as it uses port 8080

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584751#action_12584751
 ] 

Mark Combellack commented on TUSCANY-2190:
--

If this change works, it will need to be done on the root branch as well.

 Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum 
 server as it uses port 8080
 

 Key: TUSCANY-2190
 URL: https://issues.apache.org/jira/browse/TUSCANY-2190
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Demos
Affects Versions: Java-SCA-1.2
 Environment: Tuscany 1.2 branch
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-1.2


 The demos/alert-aggregator-webapp project uses port 8080 for the demo. This 
 port is in use on the Continuum server so the build fails.
 Some extracts from the build log.
 2008-04-02 12:41:00.187::INFO:  Extract 
 jar:file:/home/continuum/data/working-directory/557/demos/alert-aggregator-webapp/target/cargo-jetty/cargocpc.war!/
  to /tmp/Jetty_0_0_0_0_8080_cargocpc.war__cargocpc__xflgf3/webapp
 2008-04-02 12:41:02.245::WARN:  failed SelectChannelConnector @ 0.0.0.0:8080
 java.net.BindException: Address already in use
 at sun.nio.ch.Net.bind(Native Method)
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] Failed to start the Jetty 6.x Embedded container.
 Deployable [http://localhost:8080/cargocpc/index.html] failed to finish 
 deploying within the timeout period [12]. The Deployable state is thus 
 unknown.
 [INFO] 
 
 [INFO] Trace
 org.codehaus.cargo.container.ContainerException: Failed to start the Jetty 
 6.x Embedded container.
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:160)
 at 
 org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:61)
 at 
 org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:243)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
 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.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:212)
 at 
 org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:155)
 ... 20 more
 org.codehaus.cargo.container.ContainerException: Deployable 
 [http://localhost:8080/cargocpc/index.html] failed to finish deploying within 
 the timeout period [12]. The Deployable state is thus unknown.
 at 
 org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111

Apache Tuscany SCA Alert Aggregator Demo fails to build on the Continuum server as it uses port 8080 - svn commit 644032

[Mark Combellack]

Hi,

I've just made the following commit to the Tuscany 1.2 branch to fix a
problem with the build failing on the Continuum server as it was using port
8085. (https://issues.apache.org/jira/browse/TUSCANY-2190)

I've changed the port number to port 8085 and the unit tests build.

After some thinking, I am wondering if this will have broken the sample as
it is also supposed to deploy on Tomcat. I've changed various WSDL files, so
will this prevent the application running on Tomcat?

Thanks,

Mark

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: 02 April 2008 21:07
To: [EMAIL PROTECTED]
Subject: svn commit: r644032 - in
/incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp: ./
src/main/resources/ src/main/webapp/
src/test/java/org/apache/tuscany/sca/demos/aggregator/

Author: mcombellack
Date: Wed Apr  2 13:06:30 2008
New Revision: 644032

URL: http://svn.apache.org/viewvc?rev=644032view=rev
Log:
TUSCANY-2190 Changed port number from 8080 to 8085 since port 8080 is
already in use on the Continuum server so the build fails

Modified:
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/README
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/pom.xm
l
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/resources/Alerts.wsdl
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/resources/AlertsSources.wsdl
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/webapp/service.smd
 
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/te
st/java/org/apache/tuscany/sca/demos/aggregator/AlertsIntegrationTest.java

Modified:
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/README
URL:
http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-1.2/demos/a
lert-aggregator-webapp/README?rev=644032r1=644031r2=644032view=diff

==
---
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/README
(original)
+++
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/README
Wed Apr  2 13:06:30 2008
@@ -25,7 +25,7 @@
 
 Once deployed point your browser at 
 
-http://localhost:8080/demo-alert-aggregator-webapp
+http://localhost:8085/demo-alert-aggregator-webapp
 
 Taking care to ensure the host name and port number match you local 
 configuration. 
@@ -66,7 +66,7 @@
 favourite feed reader to read the aggregated alerts. To do this point your
 feed reader at
 
-http://localhost:8080/demo-alert-aggregator-webapp/services/AlertsFeedServi
ceRSS
+http://localhost:8085/demo-alert-aggregator-webapp/services/AlertsFeedServi
ceRSS
 
 Again taking care to ensure that the host name and port number match you 
 local configuration.

Modified:
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/pom.xm
l
URL:
http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-1.2/demos/a
lert-aggregator-webapp/pom.xml?rev=644032r1=644031r2=644032view=diff

==
---
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/pom.xm
l (original)
+++
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/pom.xm
l Wed Apr  2 13:06:30 2008
@@ -308,14 +308,14 @@
 waitfalse/wait
 configuration
 properties
-cargo.servlet.port8080/cargo.servlet.port
+cargo.servlet.port8085/cargo.servlet.port
 /properties
 deployables
 deployable
 location
 
${project.build.directory}/${project.build.finalName}.${project.packaging}
 /location
-
pingURLhttp://localhost:8080/AlertsSourcesServiceJSONRPC/pingURL
+
pingURLhttp://localhost:8085/AlertsSourcesServiceJSONRPC/pingURL
 /deployable
 /deployables
 home${project.build.directory}/cargo-jetty/home

Modified:
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/resources/Alerts.wsdl
URL:
http://svn.apache.org/viewvc/incubator/tuscany/branches/sca-java-1.2/demos/a
lert-aggregator-webapp/src/main/resources/Alerts.wsdl?rev=644032r1=644031r
2=644032view=diff

==
---
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/resources/Alerts.wsdl (original)
+++
incubator/tuscany/branches/sca-java-1.2/demos/alert-aggregator-webapp/src/ma
in/resources/Alerts.wsdl Wed Apr  2 13:06:30 2008
@@ -81,7 +81,7 @@
 
 wsdl:service name=AlertsService
 wsdl:port name=AlertsPort binding=tns:AlertsBinding
-wsdlsoap:address

[jira] Created: (TUSCANY-2180) Cannot invoke method on Service that implements multiple @Remotable interfaces with methods of the same name

[Mark Combellack (JIRA)]

Cannot invoke method on Service that implements multiple @Remotable interfaces 
with methods of the same name


 Key: TUSCANY-2180
 URL: https://issues.apache.org/jira/browse/TUSCANY-2180
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
 Environment: SVN Revision 643322
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


When a Component implementation class implements multiple @Remotable interfaces 
which have methods with the same name, it is not possible to invoke the 
duplicate method name on the second Remotable interrface.

Consider the following example:

I have two @Remotable services as defined by the following Java interfaces:

@Remotable
public interface LocalTimeService {
Date getCurrentTime();
}

@Remotable
public interface WorldTimeService {
Date getCurrentTime(String timeZone);
}


I have a single Java Component that implements both of these @Remotable 
Interfaces:

@Service(interfaces = {LocalTimeService.class, WorldTimeService.class})
public void class TimeServiceImpl implements LocalTimeService, WorldTimeService 
{
public Date getCurrentTime() {
// Code not shown
}

public Date getCurrentTime(String timeZone) {
// Code not shown
}
}


If I invoke getCurrentTime(), the code will work

If I invoke getCurrentTime(GMT), the code will fail. The stack trace is:

java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at 
org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at 
org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:266)
at 
org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:101)
at $Proxy20.getCurrentTime(Unknown Source)
at detail removed.test(BServiceImpl.java:41)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2180) Cannot invoke method on Service that implements multiple @Remotable interfaces with methods of the same name

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584106#action_12584106
 ] 

Mark Combellack commented on TUSCANY-2180:
--

I've raised this scenario with the OASIS SCA Assembly TC to see if it is valid 
to do this. The replies basically said that yes, it is valid.

See http://lists.oasis-open.org/archives/sca-assembly/200803/msg00100.html

 Cannot invoke method on Service that implements multiple @Remotable 
 interfaces with methods of the same name
 

 Key: TUSCANY-2180
 URL: https://issues.apache.org/jira/browse/TUSCANY-2180
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-1.1
 Environment: SVN Revision 643322
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


 When a Component implementation class implements multiple @Remotable 
 interfaces which have methods with the same name, it is not possible to 
 invoke the duplicate method name on the second Remotable interrface.
 Consider the following example:
 I have two @Remotable services as defined by the following Java interfaces:
 @Remotable
 public interface LocalTimeService {
 Date getCurrentTime();
 }
 @Remotable
 public interface WorldTimeService {
 Date getCurrentTime(String timeZone);
 }
 I have a single Java Component that implements both of these @Remotable 
 Interfaces:
 @Service(interfaces = {LocalTimeService.class, WorldTimeService.class})
 public void class TimeServiceImpl implements LocalTimeService, 
 WorldTimeService {
 public Date getCurrentTime() {
 // Code not shown
 }
 public Date getCurrentTime(String timeZone) {
 // Code not shown
 }
 }
 If I invoke getCurrentTime(), the code will work
 If I invoke getCurrentTime(GMT), the code will fail. The stack trace is:
 java.lang.IllegalArgumentException: argument type mismatch
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at 
 org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
   at 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
   at 
 org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
   at 
 org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(PassByValueInterceptor.java:108)
   at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:266)
   at 
 org.apache.tuscany.sca.core.invocation.JDKCallbackInvocationHandler.invoke(JDKCallbackInvocationHandler.java:101)
   at $Proxy20.getCurrentTime(Unknown Source)
   at detail removed.test(BServiceImpl.java:41)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-2169) Saxon download does not work when you are not using the default Maven local repository directory

[Mark Combellack (JIRA)]

Saxon download does not work when you are not using the default Maven local 
repository directory


 Key: TUSCANY-2169
 URL: https://issues.apache.org/jira/browse/TUSCANY-2169
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
 Environment: SVN trunk revision 642924
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


By default, Maven uses the directory home/.m2/repository (where home is 
your home directory) for it's local repository.

Maven also supports using a user specified local repository directory using the 
-Dmaven.repo.local=/some/other/directory on the Maven command line.

The Saxon module will download the required release of Saxon and copy it into 
the Maven local repository. However, this does not work if you are using a 
custom local Maven repository directory.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2169) Saxon download does not work when you are not using the default Maven local repository directory

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12583607#action_12583607
 ] 

Mark Combellack commented on TUSCANY-2169:
--

There are a few problems:

  * Maven local repository directory is hard coded so does not work with custom 
Maven local repository directories
  * The custom Maven local repository directory was not being passed into the 
Maven commands for installing the artefacts.

 Saxon download does not work when you are not using the default Maven local 
 repository directory
 

 Key: TUSCANY-2169
 URL: https://issues.apache.org/jira/browse/TUSCANY-2169
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
 Environment: SVN trunk revision 642924
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 By default, Maven uses the directory home/.m2/repository (where home is 
 your home directory) for it's local repository.
 Maven also supports using a user specified local repository directory using 
 the -Dmaven.repo.local=/some/other/directory on the Maven command line.
 The Saxon module will download the required release of Saxon and copy it into 
 the Maven local repository. However, this does not work if you are using a 
 custom local Maven repository directory.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2169) Saxon download does not work when you are not using the default Maven local repository directory

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2169.
--

Resolution: Fixed

Fixed in SVN revision 642939

 Saxon download does not work when you are not using the default Maven local 
 repository directory
 

 Key: TUSCANY-2169
 URL: https://issues.apache.org/jira/browse/TUSCANY-2169
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
 Environment: SVN trunk revision 642924
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 By default, Maven uses the directory home/.m2/repository (where home is 
 your home directory) for it's local repository.
 Maven also supports using a user specified local repository directory using 
 the -Dmaven.repo.local=/some/other/directory on the Maven command line.
 The Saxon module will download the required release of Saxon and copy it into 
 the Maven local repository. However, this does not work if you are using a 
 custom local Maven repository directory.

-- 
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]

What happened to the Continuum VMBuild server messages?

[Mark Combellack]

Hi,

It's been a while since I have seen a Continuum VMBuild message on the
Developer mailing list. Looking at the VMBuild server, builds have been run
recently.

I was wondering if the build emails have been disabled or are being
redirected to another list.

Thanks,

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How do I get permissions to edit the Tuscany Confluence web pages?

[Mark Combellack]

Hi,

 

I'm wanting to make a minor change to the Tuscany Confluence web pages but
my user account does not appear to have permissions to do so (basically the
copyright date is 2006 and should be 2006-2008)

 

I was wondering what I need to do or who to contact to grant edit permission
to my account.

 

My username is mcombell

 

Thanks,

 

Mark

 

 

 

 

 

Adding SVN version to Java files

[Mark Combellack]

Hi,

I've been looking through the Tuscany source code and noticed that some
files have a @version containing the SVN revision number in their JavaDoc
headers but others do not.

As an example, @version might look like:

/**
 * Some JavaDoc for the class
 * 
 * @version $Rev: 598005 $ $Date: 2007-11-25 16:36:27 + (Sun, 25 Nov
2007) $
 */

I would like to go through the Tuscany source code and add this header where
it is missing. This would involve a large number of minor changes to the
Tuscany tree so I wanted to run it by everyone to make sure no-one had a
problem with me doing this at this time.

I'll probably start this next week unless there is an objection.

Thanks,

Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [VOTE] Change Tuscany Charter to remove SDO reference

[Mark Combellack]

Hi,

A really picky point but there is a spelling mistake in the text. The text
has two 't's on the word project:

   establish a Projectt Management Committee charged


Mark

-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] 
Sent: 29 February 2008 20:06
To: tuscany-dev@ws.apache.org
Subject: Re: [VOTE] Change Tuscany Charter to remove SDO reference

kelvin goodson wrote:
 Please vote to alter the wording of the existing draft Tuscany charter as
 discussed in
 

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200802.mbox/%3c9deac
[EMAIL PROTECTED]
 
 to the following 
 
 WHEREAS, the Board of Directors deems it to be in the best
  interests of the Foundation and consistent with the Foundation's
  purpose to establish a Projectt Management Committee charged with the
 creation
  and maintenance of open-source software for distribution at no charge
  to the public, that simplifies the development, deployment and management
  of distributed applications built as compositions of service components.
  These components may be implemented with a range of technologies and
  connected using a variety of communication protocols. This software will
  implement relevant open standards including, but not limited to, the
  SCA standard defined by the OASIS OpenCSA member section, and related
  technologies.
 
 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
  Committee (PMC), to be known as the Apache Tuscany Project,
  be and hereby is established pursuant to Bylaws of the
  Foundation; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby is
  responsible for the creation and maintenance of software
  related to Apache Tuscany;
  and be it further
 
 RESOLVED, that the office of Vice President, Apache Tuscany be
  and hereby is created, the person holding such office to
  serve at the direction of the Board of Directors as the chair
  of the Apache Tuscany Project, and to have primary responsibility
  for management of the projects within the scope of
  responsibility of the Apache Tuscany Project; and be it further
 
 RESOLVED, that the persons listed immediately below be and
  hereby are appointed to serve as the initial members of the
  Apache Tuscany Project:
 
  Adriano Crestaniadrianocrestani at apache dot org
  Andrew Borley   ajborley at apache dot org
  ant elder   antelder at apache dot org
  Brady Johnson  bjohnson at apache dot org
  Frank Budinsky frankb at apache dot org
  Ignacio Silva-Lepe  isilval at apache dot org
  Jean-Sebastien Delfino   jsdelfino at apache dot org
  kelvin goodson   kelvingoodson at apache dot org
  Luciano Resende   lresende at apache dot org
  Mike Edwards   edwardsmj at apache dot org
  Pete Robbinsrobbinspg at apache dot org
  Raymond Feng  rfeng at apache dot org
  Simon Laws  slaws at apache dot org
  Simon Nash  nash at apache dot org
  Venkata Krishnan  svkrish at apache dot org
  Mark Combellack   mcombellack at apache dot org
 
 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder
  be appointed to the office of Vice President, Apache Tuscany, to
  serve in accordance with and subject to the direction of the
  Board of Directors and the Bylaws of the Foundation until
  death, resignation, retirement, removal or disqualification,
  or until a successor is appointed; and be it further
 
 RESOLVED, that the Apache Tuscany Project be and hereby
  is tasked with the migration and rationalization of the Apache
  Incubator Tuscany podling; and be it further
 
 RESOLVED, that all responsibilities pertaining to the Apache
  Incubator Tuscany podling encumbered upon the Apache Incubator
  Project are hereafter discharged.
 

+1 from me to remove the SDO reference (and Thanks for your answers and 
clarifications in the related DISCUSS thread [1]).

However, this VOTE thread introduces other unrelated changes to the 
charter. Would you mind restarting a new VOTE thread for the SDO change 
alone? I think it'll be easier to track things if we vote on individual 
changes separately.

Thanks.

[1] http://marc.info/?t=12036982511r=1w=2
-- 
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]

RE: Anyone seeing a test failure in itest/databindings/sdogen and how can I force the Continuum server to do a build of Tuscany?

[Mark Combellack]

Hi Jean-Sebastien,

I've finally got around to creating an account on the continuum server. My
account ID is mcombellack.

Could I be added to the Tuscany group please.

Thanks,

Mark

-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] 
Sent: 08 February 2008 05:43
To: tuscany-dev@ws.apache.org
Subject: Re: Anyone seeing a test failure in itest/databindings/sdogen and
how can I force the Continuum server to do a build of Tuscany?

Mark Combellack wrote:
[snip]
 * Are other people seeing this problem with the
 itest/databindings/sdogen iTest?

SVN revision r619725 just built OK for me.

 * How can I force the Continuum server to do a build?

You need to create a continuum account [1]. Then once we add your 
account to the Tuscany group you'll be able to trigger builds.

[1] http://vmbuild.apache.org/continuum/security/register.action

-- 
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]

Anyone seeing a test failure in itest/databindings/sdogen and how can I force the Continuum server to do a build of Tuscany?

[Mark Combellack]

Hi,

 

I've just checked out the latest revision of Tuscany source code. When I run
the iTests, one of the tests in itest/databindings/sdogen hangs. The test is
trying to access the following URL:

 

http://my_machine_name:8085/services/GreeterServiceWebServiceBinding

 

Where my_machine_name is the full DNS name of my host.

 

When I access this URL in a browser, I get the following:

 

Exception

org.apache.axis2.AxisFault: The endpoint reference (EPR) for the Operation
not found is /services/GreeterServiceWebServiceBinding and the WSA Action =
null

at
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java
:86)

at org.apache.axis2.engine.Phase.invoke(Phase.java:308)

at
org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)

at
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132)

at
org.apache.axis2.transport.http.util.RESTUtil.invokeAxisEngine(RESTUtil.java
:125)

at
org.apache.axis2.transport.http.util.RESTUtil.processURLRequest(RESTUtil.jav
a:119)

at
org.apache.axis2.transport.http.AxisServlet$RestRequestProcessor.processURLR
equest(AxisServlet.java:799)

at
org.apache.axis2.transport.http.AxisServlet.doGet(AxisServlet.java:242)

at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ServiceServlet.doGet(Axis2Servi
ceServlet.java:257)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)

at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)

at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)

at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)

at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:324)

at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)

at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnectio
n.java:828)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)

at
org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)

at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)

at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)

at
org.apache.tuscany.sca.core.work.Jsr237Work.run(Jsr237Work.java:61)

at
org.apache.tuscany.sca.core.work.ThreadPoolWorkManager$DecoratingWork.run(Th
readPoolWorkManager.java:215)

at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja
va:650)

at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6
75)

at java.lang.Thread.run(Thread.java:595)

/Exception

 

 

 

I wanted to check whether this was a local build failure so I checked the
Continuum server. 

 

http://vmbuild.apache.org/continuum/buildResults.action?projectGroupId=19
http://vmbuild.apache.org/continuum/buildResults.action?projectGroupId=19p
rojectId=277 projectId=277 

 

However, it has not done a build for a few days so not on the latest code
base. I logged in with my account - mcombellack - but could not find a way
to force a build to start.

 

 

 

My questions are:

 

*   Are other people seeing this problem with the
itest/databindings/sdogen iTest?
*   How can I force the Continuum server to do a build?

 

Thanks,

 

Mark

 

 

  _  

[jira] Created: (TUSCANY-2029) Multiple levels of Nested Composite References do not work as they are using the wrong URI in the binding

[Mark Combellack (JIRA)]

Multiple levels of Nested Composite References do not work as they are using 
the wrong URI in the binding
-

 Key: TUSCANY-2029
 URL: https://issues.apache.org/jira/browse/TUSCANY-2029
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: SVN trunk revision #619319
Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next


When using a reference to a nested composite containing another nested 
composite, the binding is using the wrong URI so it does not find the target.

For example, in the case of a reference to a nested nested composite, the 
service has the URI of:

SomeComposite/SomeOtherComposite/SomeComponent/SomeService

But the reference lookup is using the URI of the component service and is 
ignoring the nesting

SomeComponent/SomeService 

This means that references to nested nested composites do not work.

Previously, I fixed nested nested composite services as part of TUSCANY-2027. 
This is the other half of the problem to get references to work.

-- 
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]

Any hints as to where to look to fix problem with nested composites?

[Mark Combellack]

Hi,

 

I've just raised a bug about nesting an implemtation.composite within
another implementation.composite - see
https://issues.apache.org/jira/browse/TUSCANY-2027

 

I'm having problems working out how to fix the issue. I think it is an
assembly problem as the target of the Reference does not have a Contract.

 

Does anyone have any suggestions of where I should be looking to try to fix
this issue?

 

Thanks for your help,

 

Mark

 

 

 

 

[jira] Commented: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565399#action_12565399
 ] 

Mark Combellack commented on TUSCANY-2027:
--

I've managed to find the problem. It appears to be in CompositeWireBuilder in 
the assembly project.

The code for recursing down through composites for resolving references has 
been commented out with a comment that this is no longer required. This is 
partially true. If the nesting of composites extends only to one level then it 
is not needed. However, if you nest to many levels, it is necessary to recurse 
down the composites.

Basically, I am going to uncomment the following code in the 
wireCompositeReferences() method of CompositeWireBuilder:

// Process nested composites recursively
for (Component component : composite.getComponents()) {
Implementation implementation = component.getImplementation();
if (implementation instanceof Composite) {
wireCompositeReferences((Composite)implementation);
}
}


I'm doing a local build at the moment to ensure that I have not broken anything 
else.

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225

[jira] Assigned: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack reassigned TUSCANY-2027:


Assignee: Mark Combellack

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
 at $Proxy6.xOp(Unknown Source)
 at samples.CImpl.cOp(CImpl.java:33)
 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

[jira] Created: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

Problem using implementation.composite that is another implementation.composite 
with promoted references


 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next
 Attachments: recursive2.jar

I am having problems with a sample application that attempts to use nested 
implementation.composites and references

I have an application that has:

A lowest level composite (Called CComposite) that has two promoted references:

service name=CService promote=CComponent
interface.java interface=samples.C/
binding.sca/
/service

reference name=PromotedRefX promote=CComponent/refX
interface.java interface=samples.X/
binding.sca/
/reference

reference name=PromotedRefY promote=CComponent/refY
interface.java interface=samples.Y/
binding.sca/
/reference

component name=CComponent
implementation.java class=samples.CImpl/
reference name=refX/
reference name=refY/
/component




This is then used by another Composite (called BComposite):

service name=BService promote=BComponent
interface.java interface=samples.C/
binding.sca/
/service

component name=BComponent
implementation.composite name=sample:CComposite/

reference name=PromotedRefX target=XComponent/
reference name=PromotedRefY target=YComponent/
/component

component name=XComponent
implementation.java class=samples.XImpl/
/component

component name=YComponent
implementation.java class=samples.YImpl/
/component



This is then used by another composite (called AComposite):

service name=AService promote=AComponent
interface.java interface=samples.C/
/service


component name=AComponent
implementation.composite name=sample:BComposite/
/component




I have a unit test that tries to use AComponent. However, when I invoke an 
operation on the Service, I get the following exception:

---
 T E S T S
---
Running nested.NestedTestCase
Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
FAILURE!
testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
org.osoa.sca.ServiceUnavailableException: Service not found for component 
CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
composite containing the service is loaded and started somewhere in the SCA 
domain and that if running in a remote node that the interface of the target 
service marked as @Remotable
at 
org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
at 
org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
at $Proxy6.xOp(Unknown Source)
at samples.CImpl.cOp(CImpl.java:33)
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:248)
at 
org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:145)
at $Proxy5.cOp(Unknown Source

[jira] Updated: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack updated TUSCANY-2027:
-

Attachment: recursive2.jar

Test case that illustrates the problem

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
 at $Proxy6.xOp(Unknown Source)
 at samples.CImpl.cOp(CImpl.java:33)
 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

RE: Any hints as to where to look to fix problem with nested composites?

[Mark Combellack]

I think I have managed to find the problem. The code for diving down through
the composites to resolve all the references had been commented out in the
wireCompositeReferences() method of CompositeWireBuilder.

I've uncommented out the code and it now correctly resolves multiple level
nested references.

With this change, it now mirrors the behaviour that is implemented for
Composite Services which also dives down through the services of each
Composite.

I'm going to do some more testing and then commit the fix.

Mark

-Original Message-
From: Mark Combellack [mailto:[EMAIL PROTECTED] 
Sent: 04 February 2008 13:24
To: tuscany-dev@ws.apache.org
Subject: Any hints as to where to look to fix problem with nested
composites?

Hi,

 

I've just raised a bug about nesting an implemtation.composite within
another implementation.composite - see
https://issues.apache.org/jira/browse/TUSCANY-2027

 

I'm having problems working out how to fix the issue. I think it is an
assembly problem as the target of the Reference does not have a Contract.

 

Does anyone have any suggestions of where I should be looking to try to fix
this issue?

 

Thanks for your help,

 

Mark

 

 

 

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565316#action_12565316
 ] 

Mark Combellack commented on TUSCANY-2027:
--

Whilst debugging the code, the problem appears to be around the 
RuntimeSCAReferenceBindingProvider. 

The createInvoker() method is called, which finds the wire and calls 
getInvoker()

The getInvoker() method attempts to get the Contract off the target by calling 
target.getContract() but the contract is null so it cannot create an Invoker 
for the opreation

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
 at $Proxy6.xOp(Unknown Source)
 at samples.CImpl.cOp(CImpl.java:33

[jira] Commented: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12565551#action_12565551
 ] 

Mark Combellack commented on TUSCANY-2027:
--

SVN commit #618442 fixes the problem with nested composite references

SVN commit #618447 adds a test to recursive iTest for nested composites with 
references.

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
 at $Proxy6.xOp(Unknown Source)
 at samples.CImpl.cOp(CImpl.java:33)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39

[jira] Resolved: (TUSCANY-2027) Problem using implementation.composite that is another implementation.composite with promoted references

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2027.
--

Resolution: Fixed

Nested Composite References now work. Marking as fixed.

 Problem using implementation.composite that is another 
 implementation.composite with promoted references
 

 Key: TUSCANY-2027
 URL: https://issues.apache.org/jira/browse/TUSCANY-2027
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
 Environment: svn revision 609904
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: recursive2.jar


 I am having problems with a sample application that attempts to use nested 
 implementation.composites and references
 I have an application that has:
 A lowest level composite (Called CComposite) that has two promoted references:
 service name=CService promote=CComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 reference name=PromotedRefX promote=CComponent/refX
 interface.java interface=samples.X/
 binding.sca/
 /reference
 reference name=PromotedRefY promote=CComponent/refY
 interface.java interface=samples.Y/
 binding.sca/
 /reference
 component name=CComponent
 implementation.java class=samples.CImpl/
 reference name=refX/
 reference name=refY/
 /component
 This is then used by another Composite (called BComposite):
 service name=BService promote=BComponent
 interface.java interface=samples.C/
 binding.sca/
 /service
 component name=BComponent
 implementation.composite name=sample:CComposite/
 reference name=PromotedRefX target=XComponent/
 reference name=PromotedRefY target=YComponent/
 /component
 component name=XComponent
   implementation.java class=samples.XImpl/
 /component
 component name=YComponent
 implementation.java class=samples.YImpl/
 /component
 This is then used by another composite (called AComposite):
 service name=AService promote=AComponent
 interface.java interface=samples.C/
 /service
 component name=AComponent
 implementation.composite name=sample:BComposite/
 /component
 I have a unit test that tries to use AComponent. However, when I invoke an 
 operation on the Service, I get the following exception:
 ---
  T E S T S
 ---
 Running nested.NestedTestCase
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Deployed names = [XComponent, AComponent, BComponent, YComponent, CComponent]
 Setting X on CImpl to [Proxy - [EMAIL PROTECTED]
 Setting Y on CImpl to [Proxy - [EMAIL PROTECTED]
 Method call returned [C:cOp() - xResult = X:xOp() yResult = Y:yOp()]
 Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.667 sec  
 FAILURE!
 testAComponent(nested.NestedTestCase)  Time elapsed: 1.434 sec   ERROR!
 org.osoa.sca.ServiceUnavailableException: Service not found for component 
 CComponent reference refX (bindingURI=null operation=xOp). Ensure that the 
 composite containing the service is loaded and started somewhere in the SCA 
 domain and that if running in a remote node that the interface of the target 
 service marked as @Remotable
 at 
 org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:225)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addBindingInterceptor(RuntimeWireImpl.java:213)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:155)
 at 
 org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:97)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:205)
 at 
 org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:139)
 at $Proxy6.xOp(Unknown Source)
 at samples.CImpl.cOp(CImpl.java:33)
 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

[jira] Created: (TUSCANY-2023) NPE if callback service has multiple interfaces one of which does not have a callback

[Mark Combellack (JIRA)]

NPE if callback service has multiple interfaces one of which does not have a 
callback
-

 Key: TUSCANY-2023
 URL: https://issues.apache.org/jira/browse/TUSCANY-2023
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: implementation-java project trunk SVN revision 616727
Linux
Reporter: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


Whilst deploying a sample application, I ran into the following NPE.

java.lang.NullPointerException
at 
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createCallback(ServiceProcessor.java:138)
at 
org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitField(ServiceProcessor.java:117)
at 
org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:92)
at 
org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:154)
at 
org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:65)
at 
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
at 
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
at 
org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
at 
org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
at 
org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
at 
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
at 
org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
at 
org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
at 
org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
at 
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:125)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
... 22 more


The problem is caused by having a Service Implementation that implements two 
interfaces. One interface has a callback and the other interface does not.

The code in the ServiceProcessor is:

1 for (Service service : type.getServices()) {
2 JavaInterface javaInterface = 
(JavaInterface)service.getInterfaceContract().getCallbackInterface();
3 if (baseType == javaInterface.getJavaClass()) {
4 callbackService = service;
5 }
6 }

Line 1: Check each Service
Line 2: Get the callback interface for the Service
Line 3: See if the Java Class for the callback interface matches what we are 
looking for

The NPE is caused by line 3 when inspecting the second interface that does not 
have a callback. The issue is that javaInterface will be null since there is no 
callback.


The fix is simple - simply add a null check

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-2023) NPE if callback service has multiple interfaces one of which does not have a callback

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12563985#action_12563985
 ] 

Mark Combellack commented on TUSCANY-2023:
--

NOTE: I am going to submit a fix for this issue. However, I cannot assign this 
to myself as I dont' have permission to do so in JIRA

 NPE if callback service has multiple interfaces one of which does not have a 
 callback
 -

 Key: TUSCANY-2023
 URL: https://issues.apache.org/jira/browse/TUSCANY-2023
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: implementation-java project trunk SVN revision 616727
 Linux
Reporter: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 Whilst deploying a sample application, I ran into the following NPE.
 java.lang.NullPointerException
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createCallback(ServiceProcessor.java:138)
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitField(ServiceProcessor.java:117)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:92)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:154)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:65)
 at 
 org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:125)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 ... 22 more
 The problem is caused by having a Service Implementation that implements two 
 interfaces. One interface has a callback and the other interface does not.
 The code in the ServiceProcessor is:
 1 for (Service service : type.getServices()) {
 2 JavaInterface javaInterface = 
 (JavaInterface)service.getInterfaceContract().getCallbackInterface();
 3 if (baseType == javaInterface.getJavaClass()) {
 4 callbackService = service;
 5 }
 6 }
 Line 1: Check each Service
 Line 2: Get the callback interface for the Service
 Line 3: See if the Java Class for the callback interface matches what we are 
 looking for
 The NPE is caused by line 3 when inspecting the second interface that does 
 not have a callback. The issue is that javaInterface will be null since there 
 is no callback.
 The fix is simple - simply add a null check

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-2023) NPE if callback service has multiple interfaces one of which does not have a callback

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-2023.
--

Resolution: Fixed

Fixed by adding a null check in svn revision 616731

 NPE if callback service has multiple interfaces one of which does not have a 
 callback
 -

 Key: TUSCANY-2023
 URL: https://issues.apache.org/jira/browse/TUSCANY-2023
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: implementation-java project trunk SVN revision 616727
 Linux
Reporter: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 Whilst deploying a sample application, I ran into the following NPE.
 java.lang.NullPointerException
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createCallback(ServiceProcessor.java:138)
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitField(ServiceProcessor.java:117)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:92)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:154)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:65)
 at 
 org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:125)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 ... 22 more
 The problem is caused by having a Service Implementation that implements two 
 interfaces. One interface has a callback and the other interface does not.
 The code in the ServiceProcessor is:
 1 for (Service service : type.getServices()) {
 2 JavaInterface javaInterface = 
 (JavaInterface)service.getInterfaceContract().getCallbackInterface();
 3 if (baseType == javaInterface.getJavaClass()) {
 4 callbackService = service;
 5 }
 6 }
 Line 1: Check each Service
 Line 2: Get the callback interface for the Service
 Line 3: See if the Java Class for the callback interface matches what we are 
 looking for
 The NPE is caused by line 3 when inspecting the second interface that does 
 not have a callback. The issue is that javaInterface will be null since there 
 is no callback.
 The fix is simple - simply add a null check

-- 
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] Assigned: (TUSCANY-2023) NPE if callback service has multiple interfaces one of which does not have a callback

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-2023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack reassigned TUSCANY-2023:


Assignee: Mark Combellack

 NPE if callback service has multiple interfaces one of which does not have a 
 callback
 -

 Key: TUSCANY-2023
 URL: https://issues.apache.org/jira/browse/TUSCANY-2023
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Java Implementation Extension
 Environment: implementation-java project trunk SVN revision 616727
 Linux
Reporter: Mark Combellack
Assignee: Mark Combellack
Priority: Minor
 Fix For: Java-SCA-Next


 Whilst deploying a sample application, I ran into the following NPE.
 java.lang.NullPointerException
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.createCallback(ServiceProcessor.java:138)
 at 
 org.apache.tuscany.sca.implementation.java.introspect.impl.ServiceProcessor.visitField(ServiceProcessor.java:117)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaClassIntrospectorImpl.introspectClass(JavaClassIntrospectorImpl.java:92)
 at 
 org.apache.tuscany.sca.implementation.java.impl.JavaImplementationFactoryImpl.createJavaImplementation(JavaImplementationFactoryImpl.java:53)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:154)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:65)
 at 
 org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:242)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:241)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:794)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:74)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:108)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:113)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:47)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:423)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:333)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:155)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:125)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 ... 22 more
 The problem is caused by having a Service Implementation that implements two 
 interfaces. One interface has a callback and the other interface does not.
 The code in the ServiceProcessor is:
 1 for (Service service : type.getServices()) {
 2 JavaInterface javaInterface = 
 (JavaInterface)service.getInterfaceContract().getCallbackInterface();
 3 if (baseType == javaInterface.getJavaClass()) {
 4 callbackService = service;
 5 }
 6 }
 Line 1: Check each Service
 Line 2: Get the callback interface for the Service
 Line 3: See if the Java Class for the callback interface matches what we are 
 looking for
 The NPE is caused by line 3 when inspecting the second interface that does 
 not have a callback. The issue is that javaInterface will be null since there 
 is no callback.
 The fix is simple - simply add a null check

-- 
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: [NOTICE] Rajini Sivaram voted as Tuscany committer

[Mark Combellack]

ant elder [EMAIL PROTECTED] writes:

 
 The Tuscany PPMC and Incubator PMC have voted for Rajini Sivaram to become a
 Tuscany committer.
 
 Congratulations and welcome Rajini!
 
...ant
 

Congratulations Rajini and welcome on board.

Mark



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (TUSCANY-1487) Unable to use different application and runtime class loaders for a contribution

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack resolved TUSCANY-1487.
--

Resolution: Invalid

I'm going to mark this issue as invalid as it is now very old. There have been 
several recent class loader changes introduced into Tuscany. See TUSCANY-1871 
TUSCANY-1877 TUSCANY-1887. If this becomes a problem again, I will create a new 
Jira.

 Unable to use different application and runtime class loaders for a 
 contribution
 

 Key: TUSCANY-1487
 URL: https://issues.apache.org/jira/browse/TUSCANY-1487
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


 I have the scenario where I am attempting to deploy an application where:
 Runtime Class Loader - Contains all Tuscany classes
 Application Class Loader - Contains SCA application classes and has 
 Runtime Class Loader as parent
 I am currently getting the following exception:
 Note: I've cut company releated information from the stack trace.
 Caused by: org.osoa.sca.ServiceRuntimeException: 
 org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.contribution.service.ContributionResolveException: 
 java.lang.ClassNotFoundException: 
 net.**.sca.sample.appname.impl.**Impl
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
 at **
 ... 18 more
 Caused by: org.osoa.sca.ServiceRuntimeException: 
 org.apache.tuscany.sca.contribution.service.ContributionResolveException: 
 java.lang.ClassNotFoundException: 
 net.**.sca.sample.appname.impl.**Impl
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:115)
 at 
 org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
 ... 20 more
 Caused by: 
 org.apache.tuscany.sca.contribution.service.ContributionResolveException: 
 java.lang.ClassNotFoundException: 
 net.**.sca.sample.appname.impl.**Impl
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:113)
 at 
 org.apache.tuscany.sca.implementation.java.xml.JavaImplementationProcessor.resolve(JavaImplementationProcessor.java:49)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
 at 
 org.apache.tuscany.sca.assembly.xml.BaseArtifactProcessor.resolveImplementation(BaseArtifactProcessor.java:387)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:565)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:66)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:102)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:86)
 at 
 org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:43)
 at 
 org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:73)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:412)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:339)
 at 
 org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:154)
 at 
 org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113)
 ... 21 more
 Caused by: java.lang.ClassNotFoundException: 
 net.**.sca.sample.appname.impl.**Impl
 ... 35 more

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1909) Conversational Component referring to another Conversational Component always uses the same instance

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542206
 ] 

Mark Combellack commented on TUSCANY-1909:
--

I've created a simple addition to the conversations iTest that demonstrates 
this problem. I've attached it as a patch.

As the test does not pass, I would not recommend committing it to the iTest at 
the moment


The output from this test is shown below:


Running org.apache.tuscany.sca.itest.conversational.ConversationalTestCase
= First instance tests =
--- AServiceImpl constructor for [EMAIL PROTECTED]
Conversation ID for [EMAIL PROTECTED] is set to 
bb81d21d-c8ac-4f42-88d7-f275f145de31
--- Setting reference to B on [EMAIL PROTECTED] to [Proxy - [EMAIL PROTECTED]
--- BServiceImpl constructor for [EMAIL PROTECTED]
Conversation ID for [EMAIL PROTECTED] is set to 
b3312ec3-8044-4deb-a533-feaba0ec566d
= Second instance tests =
--- AServiceImpl constructor for [EMAIL PROTECTED]
Conversation ID for [EMAIL PROTECTED] is set to 
e2548ae6-34db-4a6e-86a1-92aa0b7e164a
--- Setting reference to B on [EMAIL PROTECTED] to [Proxy - [EMAIL PROTECTED]
Tests run: 67, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.932 sec  
FAILURE!
testMultipleConversations(org.apache.tuscany.sca.itest.conversational.ConversationalTestCase)
  Time elapsed: 0.053 sec   FAILURE!
junit.framework.ComparisonFailure: null expected:[Initial Value of] B but 
was:[First Instance - TestCode Set state on] B
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
org.apache.tuscany.sca.itest.conversational.ConversationalTestCase.testMultipleConversations(ConversationalTestCase.java:638)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
at 
org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at 
org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at 
org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:75)
at 
org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:36)
at 
org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at 
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at 
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:299)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:837)


Notice that in the first instance tests, we create an instance of AServiceImpl 
and BServiceImpl. However, in the second Instance tests, we only create an 
instance of AServiceImpl

The key lines of code of the test are:

// first instance test
// Get reference to AService and set a value on Service B
AService aService = domain.getService(AService.class, 
ConversationalAComponent);
aService.setStateOnB(NEW_B_VALUE);


// Second instance test
// Get another reference to AService
AService aService2 = domain.getService(AService.class, 
ConversationalAComponent);

// FAILS IN THE NEXT ASSERT
// This is the point it fails, the state on B is not the expected 
initial state
// but the state from the first instance test
Assert.assertEquals(Constants.B_INITIAL_VALUE, aService2.getStateOnB());


The assert fails since aService2 is sharing the same instance of BService

[jira] Commented: (TUSCANY-1909) Conversational Component referring to another Conversational Component always uses the same instance

[Mark Combellack (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542207
 ] 

Mark Combellack commented on TUSCANY-1909:
--

After some investigation, it appears that the problem is caused by the 
conversationPreinvoke() method in the JDKInvocationHandler. As part of the 
pre-invoke handling for conversational components, it checks if a conversation 
has been started. If it has not, it starts one and then updates the 
callableReference in the JDKInvocationHandler

ConversationManager conversationManager = 
((RuntimeWireImpl)wire).getConversationManager();
if (conversation == null || conversation.getState() == 
ConversationState.ENDED) {
conversation = 
conversationManager.startConversation(conversationID);
if (callableReference != null) {

((CallableReferenceImpl)callableReference).attachConversation(conversation);
}
}

As far as I can see, the JDKInvocationHandler instances all share the same 
callable reference (passed in at construction time) so they all end up 
referring to the same instance of BService.

As an experiment, I commented out the following lines and my new itest runs. 
However, most of the call back itests then do not run.

// if (callableReference != null) {
// 
((CallableReferenceImpl)callableReference).attachConversation(conversation);


This change was introduced in SVN revision 575101.

http://svn.apache.org/viewvc/incubator/tuscany/java/sca/modules/core/src/main/java/org/apache/tuscany/sca/core/invocation/JDKInvocationHandler.java?r1=574648r2=575101sortby=datediff_format=h




Looking in the JDKInvocationHandler, there is existing code for cloning the 
RuntimeWire in the init() method. However, we do not currently clone the 
CallableReference.



As a experement, I wanted to clone the CallableReference passed in to the 
constructor of the JDKInvocationHandler. However, the ServiceReferenceImpl and 
CallbackWireObjectFactory classes do not implement clone().

I tried a quick and dirty HACK that clones the CallableReference passed into 
the constructor of the JDKInvocationHandler using reflection, etc. Once the 
CalalbleReference has been cloned, both my new itest and the callback itests 
function.

I've attached the patch for the quick and dirty hack. Please don't apply to the 
source tree :-)


In summary, it looks like we need to:

   * clone the CallableReference when constructing the JDKInvocationHandler.
   * Make the CallableReference cloneable


 Conversational Component referring to another Conversational Component always 
 uses the same instance
 

 Key: TUSCANY-1909
 URL: https://issues.apache.org/jira/browse/TUSCANY-1909
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


 I've run into a problem with two conversational Services. Consider the 
 following scenario:
 AService
   * Has member variable called state
   * Has reference to BService
   * Has set/getState method for setting state on A
   * Has set/getStateOnB method for setting state on B
 BService
   * Has member variable called state
 Calling SCADomain.getService(AService) twice, I am expecting to get:
  AService_1 - BService_1
 and  AService_2 - BService_2
 However, I am getting:
  AService_1 - BService_1
 and  AService_2 - BService_1
 i.e a second instance of BService is not being created.
 The first time I get a new instance of AService, a new instance of BService 
 is created.
 The second time I get a new instance of AService, the original BService 
 instance is shared.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (TUSCANY-1909) Conversational Component referring to another Conversational Component always uses the same instance

[Mark Combellack (JIRA)]

Conversational Component referring to another Conversational Component always 
uses the same instance


 Key: TUSCANY-1909
 URL: https://issues.apache.org/jira/browse/TUSCANY-1909
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Reporter: Mark Combellack
 Fix For: Java-SCA-Next


I've run into a problem with two conversational Services. Consider the 
following scenario:

AService
  * Has member variable called state
  * Has reference to BService
  * Has set/getState method for setting state on A
  * Has set/getStateOnB method for setting state on B

BService
  * Has member variable called state

Calling SCADomain.getService(AService) twice, I am expecting to get:

 AService_1 - BService_1
and  AService_2 - BService_2

However, I am getting:

 AService_1 - BService_1
and  AService_2 - BService_1

i.e a second instance of BService is not being created.

The first time I get a new instance of AService, a new instance of BService is 
created.

The second time I get a new instance of AService, the original BService 
instance is shared.


-- 
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-1909) Conversational Component referring to another Conversational Component always uses the same instance

[Mark Combellack (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Combellack updated TUSCANY-1909:
-

Attachment: ConversationalWireFix_itest.patch
ConversationalWire_HACK_DO_NOT_APPLY.patch

The file ConversationalWire_HACK_DO_NOT_APPLY.patch contains a hack that 
attempts to clone the CallableReference. This is a BAD bit of code so it should 
not be applied to Tuscany but it shows that cloning the CallableReference 
solves the problem



The file ConversationalWireFix_itest.patch contains an update to the 
itest/conversation tests with an example of this problem.

 Conversational Component referring to another Conversational Component always 
 uses the same instance
 

 Key: TUSCANY-1909
 URL: https://issues.apache.org/jira/browse/TUSCANY-1909
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Reporter: Mark Combellack
 Fix For: Java-SCA-Next

 Attachments: ConversationalWire_HACK_DO_NOT_APPLY.patch, 
 ConversationalWireFix_itest.patch


 I've run into a problem with two conversational Services. Consider the 
 following scenario:
 AService
   * Has member variable called state
   * Has reference to BService
   * Has set/getState method for setting state on A
   * Has set/getStateOnB method for setting state on B
 BService
   * Has member variable called state
 Calling SCADomain.getService(AService) twice, I am expecting to get:
  AService_1 - BService_1
 and  AService_2 - BService_2
 However, I am getting:
  AService_1 - BService_1
 and  AService_2 - BService_1
 i.e a second instance of BService is not being created.
 The first time I get a new instance of AService, a new instance of BService 
 is created.
 The second time I get a new instance of AService, the original BService 
 instance is shared.

-- 
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]