Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Mike Edwards]

Matthieu Riou wrote:

On Thu, Jun 5, 2008 at 12:38 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:


Matthieu,

First - many thanks for your hard work on this.

I take no pleasure in saying this, but I am glad that the DB problem was
ODE's problem rather than Tuscany's - it looks like you are far more
experienced in handling that area of code!

Regarding that remaining error, which is generated by Tuscany.  I am
assuming that this is the same error that I examined previously when using
the TuscanyProcessConfImpl rather than the ODE ProcessConfImpl - namely that
the returned data structure from ODE is simply different - and I believe it
is in error - as the top level element is of a different type: - quoting
from my previous email, in the case of using the TuscanyProcessConfImpl:



Actually I think it's a different problem even if the symptom looks
identical (as I mentioned, I fixed the process). First, it always break in
the same way, whether the process is transient or not (which is reassuring).
Second, the message looks good to me this time:


Response:


http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";>Hello
World

The namespaces of the  and the  elements seem correct. Don't
you think?

Cheers,
Matthieu


Matthieu,

Many thanks...

the Tuscany archaeology is underway


Yours,  Mike.

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Matthieu Riou]

On Thu, Jun 5, 2008 at 12:38 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Matthieu,
>
> First - many thanks for your hard work on this.
>
> I take no pleasure in saying this, but I am glad that the DB problem was
> ODE's problem rather than Tuscany's - it looks like you are far more
> experienced in handling that area of code!
>
> Regarding that remaining error, which is generated by Tuscany.  I am
> assuming that this is the same error that I examined previously when using
> the TuscanyProcessConfImpl rather than the ODE ProcessConfImpl - namely that
> the returned data structure from ODE is simply different - and I believe it
> is in error - as the top level element is of a different type: - quoting
> from my previous email, in the case of using the TuscanyProcessConfImpl:
>

Actually I think it's a different problem even if the symptom looks
identical (as I mentioned, I fixed the process). First, it always break in
the same way, whether the process is transient or not (which is reassuring).
Second, the message looks good to me this time:

>>>Response:

http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl";>Hello
World

The namespaces of the  and the  elements seem correct. Don't
you think?

Cheers,
Matthieu



>
>
> "When we switch to using the Tuscany ProcessConfImpl - with its "transient"
> setting, when we invoke the same process, we get back a different type of
> object - an "ElementImpl" named "TestPart".  This contains an ElementNSImpl
> object named "hello" containing a TextImpl child holding "Hello World". This
> structural layout is clearly different to the previous case - and is wrong -
> it isn't what is expected."
>
> To explain futher, the direct cause of that exception you list is the fact
> that the top level element returned - the ElementImpl - does NOT have a
> namespace declared (I believe that it should be an ElementNSImpl) - and it
> is the lack of the NS that is at the root of the "null" exception that
> Tuscany returns.  I note that this is NOT the same data structure that is
> returned by ODE when the ODE ProcessConfImpl is used - that data structure
> IS headed by a DeferredElementNSImpl (the deferred aspect isn't important,
> but the "NS" aspect very much is important).
>
> I could not determine why there was this difference in the data structure
> returned.  I'll have another check using your fixed version of the code -
> but it would be useful if you could give me a clue about where in the ODE
> code this data element is being generated - it is very hard to trace.
>
>
>
> Yours,  Mike.
>
> PS - I assume that I need to take a latest build from the ODE SVN to get
> your fixes for the DB problem?
>
>
> Matthieu Riou wrote:
>
>> Okay, this took a while because it was actually far trickier than I
>> expected. Here were the two problems (the first being the serious one):
>>
>>  * When OpenJPA first connects to the DB it initializes its sequence table
>> and does it using a different connection. It's fine when it's done in
>> isolation (like at startup) but with Derby, when a transaction that
>> creates
>> stuff gets executed, it causes a lock timeout because the two connections
>> are competing to set a value. To fix this I've set a little parameters
>> (all
>> that time for a single line fix...) that forces the initialization when we
>> start the engine.
>>
>>  * The HelloWorld process assignment was actually setting a variable that
>> wasn't structured properly when checking the message schema. I updated the
>> assignment.
>>
>> So now we get the proper message in and out. I still have one last
>> problem,
>> when the message gets back to Tuscany I get:
>>
>> org.apache.tuscany.sca.databinding.TransformationException:
>> java.lang.IllegalArgumentException: local part cannot be "null" when
>> creating a QName
>>at
>>
>> org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
>>at
>>
>> org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
>>at
>>
>> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
>>at
>>
>> org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
>>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:103)
>>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 $Proxy5.hello(Unknown Source)
>>at
>>
>> helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)
>>
>> The message looks fine to me,

[jira] Resolved: (TUSCANY-2339) Java 2 Security - Provide Tuscany Maven profile to run vtest and itest with Java 2 security enabled

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-2339.
---

Resolution: Fixed

Patch applied under 663726.

> Java 2 Security - Provide Tuscany Maven profile to run vtest and itest with 
> Java 2 security enabled
> ---
>
> Key: TUSCANY-2339
> URL: https://issues.apache.org/jira/browse/TUSCANY-2339
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime
> Environment: Maven profile should be operating system independent.
>Reporter: Dan Becker
>Assignee: Raymond Feng
> Attachments: TUSCANY-2339.2.patch
>
>
> Provide Tuscany Maven profile to run vtest and itest with Java 2 security 
> enabled. This profile should specify a security profile for Tuscany, and 
> should run vtest and itests with Java 2 security enabled.
> Run the profile with
> mvn -P security.
> Suggested profile addition to Tuscany java/sca pom.xml
> 
> security
> 
> 
> itest
> vtest
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.3.1
> 
> 
> **/*TestCase.java
> 
> brief
> false
> once
> 
> -Djava.security.manager 
> -Djava.security.policy=file:///${java.home}/lib/security/tuscany.policy 
> -Dpolicy.allowSystemProperty=true -Djava.security.debug=policy
> 
> 
>  
> 
> 

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

[jira] Assigned: (TUSCANY-2339) Java 2 Security - Provide Tuscany Maven profile to run vtest and itest with Java 2 security enabled

[Raymond Feng (JIRA)]

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

Raymond Feng reassigned TUSCANY-2339:
-

Assignee: Raymond Feng

> Java 2 Security - Provide Tuscany Maven profile to run vtest and itest with 
> Java 2 security enabled
> ---
>
> Key: TUSCANY-2339
> URL: https://issues.apache.org/jira/browse/TUSCANY-2339
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core Runtime
> Environment: Maven profile should be operating system independent.
>Reporter: Dan Becker
>Assignee: Raymond Feng
> Attachments: TUSCANY-2339.2.patch
>
>
> Provide Tuscany Maven profile to run vtest and itest with Java 2 security 
> enabled. This profile should specify a security profile for Tuscany, and 
> should run vtest and itests with Java 2 security enabled.
> Run the profile with
> mvn -P security.
> Suggested profile addition to Tuscany java/sca pom.xml
> 
> security
> 
> 
> itest
> vtest
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.3.1
> 
> 
> **/*TestCase.java
> 
> brief
> false
> once
> 
> -Djava.security.manager 
> -Djava.security.policy=file:///${java.home}/lib/security/tuscany.policy 
> -Dpolicy.allowSystemProperty=true -Djava.security.debug=policy
> 
> 
>  
> 
> 

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

Re: Build failure in helloworld-bpel sample

[Mike Edwards]

Folks,

Someone has updated the code in SVN since this afternoon - so I am 
investigating.


Yours,  Mike.

Mike Edwards wrote:

Simon,

I did an SVN update and build of Tuscany earlier this afternoon and I 
did not see this failure.


The code currently checked in to the Tuscany SVN was fixed up to avoid 
the error listed by Luciano and certainly seems to work for me.


Is anyone else seeing the same problem that Simon is getting?


Yours,  Mike.

Simon Nash wrote:

I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample.  Are other people seeing this?
Any ideas?

  Simon

Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : 
{http://tuscany.apache.org}helloPartnerLink#hello

Creating invocation message:
 >> args.: 
xmlns="http://tuscany.apache.org/implementation/bpel/example/helloworld.w

sdl">Hello
 >> message..:
xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 


 >>>Invocation status:RESPONSE
 >>>Response:

xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 
World
ge>
 >>>Response:

xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 
World
ge>
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 
sec <<< FA

ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 
sec  <<< ERRO

R!
junit.framework.ComparisonFailure: expected: but was:<>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j

ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

sorImpl.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.executeTes

tSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab

stractDirectoryTestSuite.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(DelegatingMethodAcces

sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su

refireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j

ava:879)


Results :

Tests in error:
  testInvoke(helloworld.BPELHelloWorldTestCase)

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

Re: Build failure in helloworld-bpel sample

[Simon Nash]

Luciano Resende wrote:

I guess this might be related to this thread [1].

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg32278.html


Thakns.  I saw this and I agree it could be related, but the error
message is different.  I was getting the "null local part" message
from an earlier checkout, but my recent update changed the symptoms
to this new message.

  Simon


On Thu, Jun 5, 2008 at 12:30 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample.  Are other people seeing this?
Any ideas?

 Simon

Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:

args.: 

http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdl">Hello

message..:

http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello

Invocation status:RESPONSE
Response:


http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello
World

Response:


http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello
World
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
<<< FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 sec  <<<
ERRO
R!
junit.framework.ComparisonFailure: expected: but was:<>
   at junit.framework.Assert.assertEquals(Assert.java:81)
   at junit.framework.Assert.assertEquals(Assert.java:87)
   at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
   at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
   at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.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(DelegatingMethodAcces
sorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:585)
   at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
   at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)


Results :

Tests in error:
 testInvoke(helloworld.BPELHelloWorldTestCase)

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

Re: Build failure in helloworld-bpel sample

[Mike Edwards]

Simon,

I did an SVN update and build of Tuscany earlier this afternoon and I did not 
see this failure.

The code currently checked in to the Tuscany SVN was fixed up to avoid the error listed by Luciano 
and certainly seems to work for me.


Is anyone else seeing the same problem that Simon is getting?


Yours,  Mike.

Simon Nash wrote:

I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample.  Are other people seeing this?
Any ideas?

  Simon

Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:
 >> args.: 
xmlns="http://tuscany.apache.org/implementation/bpel/example/helloworld.w

sdl">Hello
 >> message..:
xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 


 >>>Invocation status:RESPONSE
 >>>Response:

xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 
World
ge>
 >>>Response:

xmlns="http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello 
World
ge>
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 
sec <<< FA

ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 sec  
<<< ERRO

R!
junit.framework.ComparisonFailure: expected: but was:<>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at 
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j

ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.

java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces

sorImpl.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.executeTes

tSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab

stractDirectoryTestSuite.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(DelegatingMethodAcces

sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su

refireBooter.java:308)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j

ava:879)


Results :

Tests in error:
  testInvoke(helloworld.BPELHelloWorldTestCase)

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

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[Simon Nash]

Simon Laws wrote:

On Wed, Jun 4, 2008 at 1:34 PM, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:


2008/6/4 ant elder <[EMAIL PROTECTED]>:

Currently the trunk has a version of 2.0-incubating-SNAPSHOT, we need to
remove "incubating" at some point and as its not clear if the next

release

would be 2.0 or something else so i wondered if we should also remove the
2.0 giving a trunk version of simply "SNAPSHOT"? Any comments on that or

the

timeframe for doing the change? I'd like to do it nowish so we have some
time to discover any problems before the next release.

  ...ant


Hi ant,
could you try a fresh build from svn?
I've some problems with and I 'd go on with my work before we're
arriving to 2.0.


Ciao,
Giorgio.
---
"Venceremos adelante, o victoria o muerte!"



I agree that it doesn't feel like the next release will be 2.0
I would prefer that we keep the trunk compatible with our 1.X level APIs for
the time being as it feels like there is still a more 1.X releases to do
If people are going to start making breaking changes in a branch (we
discussed this under the 2.0 thread but it's not happening yet) then it
would be useful to me to have the trunk poms marked with 1.X SNAPSHOT so
that I know by looking on my disc what I'm working with
When (if?) the time comes down the line to break from our 1.X APIs we could
then go to SNAPSHOT  or 2.0 SNAPSHOT


I think it's useful to have some version number.  "1.x" seems to clearly
describe what we are currently developing in trunk, so my preference
is for "1.x-SNAPSHOT".

  Simon

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Mike Edwards]

Matthieu,

First - many thanks for your hard work on this.

I take no pleasure in saying this, but I am glad that the DB problem was ODE's problem rather than 
Tuscany's - it looks like you are far more experienced in handling that area of code!


Regarding that remaining error, which is generated by Tuscany.  I am assuming that this is the same 
error that I examined previously when using the TuscanyProcessConfImpl rather than the ODE 
ProcessConfImpl - namely that the returned data structure from ODE is simply different - and I 
believe it is in error - as the top level element is of a different type: - quoting from my previous 
email, in the case of using the TuscanyProcessConfImpl:


"When we switch to using the Tuscany ProcessConfImpl - with its "transient" setting, when we invoke 
the same process, we get back a different type of object - an "ElementImpl" named "TestPart".  This 
contains an ElementNSImpl object named "hello" containing a TextImpl child holding "Hello World". 
This structural layout is clearly different to the previous case - and is wrong - it isn't what is 
expected."


To explain futher, the direct cause of that exception you list is the fact that the top level 
element returned - the ElementImpl - does NOT have a namespace declared (I believe that it should be 
an ElementNSImpl) - and it is the lack of the NS that is at the root of the "null" exception that 
Tuscany returns.  I note that this is NOT the same data structure that is returned by ODE when the 
ODE ProcessConfImpl is used - that data structure IS headed by a DeferredElementNSImpl (the deferred 
aspect isn't important, but the "NS" aspect very much is important).


I could not determine why there was this difference in the data structure returned.  I'll have 
another check using your fixed version of the code - but it would be useful if you could give me a 
clue about where in the ODE code this data element is being generated - it is very hard to trace.




Yours,  Mike.

PS - I assume that I need to take a latest build from the ODE SVN to get your 
fixes for the DB problem?


Matthieu Riou wrote:

Okay, this took a while because it was actually far trickier than I
expected. Here were the two problems (the first being the serious one):

 * When OpenJPA first connects to the DB it initializes its sequence table
and does it using a different connection. It's fine when it's done in
isolation (like at startup) but with Derby, when a transaction that creates
stuff gets executed, it causes a lock timeout because the two connections
are competing to set a value. To fix this I've set a little parameters (all
that time for a single line fix...) that forces the initialization when we
start the engine.

 * The HelloWorld process assignment was actually setting a variable that
wasn't structured properly when checking the message schema. I updated the
assignment.

So now we get the proper message in and out. I still have one last problem,
when the message gets back to Tuscany I get:

org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: local part cannot be "null" when
creating a QName
at
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
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:103)
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 $Proxy5.hello(Unknown Source)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)

The message looks fine to me, any idea what this could be? I've committed my
fixes so you should be able to reproduce it.

Cheers,
Matthieu

On Fri, May 30, 2008 at 11:39 PM, Matthieu Riou <[EMAIL PROTECTED]>
wrote:


I've started looking at the DbError issue and reproduced it. Digging deeper
it seems it's caused by a lock timeout in Derby on the
OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
deployed process. Here is an excerpt from the logs:

DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1(guid=hqejbhcnphr3beiwcxrx88)
DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
DE

Re: Build failure in helloworld-bpel sample

[Luciano Resende]

I guess this might be related to this thread [1].

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg32278.html

On Thu, Jun 5, 2008 at 12:30 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> I did a recent svn update and rebuild and I'm seeing the following test
> error from the helloworld-bpel sample.  Are other people seeing this?
> Any ideas?
>
>  Simon
>
> Running helloworld.BPELHelloWorldTestCase
> Completed calling new Process deployment code...
> Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
> Creating invocation message:
>>> args.: 
>  xmlns="http://tuscany.apache.org/implementation/bpel/example/helloworld.w
> sdl">Hello
>>> message..:
>  xmlns="http://tuscany.apache.org/implementation/bpel/e
> xample/helloworld.wsdl">Hello
Invocation status:RESPONSE
Response:
> 
>  xmlns="http://tuscany.apache.org/implementation/bpel/e
> xample/helloworld.wsdl">Hello
> World ge>
Response:
> 
>  xmlns="http://tuscany.apache.org/implementation/bpel/e
> xample/helloworld.wsdl">Hello
> World ge>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec
> <<< FA
> ILURE!
> testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 sec  <<<
> ERRO
> R!
> junit.framework.ComparisonFailure: expected: but was:<>
>at junit.framework.Assert.assertEquals(Assert.java:81)
>at junit.framework.Assert.assertEquals(Assert.java:87)
>at
> helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
> ava:57)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.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.executeTes
> tSet(AbstractDirectoryTestSuite.java:138)
>at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
> stractDirectoryTestSuite.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(DelegatingMethodAcces
> sorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:585)
>at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
> refireBooter.java:308)
>at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
> ava:879)
>
>
> Results :
>
> Tests in error:
>  testInvoke(helloworld.BPELHelloWorldTestCase)
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0
>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Build failure in helloworld-bpel sample

[Simon Nash]

I did a recent svn update and rebuild and I'm seeing the following test
error from the helloworld-bpel sample.  Are other people seeing this?
Any ideas?

  Simon

Running helloworld.BPELHelloWorldTestCase
Completed calling new Process deployment code...
Invoking bpel component : {http://tuscany.apache.org}helloPartnerLink#hello
Creating invocation message:
>> args.: 
http://tuscany.apache.org/implementation/bpel/example/helloworld.w
sdl">Hello
>> message..:
http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello
>>>Invocation status:RESPONSE
>>>Response:

http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello World
>>>Response:

http://tuscany.apache.org/implementation/bpel/e
xample/helloworld.wsdl">Hello World
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.512 sec <<< FA
ILURE!
testInvoke(helloworld.BPELHelloWorldTestCase)  Time elapsed: 9.494 sec  <<< ERRO
R!
junit.framework.ComparisonFailure: expected: but was:<>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.j
ava:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.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.executeTes
tSet(AbstractDirectoryTestSuite.java:138)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Ab
stractDirectoryTestSuite.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(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Su
refireBooter.java:308)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.j
ava:879)


Results :

Tests in error:
  testInvoke(helloworld.BPELHelloWorldTestCase)

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

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Simon Nash]

ant elder wrote:

The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany
committer.

Congratulations and welcome!

   ...ant


Vamsi,
Congratulations on this recognition of your excellent contributions.
Welcome on board!

  Simon

[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2347:
-

Attachment: TUSCANY-2347-Part2.patch

> Removing the exception throws from the processors
> -
>
> Key: TUSCANY-2347
> URL: https://issues.apache.org/jira/browse/TUSCANY-2347
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Windows XP,
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, 
> TUSCANY-2347-Part3.patch
>
>
> After introducing the monitors in various part of the code (especially in the 
> processors), while the runtime reads and resolves the contribution. Now we 
> are trying to remove the exception that are being thrown from these modules. 
> As a first step we are removing the exceptions that are safe to remove, by 
> leaving the critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
> As a second step, we will also be dealing with the above said exception once 
> we have a detailed discussion as how to handle them.

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

[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2347:
-

Attachment: TUSCANY-2347-Part3.patch

> Removing the exception throws from the processors
> -
>
> Key: TUSCANY-2347
> URL: https://issues.apache.org/jira/browse/TUSCANY-2347
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Windows XP,
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2347-Part1.patch, TUSCANY-2347-Part2.patch, 
> TUSCANY-2347-Part3.patch
>
>
> After introducing the monitors in various part of the code (especially in the 
> processors), while the runtime reads and resolves the contribution. Now we 
> are trying to remove the exception that are being thrown from these modules. 
> As a first step we are removing the exceptions that are safe to remove, by 
> leaving the critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
> As a second step, we will also be dealing with the above said exception once 
> we have a detailed discussion as how to handle them.

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

Re: [Fwd: Re: SCA BPEL - Problems with ODE - Help requested]

[Matthieu Riou]

Okay, this took a while because it was actually far trickier than I
expected. Here were the two problems (the first being the serious one):

 * When OpenJPA first connects to the DB it initializes its sequence table
and does it using a different connection. It's fine when it's done in
isolation (like at startup) but with Derby, when a transaction that creates
stuff gets executed, it causes a lock timeout because the two connections
are competing to set a value. To fix this I've set a little parameters (all
that time for a single line fix...) that forces the initialization when we
start the engine.

 * The HelloWorld process assignment was actually setting a variable that
wasn't structured properly when checking the message schema. I updated the
assignment.

So now we get the proper message in and out. I still have one last problem,
when the message gets back to Tuscany I get:

org.apache.tuscany.sca.databinding.TransformationException:
java.lang.IllegalArgumentException: local part cannot be "null" when
creating a QName
at
org.apache.tuscany.sca.core.databinding.transformers.Output2OutputTransformer.transform(Output2OutputTransformer.java:215)
at
org.apache.tuscany.sca.databinding.impl.MediatorImpl.mediate(MediatorImpl.java:79)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.transform(DataTransformationInterceptor.java:186)
at
org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:169)
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:103)
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 $Proxy5.hello(Unknown Source)
at
helloworld.BPELHelloWorldTestCase.testInvoke(BPELHelloWorldTestCase.java:56)

The message looks fine to me, any idea what this could be? I've committed my
fixes so you should be able to reproduce it.

Cheers,
Matthieu

On Fri, May 30, 2008 at 11:39 PM, Matthieu Riou <[EMAIL PROTECTED]>
wrote:

> I've started looking at the DbError issue and reproduced it. Digging deeper
> it seems it's caused by a lock timeout in Derby on the
> OPENJPA_SEQUENCE_TABLE when ODE tries to create a record for the new
> deployed process. Here is an excerpt from the logs:
>
> DEBUG - GeronimoLog.debug(66) | Creating process DAO for {
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1(guid=hqejbhcnphr3beiwcxrx88)
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT t0.ID, t0.GUID,
> t0.PROCESS_ID, t0.PROCESS_TYPE, t0.VERSION FROM ODE_PROCESS t0 WHERE
> (t0.PROCESS_ID = ?)
> DEBUG - GeronimoLog.debug(66) | bound (1,{
> http://tuscany.apache.org/implementation/bpel/example/helloworld}HelloWorld-1
> )
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: INSERT INTO
> OPENJPA_SEQUENCE_TABLE (ID, SEQUENCE_VALUE) VALUES (?, ?)
> DEBUG - GeronimoLog.debug(66) | bound (2,1) (1,0)
> DEBUG - GeronimoLog.debug(66) | close
> DEBUG - GeronimoLog.debug(66) | getConnection (tx=2)
> DEBUG - GeronimoLog.debug(66) | prepareStmt: SELECT SEQUENCE_VALUE FROM
> OPENJPA_SEQUENCE_TABLE WHERE ID = ? FOR UPDATE WITH RR
> DEBUG - GeronimoLog.debug(66) | bound (1,0)
> WARN - GeronimoLog.warn(96) | connectionErrorOccurred called with null
> java.sql.SQLException: A lock could not be obtained within the time
> requested
>
> Right now I really have no clue why this is happening, there's no reason
> why a lock would get stuck on the OpenJPA sequence table. I have to dig
> deeper but it's getting late, I'll try to find more time during the week-end
> or Monday.
>
> Cheers,
> Matthieu
>
>
> On Fri, May 30, 2008 at 1:42 PM, Mike Edwards <
> [EMAIL PROTECTED]> wrote:
>
>>
>>
>>  Original Message 
>> Subject: Re: SCA BPEL - Problems with ODE - Help requested
>> Date: Fri, 30 May 2008 17:51:12 +0100
>> From: Mike Edwards <[EMAIL PROTECTED]>
>> To: tuscany-dev@ws.apache.org
>> References: <[EMAIL PROTECTED]> <
>> [EMAIL PROTECTED]>
>>
>> Matthieu Riou wrote:
>>
>>> On Thu, May 29, 2008 at 11:41 AM, Mike Edwards <
>>> [EMAIL PROTECTED]> wrote:
>>>
>>>  Folks,

 I'v

[jira] Updated: (TUSCANY-2347) Removing the exception throws from the processors

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2347:
-

Attachment: TUSCANY-2347-Part1.patch

> Removing the exception throws from the processors
> -
>
> Key: TUSCANY-2347
> URL: https://issues.apache.org/jira/browse/TUSCANY-2347
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: Windows XP,
>Reporter: Ramkumar Ramalingam
>Assignee: Ramkumar Ramalingam
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2347-Part1.patch
>
>
> After introducing the monitors in various part of the code (especially in the 
> processors), while the runtime reads and resolves the contribution. Now we 
> are trying to remove the exception that are being thrown from these modules. 
> As a first step we are removing the exceptions that are safe to remove, by 
> leaving the critical exceptions like
> a) IOException
> b) XMLStreamException
> c) PriviledegedActionException
> d) and ParseConfigurationExceptions
> As a second step, we will also be dealing with the above said exception once 
> we have a detailed discussion as how to handle them.

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

Re: sca/tools/eclipse/plugins/core/.classpath file in svn

[Luciano Resende]

Long history [1], but I guess we never found a way to remove it and
still works as required just by pom configuration.

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26523.html

On Wed, Jun 4, 2008 at 10:02 PM, Vamsavardhana Reddy
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> There is a .classpath file in svn at [1].  I guess it made into svn by
> accident.  Can someone remove this file?  Each time I try to create a patch,
> this file shows up in the diffs and I have to manual remove it from the
> patch files :(.
>
> ++Vamsi
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tools/eclipse/plugins/core/.classpath
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: A question for DAS

[Luciano Resende]

We currently have a RDB DAS implementation, an LDAP was started but is
not quite ready yet. If you have requirements for supporting other
sources, please feel free to help us and we will help you.

2008/6/5 Adriano Crestani <[EMAIL PROTECTED]>:
> Hi,
>
> Are you talking about the Java or C++(native) DAS?
>
> Regards,
> Adriano Crestani
>
> On Thu, Jun 5, 2008 at 4:50 AM, 寿栋 <[EMAIL PROTECTED]> wrote:
>
>> Hi, sir:
>>
>>
>>
>>   Nowadays I have done some work on SDO/DAS, and have run successfully your
>> sample examples downloaded from Tuscany.
>>
>>   However, I have not found any example for the implementation of DAS that
>> is to provide a uniform way of accessing data form heterogeneous data
>> sources?
>>
>>   The examples available only access data from single RDBMS, so I wonder
>> have you already developed such implementation?
>>
>>   Many thanks~~
>>
>>
>



-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

RuntimeException: "no data binding for null" with binding.ws when the service inteface uses generics

[Vamsavardhana Reddy]

I have the following method in my service interface that uses binding.ws:
 Bean1 getTypeUnbound(T[] anArray);

I am getting the following exception in SCADomain.newInstance()

org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.RuntimeException: no data binding for null
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
at
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:70)
at
org.apache.tuscany.sca.itest.databindings.jaxb.GenericsDatabindingTestCase.setUp(GenericsDatabindingTestCase.java:43)
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.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at
org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at
org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at
org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.osoa.sca.ServiceRuntimeException:
org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.RuntimeException: no data binding for null
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:239)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:113)
at
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242)
... 16 more
Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
java.lang.RuntimeException: no data binding for null
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:986)
at
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:237)
... 18 more
Caused by: java.lang.RuntimeException: no data binding for null
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:507)
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:481)
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:366)
at
org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:142)
at
org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:198)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBindingProvider.(Axis2ReferenceBindingProvider.java:68)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:70)
at
org.apache.tuscany.sca.binding.ws.axis2.Axis2BindingProviderFactory.createReferenceBindingProvider(Axis2BindingProviderFactory.java:47)
at
org.apache.tuscany.sca.provider.DefaultProviderFactoryExtensionPoint$LazyBindingProviderFactory.createReferenceBindingProvider(DefaultProviderFactoryExtensionPoint.java:230)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.addReferenceBindingProvider(CompositeActivatorImpl.java:262)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:142)
at
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(CompositeActivatorImpl.java:982)
... 19 more

I get a similar exception when I add a method "Object getNewObject(Object
obj)" to my service interface.  IIRC, this used to work 10 days ago!

++Vamsi



++Vamsi

Re: A question for DAS

[Adriano Crestani]

Hi,

Are you talking about the Java or C++(native) DAS?

Regards,
Adriano Crestani

On Thu, Jun 5, 2008 at 4:50 AM, 寿栋 <[EMAIL PROTECTED]> wrote:

> Hi, sir:
>
>
>
>   Nowadays I have done some work on SDO/DAS, and have run successfully your
> sample examples downloaded from Tuscany.
>
>   However, I have not found any example for the implementation of DAS that
> is to provide a uniform way of accessing data form heterogeneous data
> sources?
>
>   The examples available only access data from single RDBMS, so I wonder
> have you already developed such implementation?
>
>   Many thanks~~
>
>

A question for DAS

[寿栋]

Hi, sir: 



   Nowadays I have done some work on SDO/DAS, and have run successfully your
sample examples downloaded from Tuscany. 

   However, I have not found any example for the implementation of DAS that
is to provide a uniform way of accessing data form heterogeneous data
sources? 

   The examples available only access data from single RDBMS, so I wonder
have you already developed such implementation? 

   Many thanks~~  

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Adriano Crestani]

Congratulations :D

On Thu, Jun 5, 2008 at 12:15 AM, Manu George <[EMAIL PROTECTED]>
wrote:

> Congrats Vamsi !!!
>
> On Tue, Jun 3, 2008 at 4:56 PM, Venkata Krishnan <[EMAIL PROTECTED]>
> wrote:
> > Congratulations Vamsi... Welcome !!!
> >
> > - Venkat
> >
> > On Mon, Jun 2, 2008 at 11:32 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >> The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany
> >> committer.
> >>
> >> Congratulations and welcome!
> >>
> >>   ...ant
> >>
> >
>

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602655#action_12602655
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

I have been staring at OSGiBundleActivator$BundleClassLoader.getResource hoping 
that something will strike me, but I just can't find any problem with it. I 
would have been happier if this was a rare timing related issue, but obviously 
it isn't. 

bundle.getResource() should only return null if 1) the resource is not present 
2) the bundle is not resolved or 3) the caller doesn't have permissions. I 
can't imagine any of these changing between the two calls in such a consistent 
way. It obviously looks like some code during Tuscany startup is having an 
impact, but I have no idea what it could be. 

If you have Equinox source on your machine, it will be useful to step through 
the "bundle.getResource" call in 
OSGiBundleActivator$BundleClassLoader.getResource for the bundle 
org.apache.tuscany.sca.wstx-asl-3.2.1.jar  in the failing case. 

Otherwise, maybe compare this setup with your test setup - I am still confused 
as to why this didn't fail with your test since the same Tuscany code was 
executed with both - in very similar environments perhaps?

- Rajini



> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

Re: [jira] Created: (TUSCANY-2372) Unable to build with 1.6 JDK due to JAXB conflict

[Simon Laws]

On Thu, Jun 5, 2008 at 2:13 PM, James Rutherford <[EMAIL PROTECTED]>
wrote:

> On Thu, Jun 05, 2008 at 12:43:07PM +, Mike Edwards wrote:
> > James Rutherford (JIRA) wrote:
> > > Unable to build with 1.6 JDK due to JAXB conflict
> > > -
> > >
> > >  Key: TUSCANY-2372
> > >  URL:
> https://issues.apache.org/jira/browse/TUSCANY-2372
> > >  Project: Tuscany
> > >   Issue Type: Bug
> > >   Components: Build System
> > > Affects Versions: Java-SCA-1.2
> > >  Environment: % java -version
> > > java version "1.6.0_03"
> > > Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> > > Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)
> > >
> > > % mvn -version
> > > Maven version: 2.0.8
> > > Java version: 1.6.0_03
> > > OS name: "linux" version: "2.6.24-gentoo-r3" arch: "i386" Family:
> "unix"
> > > Reporter: James Rutherford
> > >
> > >
> > > Error running 'mvn' command due to conflict with JAXB API provided by
> 1.6 JDK:
> > >
> > James,
> >
> > I think that this should be closed "no action" since the fix is to
> > move up to 1.6.0_05 of the JDK.
>
> OK, I'll upgrade my JDK and verify the fix. Where is this fix
> documented? I searched for a while, but couldn't find anything.
>
> cheers,
>
> Jim
>
> --
> James Rutherford  |  Hewlett-Packard Limited registered Office:
> Research Engineer |  Cain Road,
> HP Labs   |  Bracknell,
> Bristol, UK   |  Berks
> +44 117 312 7066  |  RG12 1HN.
> [EMAIL PROTECTED]   |  Registered No: 690597 England
>
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in
> error, you should delete it from your system immediately and advise the
> sender. To any recipient of this message within HP, unless otherwise
> stated you should consider this message and attachments as "HP
> CONFIDENTIAL".
>

Apologies Jim.

Raymond posted on this subject before [1] and suggested we put it in our
FAQ. It doesn't seem to have made it there so I'll go and update it now.

Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg30480.html

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602641#action_12602641
 ] 

Daniel Stucky commented on TUSCANY-2343:


One more comment:

During the 1st call the URL is found in bundle 
org.apache.tuscany.sca.wstx-asl-3.2.1.jar
During the 2nd call this bundle is listet in bundles, but the URL is not found!

Daniel

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

Re: GSoC Project - CORBA Support for Apache Tuscany

[Wojtek Janiszewski]

Wojtek Janiszewski wrote:

Simon Nash wrote:

One comment inline.

  Simon
6. If CORBA objects operation argument is object reference, then 
user should provide object which was previously obtained from 
binding or other CORBA object. User cannot use users-side object as 
an argument.




Yes. Let's don't worry object reference too much at this point. We 
are in the SOA world instead of distributed object :-).



This is OK if we are exposing a SCA service via CORBA.  If we are using
SCA to invoke existing CORBA services that expect object references
to be passed, we will need to come up with an approach for handling them.

I'd suggest that we start first with exposing SCA services via CORBA
as this seems to be the simplest and most useful form of integration.


Unfortunately I started earlier with reference bindings - even submitted 
a patch today.


My thoughts for object references are that after obtaining some remote 
reference, it will be enhanced by cglib and connected to users declared 
interface. By enhancing I mean interception of methods invocations and 
adding dynamic CORBA invocations. Such enhanced object could be 
recognizable by dynamic invocation mechanism, and it could be passed 
while invoking operations on remote objects.


In this solution we would have two types of CORBA objects - ones that 
were intentionally declared, and ones that were obtained from roots, and 
which are transparent. It's maybe kind of out of control by Tuscany 
runtime, but is there any other way to obtain and use CORBA references 
which are not registered in name services?


Thanks,
Wojtek



Hi,
I recently submitted some code, which helps invoking remote objects. 
Mechanism for invoking remote CORBA objects is determining operation 
arguments types by Java types and I'm not sure that Java to CORBA 
mapping model I proposed is OK.


There is quite nice description of Java to CORBA mapping under [1]. It 
shows how idlj compiler creates Java structure basing on idl file and I 
believe we shouldn't precisely follow those rules and try to make them 
as simple as possible. Am I right?


1. Structures
I proposed that CORBA structures will be Java classes, with public 
fields and no get/set methods. So every class field is member for CORBA 
structure. Or maybe we should map JavaBean classes to CORBA structures?


2. Sequences and arrays
Sequences and arrays can be mapped to Java by arrays or lists. 
Unfortunately both CORBA types behaves bit different, additionally CORBA 
arrays have fixed length so there should be possibility to distinguish 
those types somehow. For now on I cannot find any other solution, but 
annotating arrays with it's target length. Any opinions?


3. Arguments with inout/out modifiers
In CORBA, operation argument value can be changed. As we know Java 
supports passing arguments by values only, so update on argument is not 
possible. Such was solved in Java by wrapping arguments in holder 
classes, ie:


public class IntHolder {
public int value;
}

This means if user wants to get his argument updated he needs to create 
argument in holder class, which could be tough (maybe there are 
low-level techniques which allows to manipulate such arguments?).


I know I should provide some method to recognize if users class is 
holder for inout/out argument:

a. annotation
b. by implementing interface, ie:

public interface Holder {
void setValue(Object value);
Object getValue();
}

Or maybe there is some other solution? Which one should I choose?

I'll appreciate any comments. Just ask if you need more details.

[1] - http://members.tripod.com/gsraj/corba/chapter/

Thanks,
Wojtek

Re: [jira] Created: (TUSCANY-2372) Unable to build with 1.6 JDK due to JAXB conflict

[James Rutherford]

On Thu, Jun 05, 2008 at 12:43:07PM +, Mike Edwards wrote:
> James Rutherford (JIRA) wrote:
> > Unable to build with 1.6 JDK due to JAXB conflict
> > -
> >
> >  Key: TUSCANY-2372
> >  URL: https://issues.apache.org/jira/browse/TUSCANY-2372
> >  Project: Tuscany
> >   Issue Type: Bug
> >   Components: Build System
> > Affects Versions: Java-SCA-1.2
> >  Environment: % java -version
> > java version "1.6.0_03"
> > Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> > Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)
> >
> > % mvn -version
> > Maven version: 2.0.8
> > Java version: 1.6.0_03
> > OS name: "linux" version: "2.6.24-gentoo-r3" arch: "i386" Family: "unix"
> > Reporter: James Rutherford
> >
> >
> > Error running 'mvn' command due to conflict with JAXB API provided by 1.6 
> > JDK:
> >
> James,
> 
> I think that this should be closed "no action" since the fix is to
> move up to 1.6.0_05 of the JDK.

OK, I'll upgrade my JDK and verify the fix. Where is this fix
documented? I searched for a while, but couldn't find anything.

cheers,

Jim

-- 
James Rutherford  |  Hewlett-Packard Limited registered Office:
Research Engineer |  Cain Road,
HP Labs   |  Bracknell,
Bristol, UK   |  Berks
+44 117 312 7066  |  RG12 1HN.
[EMAIL PROTECTED]   |  Registered No: 690597 England

The contents of this message and any attachments to it are confidential
and may be legally privileged. If you have received this message in
error, you should delete it from your system immediately and advise the
sender. To any recipient of this message within HP, unless otherwise
stated you should consider this message and attachments as "HP
CONFIDENTIAL".

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602637#action_12602637
 ] 

Daniel Stucky commented on TUSCANY-2343:


I was not able to set a breakpoint in method findClass(...). Eclipse did just 
not allow it. It was possible in all other methods, though.

Here are the results of the breakpoint in getResource(...) and following code

1st call:
OSGiBundleActivator$BundleClassLoader  (id=84)  
bundle.size() = 230
resName=META-INF/services/javax.xml.stream.XMLInputFactory
URL=bundleresource://52/META-INF/services/javax.xml.stream.XMLInputFactory
factoryClassname=com.ctc.wstx.stax.WstxInputFactory


2nd call:
OSGiBundleActivator$BundleClassLoader  (id=84)  
bundle.size() = 230
resName=META-INF/services/javax.xml.stream.XMLInputFactory
URL=null


As you can see, the URL in the 2nd call is null.

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

Re: [jira] Created: (TUSCANY-2372) Unable to build with 1.6 JDK due to JAXB conflict

[Mike Edwards]

James Rutherford (JIRA) wrote:

Unable to build with 1.6 JDK due to JAXB conflict
-

 Key: TUSCANY-2372
 URL: https://issues.apache.org/jira/browse/TUSCANY-2372
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
Affects Versions: Java-SCA-1.2
 Environment: % java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

% mvn -version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "linux" version: "2.6.24-gentoo-r3" arch: "i386" Family: "unix"
Reporter: James Rutherford


Error running 'mvn' command due to conflict with JAXB API provided by 1.6 JDK:


James,

I think that this should be closed "no action" since the fix is to move up to 
1.6.0_05 of the JDK.



Yours,  Mike.

Re: Validation Exceptions was: Re: TUSCANY-2277 & validation messages

[Simon Laws]

Hi

More comments in line

Simon


>
> Hi Simon,
> Initially our idea was to disable most of the exception throws from the
> processors and log the warnings/exception via the monitors. Lets say we
> might still leave some exceptions to be thrown like the type1 exceptions,
> in
> such cases me might end up only throwing IOExceptions /
> XMLStreamExceptions.
>
> From stax artifact processor.
> M read(XMLStreamReader reader) throws ContributionReadException,
> XMLStreamException;
>
> Here the processor would never throw ContributionReadException, when the
> exceptions are blocked as most of the ContributionReadException are of
> type1, 2 or 3.


Do you mean type  2, 3 & 4 here. I still expect us to throw type 1
exceptions.

>
>
> Do you believe we should maintain the current API in such cases?
>
>
>
I would leave the interface as is for the time being while we work through
the various exceptions. To see if there are any we can't deal with.

Re: SCA 1.2.1 release

[ant elder]

The vote for the 1.2.1 release has now passed -
http://apache.markmail.org/message/s23xtktwohpfaacq. I'm a bit busy so will
take a little while to get the website etc updated (unless anyone wants to
help sooner?) but I've copied the artifacts to the maven repository so they
are now publicly available to use.

   ...ant

On Mon, Jun 2, 2008 at 10:47 AM, Dave Sowerby <[EMAIL PROTECTED]>
wrote:

> Hey Ant,
>
> Thanks for offering to perform this task!
>
> Have you managed to make any progress with this?
>
> Cheers,
>
> Dave.
>
> On Thu, May 29, 2008 at 10:15 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > Yes, now that it looks like everyone wants this to go ahead I'll go do
> this,
> > not sure if I'll have time to finish it today and I'm out tomorrow but
> I'll
> > try to make sure the artifacts are built and available by the end of the
> > weekend.
> >
> >   ...ant
> >
> > On Thu, May 29, 2008 at 10:07 AM, Dave Sowerby <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi All,
> >>
> >> Could anyone give me any time scales for the 1.2.1 release?
> >>
> >> The release I'm preparing is due to be released within the next week
> >> and is unfortunately blocked awaiting this update.
> >>
> >> I'm available to assist in any way necessary.
> >>
> >> Cheers,
> >>
> >> Dave.
> >>
> >> On Wed, May 28, 2008 at 7:13 AM, haleh mahbod <[EMAIL PROTECTED]>
> wrote:
> >> > I can help with validating the samples and demos for 1.2.1.
> >> >
> >> > On 5/27/08, Simon Laws <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> On Tue, May 27, 2008 at 6:26 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> > Dave Sowerby wrote:
> >> >> >
> >> >> >> Hi Simon,
> >> >> >>
> >> >> >> With regards to the 1.2.1 release you are correct that we have a
> >> >> >> patched version of tuscany-sca-all which would work, but this
> however
> >> >> >> leaves us in an awkward configuration position.
> >> >> >>
> >> >> >> We're currently preparing a software release based around Tuscany
> >> >> >> which is completely open to customers of our use of Tuscany, such
> >> that
> >> >> >> we document fully how to construct services independent of our
> >> >> >> software.  As such, we do not ship any Tuscany artifacts and
> instead
> >> >> >> encourage our customers to utilise the published maven repository.
> >> >> >> Whilst requiring a patch version of one of the jars is possible; I
> >> >> >> don't feel that this is a good representation of Tuscany - either
> >> >> >> documenting a variant version or expecting a non-standard version
> of
> >> >> >> 1.2-incubating.  These potential solutions are more likely to
> cause
> >> >> >> issues for customers that would undermine the image of Tuscany
> that
> >> we
> >> >> >> try to project.
> >> >> >>
> >> >> >> Is anyone adamantly opposed to this release?  Do you feel Tuscany
> >> >> >> 1.2.1 is still an option?  I'd hope that given the potential to
> >> damage
> >> >> >> our customer's perception of Tuscany would be enough to justify
> this
> >> >> >> minor release.
> >> >> >>
> >> >> >>  Thanks for the clarifaction and explanation.  It seems to me that
> >> >> > because we distribute Tuscany via Maven repos, which can't be
> patched,
> >> >> > this kind of situation will arise whenever a serious bug is found.
> >> >> > We can use patches to isolate a problem and confirm the fix, but we
> >> >> > generally won't be able to use them as an alternative to a release.
> >> >> >
> >> >> > In a situation like this, unless a new release is imminent, the
> best
> >> >> > solution seems to be to produce a quick "bug fix" release without
> >> >> > incurring the overhead of a full release and testing cycle.  Ant
> has
> >> >> > suggested that we could do this by applying a small set of
> carefully
> >> >> > controlled changes to the previous 1.2 release tag.  I think we
> need
> >> >> > to be very strict about what changes go in, to avoid another
> >> experience
> >> >> > like 1.0.1.  Specifically, I would suggest only including the fix
> >> >> > for TUSCANY-2304.
> >> >> >
> >> >> > What do others think of this?
> >> >> >
> >> >> >  Simon
> >> >> >
> >> >> >
> >> >> >  Cheers,
> >> >> >>
> >> >> >> Dave.
> >> >> >>
> >> >> >> On Tue, May 20, 2008 at 12:00 PM, Simon Nash <[EMAIL PROTECTED]>
> >> wrote:
> >> >> >>
> >> >> >>> Nishant Joshi wrote:
> >> >> >>>
> >> >>  Hi All,
> >> >>  I have raised TUSCANY-2304 which was actually blocking me to go
> >> >> further
> >> >>  with
> >> >>  SCA client. So It was given high priority to resolved and
> >> fortunately
> >> >>  Ant
> >> >>  has resolved it very fast, i appreciate his effortt, thanks alot
> >> Ant
> >> >> for
> >> >>  this :).
> >> >>  Another one was TUSCANY-2251 that was handled by Simon Nash and
> he
> >> has
> >> >>  also
> >> >>  done good progress on it (found from this list ). This problem
> came
> >> in
> >> >>  eclipse generated web service client (please refer it for more
> >> detail)
> >> >>  so
> >> >>  this is also in hi

GSoC Project - Tuscany SCA support in the Geronimo admin Console

[Thilina Buddhika]

Hi,


On Thu, Jun 5, 2008 at 2:00 AM, ant elder <[EMAIL PROTECTED]> wrote:

> How are you doing with this, is there anything we can help with?


I could not find following class to start the workspace admin.

org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain


How about we create some place in SVN so you have somewhere to work on you
> code within Tuscany?


It will be great if we could maintain an SVN location.


thank you.

best regards,
/ thilina


>
>
>...ant
>
> On Wed, May 28, 2008 at 9:08 AM, Thilina Buddhika <[EMAIL PROTECTED]>
> wrote:
>
>> Hi,
>>
>> I started coding phase on Monday. As the first step, I took a svn update
>> and
>> successfully built it. As discussed earlier in the mailing list (when
>> preparing the proposal), it  was  decided to bring up the
>> tuscany-workspace-
>> admin as a regular web application and run it inside Geronimo as the first
>> step.
>>
>>
>> But I could not find this class and other related classes in my copy of
>> the
>> Tuscany SCA  source.
>>
>>org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>>
>> Has the workspace-admin been moved to a different package ?
>>
>> Thank You.
>>
>> regs,
>> / thilina
>>
>>
>>
>> On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <[EMAIL PROTECTED]>
>> wrote:
>>
>> > Hi,
>> >
>> > I thought of briefing my work within last few days to Tuscany-dev, so
>> that
>> > community can give feedback on it. The wiki page[1] will also be updated
>> > along with this.
>> >
>> > Nowadays I am reading about ACEs and Portlets. I was able to implement a
>> > simple ACE and deploy it in Geronimo.  Also it  was  possible to call
>> some
>> > JSPs and Servlets within that ACE. I am digging more into this and
>> planning
>> > to look at available web based SCA domain admin tool in Tuscany.
>> >
>> > thanks!
>> >
>> > best regards,
>> > / thilina
>> >
>> > [1] -
>> >
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>> >
>> > On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika <[EMAIL PROTECTED]>
>> > wrote:
>> >
>> >> Hi,
>> >> Thanks Luciano for creating that wiki page. It is really easy to work
>> with
>> >> confluence wiki. I created a child page[1] and moved my content to it,
>> from
>> >> my earlier wiki page. I'll be use this new wiki page from now onwards.
>> >>
>> >> thanks!
>> >>
>> >> best regards,
>> >> / thilina
>> >>
>> >> [1] -
>> >>
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
>> >>
>> >>
>> >> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <[EMAIL PROTECTED]
>> >
>> >> wrote:
>> >>
>> >>> Hi Thilina
>> >>>
>> >>>   Thanks for taking the initiative and creating the wiki page. I just
>> >>> created a wiki page/section to be used for GSoC 2008 [1], at the
>> >>> Tuscany Wiki, maybe you and all other students create child pages and
>> >>> use that one.
>> >>>
>> >>> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
>> >>>
>> >>> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <
>> [EMAIL PROTECTED]>
>> >>> wrote:
>> >>> > Hi,
>> >>> >  I started working on my project. According to the Google time
>> line[1],
>> >>> now
>> >>> >  it is the community bonding period. These days I am going through
>> the
>> >>> >  documentations again, and getting more familiar with the project. I
>> >>> started
>> >>> >  a wiki page[2] to  display the current status of the project. I
>> will
>> >>> be
>> >>> >  frequently updating that wiki page. I will be using this thread to
>> for
>> >>> the
>> >>> >  discussions with the community.
>> >>> >
>> >>> >  thanks!
>> >>> >
>> >>> >  best regards,
>> >>> >  / thilina
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >  [1] -
>> >>> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
>> >>> >  [2] -
>> >>> http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Luciano Resende
>> >>> Apache Tuscany Committer
>> >>> http://people.apache.org/~lresende
>> 
>> >>> http://lresende.blogspot.com/
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > E-Mail : [EMAIL PROTECTED]
>> > I blog here : http://thilinamb.blogspot.com
>>
>>
>>
>>
>> --
>> E-Mail : [EMAIL PROTECTED]
>> I blog here : http://thilinamb.blogspot.com
>>
>
>


-- 
E-Mail : [EMAIL PROTECTED]
I blog here : http://thilinamb.blogspot.com



-- 
E-Mail : [EMAIL PROTECTED]
I blog here : http://thilinamb.blogspot.com

Re: what should happen if service and binding.ws require different soap version?

[Simon Laws]

On Tue, Jun 3, 2008 at 1:12 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Simon Laws wrote:
>
>>
>> Hi Mike
>>
>> Sticking a pin in the specs it does say what you are saying. I was
>> thinking
>> "must support" as opposed to "must use" on the service side. Within an SCA
>> domain in Tuscany I believe that the binding matching code will fail to
>> match soap.1_1 and soap.1_2 intents. Crossing the domain boundary what
>> would
>> be the intended action if a soap 1.1 message arrived at a service that is
>> marked as soap 1.2. A response indicating that the message is not
>> understood?
>>
>> Simon
>>
>>  Simon,
>
> The SOAP 1.2 spec itself deals with what happens on a version mismatch of
> this kind and it describes in detail the error response message that must be
> sent under circumstance where the versions do mismatch in exactly this way.
>
>
> Yours,  Mike.
>
> PS Maybe Axis does not follow the SOAP 1.2 spec
>

Ah, so it does. Thanks for the pointer!

Simon

[jira] Closed: (TUSCANY-2369) sample-calculator-ws-webapp fails to deploy

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2369.
--

Resolution: Fixed

Works fine today now when i try to debug it with a fresh build

> sample-calculator-ws-webapp fails to deploy
> ---
>
> Key: TUSCANY-2369
> URL: https://issues.apache.org/jira/browse/TUSCANY-2369
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> sample-calculator-ws-webapp fails to deploy on Tomcat with the following:
> org.osoa.sca.ServiceRuntimeException: 
> java.lang.reflect.InvocationTargetException
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:276)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83)
>   at 
> org.apache.tuscany.sca.host.webapp.WebAppServletHost.init(WebAppServletHost.java:218)
>   at 
> org.apache.tuscany.sca.host.webapp.TuscanyServletFilter.init(TuscanyServletFilter.java:52)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397)
>   at 
> org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108)
>   at 
> org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3709)
>   at 
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4356)
>   at 
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
>   at 
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
>   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
>   at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:829)
>   at 
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:718)
>   at 
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
>   at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
>   at 
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
>   at 
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
>   at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
>   at 
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
>   at 
> org.apache.catalina.core.StandardService.start(StandardService.java:516)
>   at 
> org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
>   at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
>   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.catalina.startup.Bootstrap.start(Bootstrap.java:288)
>   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:258)
>   ... 30 more
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.tuscany.sca.databinding.DataBinding.getXMLTypeHelperClass()Ljava/lang/Class;
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.getElementInfo(Interface2WSDLGenerator.java:515)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateWrapperPart(Interface2WSDLGenerator.java:487)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generateOperation(Interface2WSDLGenerator.java:383)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.interface2wsdl.Interface2WSDLGenerator.generate(Interface2WSDLGenerator.java:159)
>   at 
> org.apache.tuscany.sca.interfacedef.wsdl.java2wsdl.Java2WSDLHelper.createWSDLInterfaceContract(Java2WSDLHelper.java:193)
>   at 
> org.apache.tuscany.sca.binding.ws.axis2.Axis2ReferenceBin

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602606#action_12602606
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

Could you run the test through the debugger with breakpoints on the line " 
javax.xml.stream.XMLInputFactory.newInstance(); " in both the cases? When you 
get to this line, could you set breakpoints on the methods "getResource" and 
"findClass" in OSGiBundleActivator.BundleClassLoader? I would like to make sure 
that
   1) The same OSGiBundleActivator$BundleClassLoader object is used in both 
cases
   2) The "bundles" field of this object contains around 200 bundles
   3) getResource("META-INF/services/javax.xml.stream.XMLInputFactory") when 
called returns a valid URL in both cases
   4) findClass("com.ctc.wstx.stax.WstxInputFactory") should get called in both 
cases, and should return a class from the bundle (the first return statement).

Sorry, I really dont have a clue what is broken...

- Rajini


> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

[jira] Created: (TUSCANY-2372) Unable to build with 1.6 JDK due to JAXB conflict

[James Rutherford (JIRA)]

Unable to build with 1.6 JDK due to JAXB conflict
-

 Key: TUSCANY-2372
 URL: https://issues.apache.org/jira/browse/TUSCANY-2372
 Project: Tuscany
  Issue Type: Bug
  Components: Build System
Affects Versions: Java-SCA-1.2
 Environment: % java -version
java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) Server VM (build 1.6.0_03-b05, mixed mode)

% mvn -version
Maven version: 2.0.8
Java version: 1.6.0_03
OS name: "linux" version: "2.6.24-gentoo-r3" arch: "i386" Family: "unix"
Reporter: James Rutherford


Error running 'mvn' command due to conflict with JAXB API provided by 1.6 JDK:

[INFO] 
[INFO] Building Apache Tuscany SCA Data Binding for JAXB
[INFO]task-segment: [install]
[INFO] 
[INFO] [dependency:copy {execution: copy}]
[INFO] Configured Artifact: javax.xml.bind:jaxb-api:2.1:jar
[INFO] javax.xml.bind:jaxb-api:2.1:jar already exists in 
/home/jim/src/tuscany/tuscany-sca-1.2-incubating-src/modules/databinding-jaxb/target/endorsed
[INFO] [build-helper:add-test-source {execution: add-test-source}]
[INFO] Test Source directory: 
/home/jim/src/tuscany/tuscany-sca-1.2-incubating-src/modules/databinding-jaxb/target/jaxb-source
 added.
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [jaxb2:generate {execution: generate-jaxb}]
[INFO] Removed old generateDirectory 
'/home/jim/src/tuscany/tuscany-sca-1.2-incubating-src/modules/databinding-jaxb/target/jaxb-source'.
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI 
(from 
jar:file:/home/jim/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.5/jaxb-impl-2.1.5.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class)
 needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in 
the bootstrap classloader. (See 
http://java.sun.com/j2se/1.5.0/docs/guide/standards/)
[INFO] 
[INFO] Trace
java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap 
classloader, but this RI (from 
jar:file:/home/jim/.m2/repository/com/sun/xml/bind/jaxb-impl/2.1.5/jaxb-impl-2.1.5.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class)
 needs 2.1 API. Use the endorsed directory mechanism to place jaxb-api.jar in 
the bootstrap classloader. (See 
http://java.sun.com/j2se/1.5.0/docs/guide/standards/)
at 
com.sun.xml.bind.v2.model.impl.ModelBuilder.(ModelBuilder.java:172)
at 
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:422)
at 
com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:286)
at 
com.sun.tools.xjc.reader.xmlschema.bindinfo.BindInfo.getJAXBContext(BindInfo.java:332)
at 
com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl$1.(AnnotationParserFactoryImpl.java:79)
at 
com.sun.tools.xjc.reader.xmlschema.bindinfo.AnnotationParserFactoryImpl.create(AnnotationParserFactoryImpl.java:78)
at 
com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.createAnnotationParser(NGCCRuntimeEx.java:323)
at 
com.sun.xml.xsom.impl.parser.state.annotation.action0(annotation.java:48)
at 
com.sun.xml.xsom.impl.parser.state.annotation.enterElement(annotation.java:73)
at 
com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:378)
at 
com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterElement(NGCCHandler.java:74)
at 
com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:294)
at 
com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:378)
at 
com.sun.xml.xsom.impl.parser.state.NGCCHandler.revertToParentFromEnterElement(NGCCHandler.java:111)
at 
com.sun.xml.xsom.impl.parser.state.foreignAttributes.enterElement(foreignAttributes.java:50)
at 
com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:378)
at 
com.sun.xml.xsom.impl.parser.state.NGCCHandler.spawnChildFromEnterElement(NGCCHandler.java:74)
at 
com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:200)
at 
com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:378)
at 
com.sun.xml.xsom.impl.parser.state.Schema.enterElement(Schema.java:250)
at 
com.sun.xml.xsom.impl.parser.state.NGCCRuntime.sendEnterElement(NGCCRuntime.java:378)
at 
com.sun.xml.xsom.i

[jira] Commented: (TUSCANY-2281) How to create ServiceReferences for references using multiplicity="1..n"

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602589#action_12602589
 ] 

Daniel Stucky commented on TUSCANY-2281:


Hi all,

I just wanted to ask if there are any plans when this issue could be solved.
I'd really like to make use of this feature in the EILF project.

Bye,
Daniel

> How to create ServiceReferences for references using multiplicity="1..n"
> 
>
> Key: TUSCANY-2281
> URL: https://issues.apache.org/jira/browse/TUSCANY-2281
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.2
>Reporter: Daniel Stucky
> Fix For: Java-SCA-Next
>
>
> At the moment it is not possible to create ServiceReferences for specific 
> targets of references with multiplicity="1..n". 
> See the mailing list for details: http://www.mail-archive.com/[EMAIL 
> PROTECTED]/msg03024.html
> A quote from Simon Laws' answer:
> "The OASIS TC has proposed a solution to this issue 
> (http://www.osoa.org/jira/browse/JAVA-9) but this isn't part of the API we 
> have implemented as we have taken the V1 API. Can you raise a JIRA for this 
> as I can't see one already and at least in that way we can track it."

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

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Daniel Stucky (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602588#action_12602588
 ] 

Daniel Stucky commented on TUSCANY-2343:


Hi Rajini,

I added your code snippet. Here is the output:

output of 1st snippet just before scaDomain.start(). no exception is thrown
- TCCL : class 
org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader

output of 2nd snippet in catch block after scaDomain.start()
- TCCL : class 
org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader
but this time javax.xml.stream.XMLInputFactory.newInstance() throws the 
following exception
- javax.xml.stream.FactoryConfigurationError: Provider 
com.bea.xml.stream.MXParserFactory not found

Bye,
Daniel

> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

Re: TUSCANY-2344 & 5 - resource & widget validation

[Ramkumar R]

Thanks Luciano, the issue is resolved now. It works.

-- 
Thanks & Regards,
Ramkumar Ramalingam

Re: GSoC Project - Tuscany SCA support in the Geronimo admin Console

[ant elder]

How are you doing with this, is there anything we can help with? How about
we create some place in SVN so you have somewhere to work on you code within
Tuscany?

   ...ant

On Wed, May 28, 2008 at 9:08 AM, Thilina Buddhika <[EMAIL PROTECTED]>
wrote:

> Hi,
>
> I started coding phase on Monday. As the first step, I took a svn update
> and
> successfully built it. As discussed earlier in the mailing list (when
> preparing the proposal), it  was  decided to bring up the
> tuscany-workspace-
> admin as a regular web application and run it inside Geronimo as the first
> step.
>
>
> But I could not find this class and other related classes in my copy of the
> Tuscany SCA  source.
>
>org.apache.tuscany.sca.workspace.admin.main.DomainAdminMain
>
> Has the workspace-admin been moved to a different package ?
>
> Thank You.
>
> regs,
> / thilina
>
>
>
> On Tue, May 6, 2008 at 11:21 AM, Thilina Buddhika <[EMAIL PROTECTED]>
> wrote:
>
> > Hi,
> >
> > I thought of briefing my work within last few days to Tuscany-dev, so
> that
> > community can give feedback on it. The wiki page[1] will also be updated
> > along with this.
> >
> > Nowadays I am reading about ACEs and Portlets. I was able to implement a
> > simple ACE and deploy it in Geronimo.  Also it  was  possible to call
> some
> > JSPs and Servlets within that ACE. I am digging more into this and
> planning
> > to look at available web based SCA domain admin tool in Tuscany.
> >
> > thanks!
> >
> > best regards,
> > / thilina
> >
> > [1] -
> >
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
> >
> > On Wed, Apr 30, 2008 at 7:03 PM, Thilina Buddhika <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi,
> >> Thanks Luciano for creating that wiki page. It is really easy to work
> with
> >> confluence wiki. I created a child page[1] and moved my content to it,
> from
> >> my earlier wiki page. I'll be use this new wiki page from now onwards.
> >>
> >> thanks!
> >>
> >> best regards,
> >> / thilina
> >>
> >> [1] -
> >>
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+SCA+support+in+the+Apache+Geronimo+Admin+Console
> >>
> >>
> >> On Tue, Apr 29, 2008 at 9:05 PM, Luciano Resende <[EMAIL PROTECTED]>
> >> wrote:
> >>
> >>> Hi Thilina
> >>>
> >>>   Thanks for taking the initiative and creating the wiki page. I just
> >>> created a wiki page/section to be used for GSoC 2008 [1], at the
> >>> Tuscany Wiki, maybe you and all other students create child pages and
> >>> use that one.
> >>>
> >>> [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/GSoC+2008
> >>>
> >>> On Tue, Apr 29, 2008 at 6:08 AM, Thilina Buddhika <[EMAIL PROTECTED]
> >
> >>> wrote:
> >>> > Hi,
> >>> >  I started working on my project. According to the Google time
> line[1],
> >>> now
> >>> >  it is the community bonding period. These days I am going through
> the
> >>> >  documentations again, and getting more familiar with the project. I
> >>> started
> >>> >  a wiki page[2] to  display the current status of the project. I will
> >>> be
> >>> >  frequently updating that wiki page. I will be using this thread to
> for
> >>> the
> >>> >  discussions with the community.
> >>> >
> >>> >  thanks!
> >>> >
> >>> >  best regards,
> >>> >  / thilina
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >  [1] -
> >>> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> >>> >  [2] -
> >>> http://wiki.apache.org/incubator/ThilinaBuddhika/GSoC2008_status
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Luciano Resende
> >>> Apache Tuscany Committer
> >>> http://people.apache.org/~lresende
> 
> >>> http://lresende.blogspot.com/
> >>>
> >>
> >>
> >
> >
> > --
> > E-Mail : [EMAIL PROTECTED]
> > I blog here : http://thilinamb.blogspot.com
>
>
>
>
> --
> E-Mail : [EMAIL PROTECTED]
> I blog here : http://thilinamb.blogspot.com
>

Re: [RESULT] [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[Feng Wang]

It is ok to me.
+1 
 
Thanks,
Feng Wang

On 2008-06-05 15:03:00,ant elder <[EMAIL PROTECTED]> wrote:

>Passed with +1s from me, Luciano Resende, Dave Sowerby, Vamsavardhana Reddy
>, Dan Becker, Simon Laws, Davanum Srinivas, and affirmative comments from
>Mike Edwards  and haleh mahbod.
>
>Thanks everyone for participating.
>
>   ...ant
>
>On Sun, Jun 1, 2008 at 10:10 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> Please review and vote on the release artifacts for the Tuscany SCA for
>> Java 1.2.1 maintenance release.
>>
>> The artifacts are available for review at:
>> http://people.apache.org/~antelder/tuscany/1.2.1-RC1/
>>
>> This includes the signed binary and source distributions, Maven staging
>> repository, and eclipse update site.
>>
>> The SVN tag for the release is:
>> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
>>
>> The _only_ code change in this over the 1.2 release is in r657526 [1], all
>> other changes are just version updates and doc changes for the release.
>>
>> +1 to release from me.
>>
>>...ant
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>>  PROTECTED]
>>
>>
>>
>

[jira] Commented: (TUSCANY-2343) OSGi bundle design leads to class loading issues

[Rajini Sivaram (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602583#action_12602583
 ] 

Rajini Sivaram commented on TUSCANY-2343:
-

Daniel,

It still looks like a problem with TCCL, though I dont know why. I think it is 
too early to be related to the JAXB issue.

Can you add a try-catch block in ScaDomainActivator.initDomainByContribution 
around the code which creates and starts the SCA domain, and include this 
snippet of code twice - just before calling EmbeddedSCADomain.start after you 
have set TCCL, and in the catch block.  

try {
System.out.println("TCCL : " + 
Thread.currentThread().getContextClassLoader().getClass());
javax.xml.stream.XMLInputFactory.newInstance();
} catch (Throwable e) {
e.printStackTrace();
}

I would expect to see the print "TCCL : class 
org.apache.tuscany.sca.osgi.runtime.OSGiBundleActivator$BundleClassLoader" and 
no exception thrown from the call in both cases if it works.

- Rajini


> OSGi bundle design leads to class loading issues
> 
>
> Key: TUSCANY-2343
> URL: https://issues.apache.org/jira/browse/TUSCANY-2343
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Georg Schmidt
> Attachments: Libary Versions.xls, test_bundles.zip
>
>
> Currently the design of the OSGi bundles leads to class loading exceptions. 
> There seem to be several reasons for this behavior:
> * reexporting of all libraries without version numbers
> * imports without version numbers
> Please use distinct bundles for 3rd party libraries. That would lead to 
> easier reusage of your bundles in a larger OSGi project.
> The current status leads to undefined system behaviour due to the OSGi class 
> loading concept.
> Please tell if you see a way, how we could support you by achieving this 
> goal. (If a solution is interesting for you)  We are willing to contribute 
> because its a critical project issue for us.
> The problems occur with the current snapshot release. Sorry, I do not know 
> which version to take.

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

Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer

[Manu George]

Congrats Vamsi !!!

On Tue, Jun 3, 2008 at 4:56 PM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Congratulations Vamsi... Welcome !!!
>
> - Venkat
>
> On Mon, Jun 2, 2008 at 11:32 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
>> The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany
>> committer.
>>
>> Congratulations and welcome!
>>
>>   ...ant
>>
>

Re: Changing SCA trunk version from 2.0-incubating-SNAPSHOT to SNAPSHOT

[ant elder]

On Wed, Jun 4, 2008 at 5:59 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> The good thing about having a version on the pom is that you can have
> multiple SNAPSHOTs available in a maven repo (e.g 1.2-SNAPSHOT,
> 1.2.1-SNAPSHOT, TRUNK x-SNAPSHOT and TRUNK y-SNAPSHOT), this also
> allows for multiple active development streams.
>
> If you have SNAPSHOT only, I guess you are restricted to only latest
> SNAPSHOT, and I also don't see how you would be able to have multiple
> active development streams in this case.
>
>
Well I don't think we should be having "multiple active development streams"
:) Fine to have historic 1.x, 2.x, 3.x etc branches which are kept alive for
maintenance, and that will work fine with trunk being just SNAPSHOT. But
we're a small group of active committers still learning how to get consensus
on things and i worry it could easily end quite badly if we have multiple
trunks all being developed in parralel competing to be the next new version.

   ...ant

[RESULT] [Vote] Release Tuscany Java SCA 1.2.1 (RC1)

[ant elder]

Passed with +1s from me, Luciano Resende, Dave Sowerby, Vamsavardhana Reddy
, Dan Becker, Simon Laws, Davanum Srinivas, and affirmative comments from
Mike Edwards  and haleh mahbod.

Thanks everyone for participating.

   ...ant

On Sun, Jun 1, 2008 at 10:10 PM, ant elder <[EMAIL PROTECTED]> wrote:

> Please review and vote on the release artifacts for the Tuscany SCA for
> Java 1.2.1 maintenance release.
>
> The artifacts are available for review at:
> http://people.apache.org/~antelder/tuscany/1.2.1-RC1/
>
> This includes the signed binary and source distributions, Maven staging
> repository, and eclipse update site.
>
> The SVN tag for the release is:
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2.1
>
> The _only_ code change in this over the 1.2 release is in r657526 [1], all
> other changes are just version updates and doc changes for the release.
>
> +1 to release from me.
>
>...ant
>
> [1]
> http://mail-archives.apache.org/mod_mbox/ws-tuscany-commits/200805.mbox/[EMAIL
>  PROTECTED]
>
>
>