[jira] Updated: (TUSCANY-2234) More tests for section 1.8 of SCA Java Annotations And APIs V100

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan updated TUSCANY-2234:
--

Attachment: T2234-vtest.new.zip
T2234.vtest.patch

> More tests for section 1.8 of SCA Java Annotations And APIs V100
> 
>
> Key: TUSCANY-2234
> URL: https://issues.apache.org/jira/browse/TUSCANY-2234
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Priority: Minor
> Attachments: T2234-vtest.new.zip, T2234.vtest.patch
>
>
> Add more tests for following sections
> 1.8.1 @AllowsPassByReference
> 1.8.3 @ComponentName
> 1.8.5 @Constructor
> 1.8.6 @Context
> 1.8.15 @Remotable

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


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

Deadline for ranking proposals Re: [GSoC] Time to rank the Google Summer of Code Proposals

[Luciano Resende]

This is a gentle reminder. We have untill April 18th midnight PDT  to
rank proposals. All mentors, please take a moment to rank proposals.

[1] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29+Applications

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

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

Re: [(GSoC] Time to rank the Google Summer of Code Proposals

[Luciano Resende]

Hey Giorgio,

   That would be really good. Now that you have your apache account
ready, please follow the next stes:

- Go to GSoC website [1] and register as a mentor and select Apache
Software Foundation as mentor organization. You might need to add your
mail to MailAlias.txt that is available in repos/private/committers in
order to get approved.

- Subscribe to code-awards mailling list ([EMAIL PROTECTED])

- Send e-mail to code-awards asking for approval of your mentor application.

- Once you are done as a mentor, please review applications. I have
added a list of Tuscany applications in our wiki [2]

[1] http://code.google.com/soc/2008/mentor_step1.html
[2] 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Google+Summer+of+Code+%282008%29+Applications

On 4/15/08, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Giorgio Zoppi wrote:
> > For map/hadoop if you need a part time mentor till 30 June, ask me. After
> > that time I'll travel around Spain all summer.
> >
> >
>
> Giorgio, that's great! I'll be happy to mentor the map-reduce / tuscany /
> hadoop project with you as a co-mentor.
>
> Can you sign up as a mentor and indicate which applications you're willing
> to co-mentor? I'm still catching up with email but I think the instructions
> to sign up are discussed in this thread too.
>
> I wished I could travel around Spain all summer too :)
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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

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

[Luciano Resende]

The Continuum e-mails are not going to the dev-list anymore, and only
to committers that committed something on the faulty build. You can
always go directly to the build machine to check.

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

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

[jira] Updated: (TUSCANY-2234) More tests for section 1.8 of SCA Java Annotations And APIs V100

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan updated TUSCANY-2234:
--

Description: 
Add more tests for following sections
1.8.1 @AllowsPassByReference
1.8.3 @ComponentName
1.8.5 @Constructor
1.8.6 @Context
1.8.15 @Remotable

  was:
1.8.1 @AllowsPassByReference
1.8.3 @ComponentName
1.8.5 @Constructor
1.8.6 @Context
1.8.15 @Remotable


> More tests for section 1.8 of SCA Java Annotations And APIs V100
> 
>
> Key: TUSCANY-2234
> URL: https://issues.apache.org/jira/browse/TUSCANY-2234
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Priority: Minor
>
> Add more tests for following sections
> 1.8.1 @AllowsPassByReference
> 1.8.3 @ComponentName
> 1.8.5 @Constructor
> 1.8.6 @Context
> 1.8.15 @Remotable

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


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

[jira] Created: (TUSCANY-2234) More tests for section 1.8 of SCA Java Annotations And APIs V100

[Gilbert Kwan (JIRA)]

More tests for section 1.8 of SCA Java Annotations And APIs V100


 Key: TUSCANY-2234
 URL: https://issues.apache.org/jira/browse/TUSCANY-2234
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Affects Versions: Java-SCA-Next
Reporter: Gilbert Kwan
Priority: Minor


1.8.1 @AllowsPassByReference
1.8.3 @ComponentName
1.8.5 @Constructor
1.8.6 @Context
1.8.15 @Remotable

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


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

Re: JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Adriano Crestani]

 Folks,

Sheepish grin - the surprise to me was to find that this is JDK 6 related -
I thought I was using Sun 1.5.0_14.  However - SOMEHOW my system is using
Sun 1.6.0_03 - and I'm still trying to work out why!

MS Windows?

Adriano Crestani

On Tue, Apr 15, 2

008 at 10:53 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:

> Mike Edwards wrote:
>
> > Jean-Sebastien Delfino wrote:
> >
> >
> > > >
> > > You'll get this with some of the other samples too I think, if you use
> > > JDK 6 and don't place JAXB 2.1 in the lib/endorsed directory of your JRE.
> > >
> > > Try to do what the the error message is asking you to do :)
> > >
> >
> > Folks,
> >
> > Sheepish grin - the surprise to me was to find that this is JDK 6
> > related - I thought I was using Sun 1.5.0_14.  However - SOMEHOW my system
> > is using Sun 1.6.0_03 - and I'm still trying to work out why!
> >
> >
> > Yours, Mike
> >
> >
> Check you PATH and JAVA_HOME? :)
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Usability improvements to admin application

[Jean-Sebastien Delfino]

Hi,

I'm currently working on some usability improvements of the admin 
application, in particular:
- popup lists to allow you to select contribution URIs, namespaces, 
composite names, to save a lot of typing
- error reporting and better robustness of the admin agains erroneous 
contributions and composites.


I'm also starting to implement the 'Search' function on the admin home 
page (which currently says 'under construction'), which will make it 
really easier to find things in the SCA domain. I have tried using 
Apache Solr and it's light weight and seems to work well, I'd like to 
get that working smoothly sometime this week.


If people are interested in trying the admin app, it would be great if 
you could try it with your own scenarios or samples (as I've mostly used 
it with the tutorial and calculator-distributed) and report or help fix 
any JIRA issues you run into or suggest improvements as you use it.


Thanks!
--
Jean-Sebastien

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

Re: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Giorgio Zoppi]

2008/4/15, Raymond Feng <[EMAIL PROTECTED]>:
> It might not be feasible for some users. But it's at least an option for
> others :-).
>
>  Thanks,
>  Raymond
I agree with you but i was only spotting a possible doubt.

Ciao,
Giorgio.
---
"The only people for me are the mad ones, the ones who are mad to
live, mad to talk, mad to be saved. The ones who never yawn or say a
commonplace thing, but burn, burn, burn like fabulous yellow roman
candles exploding like spiders across the stars"
On The Road - Jack Kerouac

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

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

[Rajini Sivaram]

Sorry about that. I have committed a fix under revision 648396.

Due to a difference in classloading between the IBM JDK that I was using for
testing and the Sun(?) JDK on Continuum, an additional class was required to
be visible from the test bundle, resulting in the NoClassDefFoundError.

I was expecting to see a build failure report if the Continuum build failed
after I checked in code. Is that completely turned off now?


On 4/15/08, Mark Combellack <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
>
>
> Over the last few days, the continuum build has been failing for the trunk
> of Tuscany. The problem is that two tests are failing in
> itest/osgi-implementation. The relevant error messages are:
>
>
>
>
>
> testJavaToOSGi(helloworld.sdo.SdoTestCase)  Time elapsed: 0.424 sec  <<<
> ERROR!
>
> java.lang.NoClassDefFoundError
>
>  at
>
> helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien
> tComponent.java:33)
>
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>  at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>
>  at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>
>  at java.lang.reflect.Method.invoke(Method.java:585)
>
>  at
>
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvo
> ker.invoke(JavaImplementationInvoker.java:109)
>
>  at
>
> org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
> assByValueInterceptor.java:108)
>
>  at
>
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingI
> nvoker.java:61)
>
>  at
>
> org.apache.tuscany.sca.core.databinding.wire.PassByValueInterceptor.invoke(P
> assByValueInterceptor.java:108)
>
>  at
>
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
> tionHandler.java:286)
>
>  at
>
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvoca
> tionHandler.java:154)
>
>  at $Proxy141.getGreetings(Unknown Source)
>
>  at helloworld.sdo.SdoTestCase.testJavaToOSGi(SdoTestCase.java:81)
>
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>  at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>
>  at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>
>  at java.lang.reflect.Method.invoke(Method.java:585)
>
>  at junit.framework.TestCase.runTest(TestCase.java:168)
>
>  at junit.framework.TestCase.runBare(TestCase.java:134)
>
>  at junit.framework.TestResult$1.protect(TestResult.java:110)
>
>  at junit.framework.TestResult.runProtected(TestResult.java:128)
>
>  at junit.framework.TestResult.run(TestResult.java:113)
>
>  at junit.framework.TestCase.run(TestCase.java:124)
>
>  at junit.framework.TestSuite.runTest(TestSuite.java:232)
>
>  at junit.framework.TestSuite.run(TestSuite.java:227)
>
>  at
>
> org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35
> )
>
>  at
>
> org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62
> )
>
>  at
>
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(Ab
> stractDirectoryTestSuite.java:138)
>
>  at
>
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractD
> irectoryTestSuite.java:125)
>
>  at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
>
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>  at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>
>  at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>
>  at java.lang.reflect.Method.invoke(Method.java:585)
>
>  at
>
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireB
> ooter.java:308)
>
>  at
>
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879
> )
>
>
>
> testOSGiToJava(helloworld.sdo.SdoTestCase)  Time elapsed: 0.278 sec  <<<
> ERROR!
>
> java.lang.NoClassDefFoundError
>
>  at
>
> helloworld.sdo.client.HelloWorldClientComponent.getGreetings(HelloWorldClien
> tComponent.java:33)
>
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>  at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
> )
>
>  at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
> .java:25)
>
>  at java.lang.reflect.Method.invoke(Method.java:585)
>
>  at
>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo
> keMethod(OSGiTargetInvoker.java:171)
>
>  at
>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiRemotableInvoker.i
> nvokeMethod(OSGiRemotableInvoker.java:75)
>
>  at
>
> org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo
>

Re: [DISCUSS] Evolving Implementation-data-xml

[Luciano Resende]

I'd suggest the following as the next steps around implementation-data-xml

- Add support for data collection interface from implementation-data
- At this point, integration with binding-atom-abdera should be
working, it would be great to integrate this with our store tutorial,
either by enhancing the catalog-db or by creating a new module
catalog-db-xml.
- The exercise above should also help drive the requirements for
database schema that you are proposing with a concrete scenario.

Thoughts ?

On Tue, Apr 15, 2008 at 12:14 PM, Douglas Leite <[EMAIL PROTECTED]> wrote:
> In my last contribution, I have proposed a first version of Update and
>  Insert methods for impl.data.xml component.
>  One of the insert method limitations is that the table must only have
>  columns which types are char or varchar. However, I want to improve this,
>  allowing any sql primitive type.
>  The fact is, the syntax to insert a varchar, for example, is different to
>  insert a integer. So, it's necessary to know the types of the column.
>  I could resolve this problem in, at least, to different ways: First, I could
>  use metadata information on the InsertInvoker, and discover the types of
>  columns. Another way to do this, is to add the column type information in
>  the xml stream retrieved by the get method. So, we would have something like
>  this:
>
>  
> 
> New Coorporation I
> +5511990202146
>  . . .
> 
>  
>
>  I am not sure if other metadata informations should be added to the xml
>  stream. But, at the moment, I think that column type would be useful.
>
>  Thoughts?
>
>  --
>  Douglas Siqueira Leite
>  Computer Science Master's degree student of University of Campinas (Unicamp)
>



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

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

[jira] Updated: (TUSCANY-2233) Test Cases for Conversation API

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang updated TUSCANY-2233:


Attachment: ConversationJIRA2233.patch

> Test Cases for Conversation API
> ---
>
> Key: TUSCANY-2233
> URL: https://issues.apache.org/jira/browse/TUSCANY-2233
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: ConversationJIRA2233.patch
>
>
> Conversation's vtest.

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


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

[jira] Created: (TUSCANY-2232) Test Cases for ServiceReference API

[Yee-Kang Chang (JIRA)]

Test Cases for ServiceReference API
---

 Key: TUSCANY-2232
 URL: https://issues.apache.org/jira/browse/TUSCANY-2232
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Reporter: Yee-Kang Chang
 Attachments: ServiceReferenceJIRA2232.patch

ServiceReference's vtest.

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


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

[jira] Updated: (TUSCANY-2232) Test Cases for ServiceReference API

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang updated TUSCANY-2232:


Attachment: ServiceReferenceJIRA2232.patch

> Test Cases for ServiceReference API
> ---
>
> Key: TUSCANY-2232
> URL: https://issues.apache.org/jira/browse/TUSCANY-2232
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: ServiceReferenceJIRA2232.patch
>
>
> ServiceReference's vtest.

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


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

[jira] Created: (TUSCANY-2233) Test Cases for Conversation API

[Yee-Kang Chang (JIRA)]

Test Cases for Conversation API
---

 Key: TUSCANY-2233
 URL: https://issues.apache.org/jira/browse/TUSCANY-2233
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Reporter: Yee-Kang Chang


Conversation's vtest.

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


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

[DISCUSS] Evolving Implementation-data-xml

[Douglas Leite]

In my last contribution, I have proposed a first version of Update and
Insert methods for impl.data.xml component.
One of the insert method limitations is that the table must only have
columns which types are char or varchar. However, I want to improve this,
allowing any sql primitive type.
The fact is, the syntax to insert a varchar, for example, is different to
insert a integer. So, it's necessary to know the types of the column.
I could resolve this problem in, at least, to different ways: First, I could
use metadata information on the InsertInvoker, and discover the types of
columns. Another way to do this, is to add the column type information in
the xml stream retrieved by the get method. So, we would have something like
this:



New Coorporation I
+5511990202146
 . . .



I am not sure if other metadata informations should be added to the xml
stream. But, at the moment, I think that column type would be useful.

Thoughts?

-- 
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas (Unicamp)

[jira] Updated: (TUSCANY-2231) Test Cases for CallableReference API

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang updated TUSCANY-2231:


Attachment: CallableReferenceJIRA2231.patch

> Test Cases for CallableReference API
> 
>
> Key: TUSCANY-2231
> URL: https://issues.apache.org/jira/browse/TUSCANY-2231
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: CallableReferenceJIRA2231.patch
>
>
> Test Cases for CallableReference's vtest.

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


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

[jira] Created: (TUSCANY-2231) Test Cases for CallableReference API

[Yee-Kang Chang (JIRA)]

Test Cases for CallableReference API


 Key: TUSCANY-2231
 URL: https://issues.apache.org/jira/browse/TUSCANY-2231
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Reporter: Yee-Kang Chang
 Attachments: CallableReferenceJIRA2231.patch

Test Cases for CallableReference's vtest.

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


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

[jira] Created: (TUSCANY-2230) Test Cases for RequestContext API

[Yee-Kang Chang (JIRA)]

Test Cases for RequestContext API
-

 Key: TUSCANY-2230
 URL: https://issues.apache.org/jira/browse/TUSCANY-2230
 Project: Tuscany
  Issue Type: Test
  Components: Java SCA Verification Tests
Reporter: Yee-Kang Chang
 Attachments: RequestContextJIRA2230.patch

Test Cases for RequestContext's vtest.

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


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

[jira] Updated: (TUSCANY-2230) Test Cases for RequestContext API

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang updated TUSCANY-2230:


Attachment: RequestContextJIRA2230.patch

> Test Cases for RequestContext API
> -
>
> Key: TUSCANY-2230
> URL: https://issues.apache.org/jira/browse/TUSCANY-2230
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Reporter: Yee-Kang Chang
> Attachments: RequestContextJIRA2230.patch
>
>
> Test Cases for RequestContext's vtest.

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


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

Re: JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Jean-Sebastien Delfino wrote:





You'll get this with some of the other samples too I think, if you use 
JDK 6 and don't place JAXB 2.1 in the lib/endorsed directory of your JRE.


Try to do what the the error message is asking you to do :)


Folks,

Sheepish grin - the surprise to me was to find that this is JDK 6 
related - I thought I was using Sun 1.5.0_14.  However - SOMEHOW my 
system is using Sun 1.6.0_03 - and I'm still trying to work out why!



Yours, Mike



Check you PATH and JAVA_HOME? :)

--
Jean-Sebastien

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

[jira] Created: (TUSCANY-2229) Got WARNING if @Context is used to annotate a setter method

[Gilbert Kwan (JIRA)]

Got WARNING if @Context is used to annotate a setter method
---

 Key: TUSCANY-2229
 URL: https://issues.apache.org/jira/browse/TUSCANY-2229
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Core Runtime
Affects Versions: Java-SCA-Next
Reporter: Gilbert Kwan
Priority: Minor


I got following warnings when @Context is used to annotate a setter method:

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/requestContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/componentContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/requestContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/componentContext

Implementation Class:
=
public RequestContext requestContext;
public ComponentContext componentContext;

@Context
public void setComponentContext(ComponentContext componentContext) {
   this.componentContext = componentContext;
}

@Context
public void setRequestContext(RequestContext requestContext) {
   this.requestContext = requestContext;
}

Composite:
=
http://www.osoa.org/xmlns/sca/1.0"; 
   targetNamespace="http://java-api-tests";
   name="AB-Composite">
   
   
   


If @Context is used to annotate a class field, there is no warning.

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


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

[jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan commented on TUSCANY-2165:
---

Although b4 is a public field, without setter and un-annotated,  should it be 
injected?
- If yes, the patch not work and that why atReference2 failed.
- If no, vtest need to rewrite.

I tried other scenario b6 which is public field, with setter and un-annotated, 
it also failed too. I suspect the problem is not fixed yet.

I used revision 648306.

> Java runtime should inject service references to field with common name in 
> absence of @Reference 
> -
>
> Key: TUSCANY-2165
> URL: https://issues.apache.org/jira/browse/TUSCANY-2165
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
> Attachments: TUSCANY-2165-revised-test.patch, TUSCANY-2165.patch
>
>
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> The vTest:  
> org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 
> demonstrates this issue

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


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

Re: Should we move to SDO 1.1-incubating version for SCA Java?

[Luciano Resende]

On Tue, Apr 15, 2008 at 9:30 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  Now the SDO 1.1-incubating has been released. Should we adjust the pom.xml
> in SCA Java to reference this release?

+0, As you have CCed our user list, I'll defer this feedback them.

>
>  ATM, we have SDO 1.0-incubating-SNAPSHOT in trunk. And SCA projects either
> reference SDO 1.0-incubating or 1.0-incubating-SNAPSHOT. I think it's better
> to have SCA depends on a released SDO version consistently across the
> modules. What do you think?

+1, We should be consistent here and depend on a released SDO version
across all SCA modules.

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



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

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

Re: Got WARNING if @Context is used to annotate a setter method

[Raymond Feng]

Please open a JIRA and attach your test case then. We'll investigate.

Thanks,
Raymond
--
From: "Gilbert Kwan" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 10:27 AM
To: 
Subject: Re: Got WARNING if @Context is used to annotate a setter method


my composite just simply as:

http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://java-api-tests";
name="AB-Composite">

   
   
   





On Tue, Apr 15, 2008 at 1:08 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
I need to see your composite file. It seems that you're trying to 
configure
the context as a property. Any setter method annotated with @Context will 
be
excluded from the SCA Reference/Property introspection against the Java 
impl

class.

Thanks,
Raymond
--
From: "Gilbert Kwan" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 9:08 AM
To: 
Subject: Got WARNING if @Context is used to annotate a setter method

>
>
>
> I am curious why I got following warnings when @Context is used to
> annotate a setter method:
>
> Apr 15, 2008 11:45:18 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: No type specified on component property:
BComponent/requestContext
> Apr 15, 2008 11:45:18 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: No type specified on component property:
BComponent/componentContext
> Apr 15, 2008 11:45:18 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: No type specified on component property:
BComponent/requestContext
> Apr 15, 2008 11:45:18 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: No type specified on component property:
BComponent/componentContext
>
> public RequestContext requestContext;
> public ComponentContext componentContext;
>
> @Context
> public void setComponentContext(ComponentContext componentContext) {
> this.componentContext = componentContext;
> }
>
> @Context
> public void setRequestContext(RequestContext requestContext) {
> this.requestContext = requestContext;
> }
>
> If @Context is used to annotate a class field, there is no warning.
>
> Regards
> Gilbert
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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




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



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

Re: Got WARNING if @Context is used to annotate a setter method

[Gilbert Kwan]

my composite just simply as:

http://www.osoa.org/xmlns/sca/1.0";
targetNamespace="http://java-api-tests";
name="AB-Composite">









On Tue, Apr 15, 2008 at 1:08 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> I need to see your composite file. It seems that you're trying to configure
> the context as a property. Any setter method annotated with @Context will be
> excluded from the SCA Reference/Property introspection against the Java impl
> class.
>
> Thanks,
> Raymond
> --
> From: "Gilbert Kwan" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 15, 2008 9:08 AM
> To: 
> Subject: Got WARNING if @Context is used to annotate a setter method
>
> >
> >
> >
> > I am curious why I got following warnings when @Context is used to
> > annotate a setter method:
> >
> > Apr 15, 2008 11:45:18 AM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: No type specified on component property:
> BComponent/requestContext
> > Apr 15, 2008 11:45:18 AM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: No type specified on component property:
> BComponent/componentContext
> > Apr 15, 2008 11:45:18 AM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: No type specified on component property:
> BComponent/requestContext
> > Apr 15, 2008 11:45:18 AM
> > org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> > problem
> > WARNING: No type specified on component property:
> BComponent/componentContext
> >
> > public RequestContext requestContext;
> > public ComponentContext componentContext;
> >
> > @Context
> > public void setComponentContext(ComponentContext componentContext) {
> > this.componentContext = componentContext;
> > }
> >
> > @Context
> > public void setRequestContext(RequestContext requestContext) {
> > this.requestContext = requestContext;
> > }
> >
> > If @Context is used to annotate a class field, there is no warning.
> >
> > Regards
> > Gilbert
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Mike Edwards]

Jean-Sebastien Delfino wrote:





You'll get this with some of the other samples too I think, if you use 
JDK 6 and don't place JAXB 2.1 in the lib/endorsed directory of your JRE.


Try to do what the the error message is asking you to do :)


Folks,

Sheepish grin - the surprise to me was to find that this is JDK 6 
related - I thought I was using Sun 1.5.0_14.  However - SOMEHOW my 
system is using Sun 1.6.0_03 - and I'm still trying to work out why!



Yours, Mike

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

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

[Yang Lei]

I agree with Simon's emphases on the point of view. I understand
Tuscany may prefer one solution over the other. However from
extensibility perspective, there need some extension points to enable
Tuscany adapters to overwrite the default behavior. I think the thread
discussion on reference target and the comparing of 1 and 2 showcase
one of the extensibility area :  how to resolve reference target for
different bindings.

I am actually looking beyond just reference target, I see the
extensibility in the following areas:

1. When/How to enable a binding to resolve the target endpoint . This
include the case to support reference target, and beyond, such as
supporting wireByImpl or autoWire. This also include distributed
support in case adapters have different ways to support distributed
contributions for a given virtual domain.

I understand Tuscany has workspace discussions. It may potentially be
a solution.I am still waiting to see how workspace is intending to
support distributed scenarios or how it can enable late binding on
resolving target endpoint. Regardless workspace is the solution or
not, we need the flexibility and extensibility to overwrite Tuscany's
default behavior on binding end point resolving.

2. When/How the binding resolvable is in used,

Some part of the Tuscany code is using binding resolved or not to have
different process  (see point 3). I think if certain logic outside
binding needs to understand if a binding is resolvable, we should make
it clear which method achieve it so binding implementations know what
to expect.

I can see Tuscany code uses binding's URI and targetComponentService
today, I think it should be limited to one method only, I am not sure
overloading URI is  good .

3. When/How to make binding selections on the reference side.

I can see Tuscany is trying to remove the unresolvable bindings first
from the reference side , then use some algorithm to either pick the
default binding if it exists or pick the first on the list.

I think we need some plug in point in Tuscany to enable different
algorithm from the above default behavior. And the plugin point need
to enable late binding so during reference's execution time we can
determine a binding is resolvable or not and then use some own
prioritizing rules to select the right bindings.


I would like to see these discussions concluded with a set of API and
some form of API interaction diagrams in the end.

Thanks.

Yang



I can see a couple of scenarios:



I thinkand binding selection that we need to enable some extension
points for others using other algorism or other

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

Re: Got WARNING if @Context is used to annotate a setter method

[Raymond Feng]

I need to see your composite file. It seems that you're trying to configure 
the context as a property. Any setter method annotated with @Context will be 
excluded from the SCA Reference/Property introspection against the Java impl 
class.


Thanks,
Raymond
--
From: "Gilbert Kwan" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 9:08 AM
To: 
Subject: Got WARNING if @Context is used to annotate a setter method


I am curious why I got following warnings when @Context is used to
annotate a setter method:

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: 
BComponent/requestContext

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: 
BComponent/componentContext

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: 
BComponent/requestContext

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: 
BComponent/componentContext


public RequestContext requestContext;
public ComponentContext componentContext;

@Context
public void setComponentContext(ComponentContext componentContext) {
this.componentContext = componentContext;
}

@Context
public void setRequestContext(RequestContext requestContext) {
this.requestContext = requestContext;
}

If @Context is used to annotate a class field, there is no warning.

Regards
Gilbert

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



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

Re: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Raymond Feng]

It might not be feasible for some users. But it's at least an option for 
others :-).


Thanks,
Raymond
--
From: "Giorgio Zoppi" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 8:56 AM
To: 
Subject: Re: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java 
SCA 1.2-incubating (RC4)



2008/4/15, Raymond Feng <[EMAIL PROTECTED]>:

I'm changing the subject to avoid hijacking the [VOTE] thread.



I as user, dislike requiring the last java version, why should i
upgrade it, when all
my programs works?
So the first choice is not an option for me.

Ciao,
Giorgio.
---
"The only people for me are the mad ones, the ones who are mad to
live, mad to talk, mad to be saved. The ones who never yawn or say a
commonplace thing, but burn, burn, burn like fabulous yellow roman
candles exploding like spiders across the stars"
On The Road - Jack Kerouac

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



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

Re: Apache Tuscany committer status reaffirmation

[Brent Daniel]

Ant,

  My preference would be to remain a committer. However, I am not sure
when my schedule will allow for a deeper involvement.

Lately, I have been submitting fixes in patches rather than committing
directly. With a small number of fixes this isn't a big deal, and it
ensures that at least one person reviews the fix, whereas a simple
commit could be overlooked. I can certainly continue to work like this
without committership, but would prefer to keep the ability to commit
for when I am able to spend more time on the Tuscany code base.

Brent

On Sat, Apr 12, 2008 at 2:23 AM, ant elder <[EMAIL PROTECTED]> wrote:
> You are receiving this email because you are listed as an Apache
>  Tuscany committer. Tuscany is looking to graduate in the near future
>  and following Apache Incubator practice is cleaning up the committer
>  list.  Tuscany has 35 committers listed on the status file some of
>  those have left and some were just listed there when the original
>  proposal was accepted and have never even once committed anything.
>  We've decided any one who has interacted with the project within the
>  last 12 months will automatically remain a committer, anyone else will
>  need to reply to this email to retain their committer status.
>
>  These are the committers who've participated in the last 12 months and
>  will automatically retain their committer status:
>
> adrianocrestani Adriano Crestani
> amita   Amita Vadhavkar
> ajborleyAndrew Borley
> antelderAnt Elder
> bjohnsonBrady Johnson
> dkulp   Dan Kulp
> frankb  Frank Budinsky
> fuhwei  Fuhwei Lwo
> giorgio Giorgio Zoppi
> isilval Ignacio Silva-Lepe
> jsdelfino   Jean-Sebastien Delfino
> kelvingoodson   Kelvin Goodson
> kwilliams   Kevin Williams
> lresendeLuciano Resende
> mcombellack Mark Combellack
> myoder  Michael Yoder
> edwardsmj   Mike Edwards
> nashSimon Nash
> rsivaramRajini Sivaram
> rfeng   Raymond Feng
> robbinspg   Pete Robbins
> slaws   Simon Laws
> svkrish Venkata Krishnan
>
>  So, if you are not on that list but would like to retain your Tuscany
>  committer status please reply to this email and let us know about how
>  you would like to be involved with Tuscany. Also, if you are on that
>  list but no longer want to stay a committer once Tuscany graduates you
>  can also reply to this email and we'll remove your name.
>
>  Many thanks,
>  The Apache Tuscany PPMC
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: Can @ConversationID apply on private variable?

[Kevin Williams]

The Specification is inconsistent since:

504 If a *protected* or *public* field or setter method is
annotated with @ConversationID, then the conversation
505 ID for the conversation is injected onto the field ...

My guess is that the example has a typo and should actually be:

   1710 @ConversationID
   1711 protected String ConversationID;

--Kevin

On Fri, Apr 11, 2008 at 10:01 AM, Gilbert Kwan <[EMAIL PROTECTED]> wrote:
> In the spec of "Java Common Annotations and APIs"
>  
> (http://www.osoa.org/download/attachments/35/SCA_JavaAnnotationsAndAPIs_V100.pdf?version=1),
>  line 1710-1711 says
>
>  1710 @ConversationID
>  1711 private String ConversationID;
>
>  I tried and got following warning:
>  Apr 11, 2008 11:50:37 AM
>  
> org.apache.tuscany.sca.implementation.java.introspect.impl.JavaIntrospectionHelper
>  checkInvalidAnnotations
>  WARNING: Invalid annotation @org.osoa.sca.annotations.ConversationID()
>  is found on private java.lang.String
>  
> org.apache.tuscany.sca.vtest.javaapi.annotations.scope.impl.IServiceImpl.conversationId
>
>  Is it a spec or implementation error?
>
>  Thanks
>  Gilbert
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

RE: Tutorial marketplace scenario ready

[Antollini, Mario]

Comments in-line...

Mario

-Original Message-
From: Jean-Sebastien Delfino [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 15, 2008 6:17 AM
To: tuscany-dev@ws.apache.org
Subject: Re: Tutorial marketplace scenario ready

Antollini, Mario wrote:
>> I have finished coding the tutorial marketplace scenario.
>>
>> I have attached all the necessary files in
>> https://issues.apache.org/jira/browse/TUSCANY-2224
>>  
>
> Mario, that looks pretty good, I just got it working :)
>
> One minor comment:
>
> MarketCatalogImpl could be simplified a bit to call   each catalog
once 
> instead of twice.

OK, I can do it for sure. I did not focus on having an efficient
MarketCatalog implementation. But you are right, I need to fix that.

> And some ideas:
>
> - We could add more catalogs to the list (a local one, the Web service

> ones, and the EJB catalog running on Geronimo) to really leverage the 
> reference with multiplicity 0..n. We'd just need to change the
contents 
> of the different catalogs (for example have fruits/vegetables from 
> different places).
>
> That raises an interesting question about the mix of bindings that can

> be used on a reference with multiplicity 0..n. Can different targets
use 
> different bindings or do they have to all use the same binding? I
think 
> it's worth investigating.

I am glad that you brought this up. Actually, I struggled with this many
hours. At first, I tried to do what you suggested (having heterogeneous
bindings for the catalog reference). I wanted the Market catalog to bind
to the Fruit catalog locally (an internal component) and the Vegetables
one through web services. I tried very hard, but I did not manage to get
it working. I tried different approaches but none worked. Therefore I
decided to use bind to both the fruits and vegetables catalog through
web services (this worked right away).

Do you think this heterogeneous binding issue could be a Tuscany issue?


> - Use standalone  elements in a different .composite file in a 
> different contribution to wire the goodsCatalog reference to the
catalogs.

> IMO this is a typical scenario where people want to add catalogs
without 
> changing the market contribution which has already been installed in
the 
> domain.

I tried with the  element as well but it did not work either.
However, I did not try with different composite files. Can you give me
more details about this, please?

> - Another idea, add a Web Service binding to your StoreMarket catalog 
> component, add a markup to the prices, and that makes it a broker :)

Do you mean to expose the marketplace as a service using web services?

> Thoughts?
> -- 
> Jean-Sebastien

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


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

Should we move to SDO 1.1-incubating version for SCA Java?

[Raymond Feng]

Hi,

Now the SDO 1.1-incubating has been released. Should we adjust the pom.xml 
in SCA Java to reference this release?


ATM, we have SDO 1.0-incubating-SNAPSHOT in trunk. And SCA projects either 
reference SDO 1.0-incubating or 1.0-incubating-SNAPSHOT. I think it's better 
to have SCA depends on a released SDO version consistently across the 
modules. What do you think?


Thanks,
Raymond 



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

Re: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Jean-Sebastien Delfino]

Giorgio Zoppi wrote:

2008/4/15, Raymond Feng <[EMAIL PROTECTED]>:

I'm changing the subject to avoid hijacking the [VOTE] thread.



I as user, dislike requiring the last java version, why should i
upgrade it, when all
my programs works?
So the first choice is not an option for me.

Ciao,
Giorgio.
---


Good news :) it works with older JDKs too. I'm using 1.6.0_02 and I just 
need to place the correct JAXB JARs in the lib endorsed directory.


--
Jean-Sebastien

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

JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Jean-Sebastien Delfino]

Mike Edwards wrote:

Luciano Resende wrote:
Please review and vote on the 1.2 release artifacts of Tuscany SCA for 
Java.


The artifacts are available for review at:
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/

This includes the signed binary and source distributions, the RAT report,
and the Maven staging repository.

The eclipse updatesite for the Tuscany Eclipse plugins is available at:
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/

The release tag is available at :
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/


Looks OK to me, here is my +1.


Luciano,

Sorry to spoil the party, but I run into a problem running the Tutorial 
following the instructions in the README.


So I install the apache-tuscany-sca-1.2-incubating.zip and go to the 
/tutorial directory and follow the instructions in the README, starting 
the domain manager:


   cd domain
   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar domain

This seems to run well (no errors reported)

I view the SCA Manager application at:

http://localhost:9990/ui/cloud/

...the various nodes appear as they should.

I try to start the StoreNode, as recommended in the README, but when I 
select the Start button, I get an error, with an exception trace in the 
command window running the SCA server, which starts with:


15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet /processes/* threw exception
java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap 
classloader, but this RI (from 
jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
axb-impl-2.1.6.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/)



...followed by the usual long exception trace


Sounds like a configuration error, with the wrong level of JAXB 
libraries being used.


Is this just me - or is this a problem with the build?



You'll get this with some of the other samples too I think, if you use 
JDK 6 and don't place JAXB 2.1 in the lib/endorsed directory of your JRE.


Try to do what the the error message is asking you to do :)
--
Jean-Sebastien

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

Re: Mirror of release artifacts

[Luciano Resende]

How do we get stats from the number of downloads when using mirros ?

On Tue, Apr 15, 2008 at 7:21 AM, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 2:20 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
>  > WIth the changes to how the Incubator release artifacts get distributed
>  > via
>  > mirrors now I understood we were supposed to have our website download
>  > pages
>  > use a script accessing the mirrors.  Looking back at the  SCA 1.1 download
>  > page change history it did at one point do that (r17) but then it got
>  > changed back to the non-script approach. Anyone know why? Are there some
>  > issues with using the script/mirrors?
>  >
>  >   ...ant
>
>
>  Hi
>
>  Distribution mirroring is part of incubator release best practice [1] so we
>  should try and put this back in if we can. Happy to help to make this work
>  if anyone can identify what the original issue was. If we can't identify a
>  specific issue I would go for going back to the links from r17.
>
>  Regards
>
>  Simon
>
>
>  [1]
>  
> http://incubator.apache.org/guides/releasemanagement.html#distribution-mirroring
>



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

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

Got WARNING if @Context is used to annotate a setter method

[Gilbert Kwan]

I am curious why I got following warnings when @Context is used to
annotate a setter method:

Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/requestContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/componentContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/requestContext
Apr 15, 2008 11:45:18 AM
org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
problem
WARNING: No type specified on component property: BComponent/componentContext

public RequestContext requestContext;
public ComponentContext componentContext;

@Context
public void setComponentContext(ComponentContext componentContext) {
this.componentContext = componentContext;
}

@Context
public void setRequestContext(RequestContext requestContext) {
this.requestContext = requestContext;
}

If @Context is used to annotate a class field, there is no warning.

Regards
Gilbert

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

Re: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Giorgio Zoppi]

2008/4/15, Raymond Feng <[EMAIL PROTECTED]>:
> I'm changing the subject to avoid hijacking the [VOTE] thread.


I as user, dislike requiring the last java version, why should i
upgrade it, when all
my programs works?
So the first choice is not an option for me.

Ciao,
Giorgio.
---
"The only people for me are the mad ones, the ones who are mad to
live, mad to talk, mad to be saved. The ones who never yawn or say a
commonplace thing, but burn, burn, burn like fabulous yellow roman
candles exploding like spiders across the stars"
On The Road - Jack Kerouac

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

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Simon Laws]

On Tue, Apr 15, 2008 at 4:50 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> It's related to JDK 6 which ships a version of JAXB impl by itself. Up to
> JDK 6 Update 3, the JDK ships with JAX-WS 2.0 (which includes JAXB 2.0), but
> Tuscany requires JAXB 2.1. There are two possible solutions to this problem:
>
> 1) Upgrade your JDK to 1.6.0_04 or above, which will include JAX-WS (and
> JAXB) 2.1
> 2) Copy the version 2.1 jaxb-api.jar or jaxws-api.jar (you can probably
> find them in your local maven repo) to /lib/endorsed to override
> the API jars that ship with the JDK
> 3) Use the -Djava.endorsed.dir= to
> override the JAXB from JDK 6.
>
> We need to add this to our FAQ or release note.
>
> Thanks,
> Raymond
>
> --
> From: "Simon Laws" <[EMAIL PROTECTED]>
> Sent: Tuesday, April 15, 2008 7:38 AM
> To: ; <[EMAIL PROTECTED]>
> Subject: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)
>
>
>  On Tue, Apr 15, 2008 at 3:31 PM, ant elder <[EMAIL PROTECTED]> wrote:
> >
> >  On Tue, Apr 15, 2008 at 3:19 PM, Mike Edwards <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > Luciano Resende wrote:
> > > >
> > > > > Please review and vote on the 1.2 release artifacts of Tuscany SCA
> > > > > for
> > > > > Java.
> > > > >
> > > > > The artifacts are available for review at:
> > > > > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/
> > > 
> > > 
> > > > >
> > > > > This includes the signed binary and source distributions, the RAT
> > > > > report,
> > > > > and the Maven staging repository.
> > > > >
> > > > > The eclipse updatesite for the Tuscany Eclipse plugins is
> > > available
> > > at:
> > > > > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/
> > > 
> > > 
> > > > >
> > > > > The release tag is available at :
> > > > >
> > >
> > > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
> > > > >
> > > > >
> > > > > Looks OK to me, here is my +1.
> > > > >
> > > > >  Luciano,
> > > >
> > > > Sorry to spoil the party, but I run into a problem running the
> > > Tutorial
> > > > following the instructions in the README.
> > > >
> > > > So I install the apache-tuscany-sca-1.2-incubating.zip and go to the
> > > > /tutorial directory and follow the instructions in the README,
> > > starting
> > > the
> > > > domain manager:
> > > >
> > > >   cd domain
> > > >   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar
> > > domain
> > > >
> > > > This seems to run well (no errors reported)
> > > >
> > > > I view the SCA Manager application at:
> > > >
> > > > http://localhost:9990/ui/cloud/
> > > >
> > > > ...the various nodes appear as they should.
> > > >
> > > > I try to start the StoreNode, as recommended in the README, but when
> > > I
> > > > select the Start button, I get an error, with an exception trace in
> > > the
> > > > command window running the SCA server, which starts with:
> > > >
> > > > 15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve
> > > invoke
> > > > SEVERE: Servlet.service() for servlet /processes/* threw exception
> > > > java.lang.LinkageError: JAXB 2.0 API is being loaded from the
> > > bootstrap
> > > > classloader, but this RI (from
> > > > jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
> > > >
> > > axb-impl-2.1.6.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/)
> > > >
> > > >
> > > > ...followed by the usual long exception trace
> > > >
> > > >
> > > > Sounds like a configuration error, with the wrong level of JAXB
> > > libraries
> > > > being used.
> > > >
> > > > Is this just me - or is this a problem with the build?
> > > >
> > > >
> > > > Yours,  Mike.
> > > >
> > >
> > > I've just run through what you have described and it works ok for me.
> > > Could
> > > it be a java level thing, which JDK are you using? I have:
> > > java -version
> > > java version "1.5.0_10"
> > > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
> > > Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)
> > >
> > >  ...ant
> > >
> > >
> > I just ran it too and it works for me...
> >
> > WinXp SP2
> > java version "1.5.0"
> > Java(TM) 2 Runtime Environment, Standard Edition (build
> > pwi32dev-20070201
> > (SR4))
> >
> > IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
> > j9vmwi3223-2007020
> > 1 (JIT enabled)
> > J9VM - 20070131_11312_lHdSMR
> > JIT  - 20070109_18

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Raymond Feng]

It's related to JDK 6 which ships a version of JAXB impl by itself. Up to 
JDK 6 Update 3, the JDK ships with JAX-WS 2.0 (which includes JAXB 2.0), but 
Tuscany requires JAXB 2.1. There are two possible solutions to this problem:


1) Upgrade your JDK to 1.6.0_04 or above, which will include JAX-WS (and 
JAXB) 2.1
2) Copy the version 2.1 jaxb-api.jar or jaxws-api.jar (you can probably find 
them in your local maven repo) to /lib/endorsed to override the 
API jars that ship with the JDK
3) Use the -Djava.endorsed.dir= to 
override the JAXB from JDK 6.


We need to add this to our FAQ or release note.

Thanks,
Raymond

--
From: "Simon Laws" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 7:38 AM
To: ; <[EMAIL PROTECTED]>
Subject: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)


On Tue, Apr 15, 2008 at 3:31 PM, ant elder <[EMAIL PROTECTED]> wrote:


On Tue, Apr 15, 2008 at 3:19 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
> > Please review and vote on the 1.2 release artifacts of Tuscany SCA 
> > for

> > Java.
> >
> > The artifacts are available for review at:
> > 
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/

> >
> > This includes the signed binary and source distributions, the RAT
> > report,
> > and the Maven staging repository.
> >
> > The eclipse updatesite for the Tuscany Eclipse plugins is available
at:
> > 
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/

> >
> > The release tag is available at :
> >
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
> >
> >
> > Looks OK to me, here is my +1.
> >
> >  Luciano,
>
> Sorry to spoil the party, but I run into a problem running the Tutorial
> following the instructions in the README.
>
> So I install the apache-tuscany-sca-1.2-incubating.zip and go to the
> /tutorial directory and follow the instructions in the README, starting
the
> domain manager:
>
>   cd domain
>   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar
domain
>
> This seems to run well (no errors reported)
>
> I view the SCA Manager application at:
>
> http://localhost:9990/ui/cloud/
>
> ...the various nodes appear as they should.
>
> I try to start the StoreNode, as recommended in the README, but when I
> select the Start button, I get an error, with an exception trace in the
> command window running the SCA server, which starts with:
>
> 15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve
invoke
> SEVERE: Servlet.service() for servlet /processes/* threw exception
> java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap
> classloader, but this RI (from
> jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
> axb-impl-2.1.6.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/)
>
>
> ...followed by the usual long exception trace
>
>
> Sounds like a configuration error, with the wrong level of JAXB
libraries
> being used.
>
> Is this just me - or is this a problem with the build?
>
>
> Yours,  Mike.
>

I've just run through what you have described and it works ok for me.
Could
it be a java level thing, which JDK are you using? I have:
java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)

  ...ant



I just ran it too and it works for me...

WinXp SP2
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201
(SR4))

IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-2007020
1 (JIT enabled)
J9VM - 20070131_11312_lHdSMR
JIT  - 20070109_1805ifx1_r8
GC   - 200701_09)
JCL  - 20070131

Simon



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

[jira] Closed: (TUSCANY-2221) New tests for Java @Scope annotaion

[Kevin Williams (JIRA)]

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

Kevin Williams closed TUSCANY-2221.
---

   Resolution: Fixed
Fix Version/s: Java-SCA-Next

> New tests for Java @Scope annotaion 
> 
>
> Key: TUSCANY-2221
> URL: https://issues.apache.org/jira/browse/TUSCANY-2221
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2221.test.patch, vtest.scope.zip
>
>
> New tests for Java Common Annotations and APIs Specification of @Scope 
> annotation

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


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

Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Raymond Feng]

I'm changing the subject to avoid hijacking the [VOTE] thread.

Thanks,
Raymond
--
From: "Raymond Feng" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 8:50 AM
To: 
Subject: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

It's related to JDK 6 which ships a version of JAXB impl by itself. Up to 
JDK 6 Update 3, the JDK ships with JAX-WS 2.0 (which includes JAXB 2.0), 
but Tuscany requires JAXB 2.1. There are two possible solutions to this 
problem:


1) Upgrade your JDK to 1.6.0_04 or above, which will include JAX-WS (and 
JAXB) 2.1
2) Copy the version 2.1 jaxb-api.jar or jaxws-api.jar (you can probably 
find them in your local maven repo) to /lib/endorsed to 
override the API jars that ship with the JDK
3) Use the -Djava.endorsed.dir= to 
override the JAXB from JDK 6.


We need to add this to our FAQ or release note.

Thanks,
Raymond

--
From: "Simon Laws" <[EMAIL PROTECTED]>
Sent: Tuesday, April 15, 2008 7:38 AM
To: ; <[EMAIL PROTECTED]>
Subject: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)


On Tue, Apr 15, 2008 at 3:31 PM, ant elder <[EMAIL PROTECTED]> wrote:


On Tue, Apr 15, 2008 at 3:19 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
> > Please review and vote on the 1.2 release artifacts of Tuscany SCA 
> > for

> > Java.
> >
> > The artifacts are available for review at:
> > 
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/

> >
> > This includes the signed binary and source distributions, the RAT
> > report,
> > and the Maven staging repository.
> >
> > The eclipse updatesite for the Tuscany Eclipse plugins is available
at:
> > 
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/

> >
> > The release tag is available at :
> >
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
> >
> >
> > Looks OK to me, here is my +1.
> >
> >  Luciano,
>
> Sorry to spoil the party, but I run into a problem running the 
> Tutorial

> following the instructions in the README.
>
> So I install the apache-tuscany-sca-1.2-incubating.zip and go to the
> /tutorial directory and follow the instructions in the README, 
> starting

the
> domain manager:
>
>   cd domain
>   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar
domain
>
> This seems to run well (no errors reported)
>
> I view the SCA Manager application at:
>
> http://localhost:9990/ui/cloud/
>
> ...the various nodes appear as they should.
>
> I try to start the StoreNode, as recommended in the README, but when I
> select the Start button, I get an error, with an exception trace in 
> the

> command window running the SCA server, which starts with:
>
> 15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve
invoke
> SEVERE: Servlet.service() for servlet /processes/* threw exception
> java.lang.LinkageError: JAXB 2.0 API is being loaded from the 
> bootstrap

> classloader, but this RI (from
> jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
> axb-impl-2.1.6.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/)
>
>
> ...followed by the usual long exception trace
>
>
> Sounds like a configuration error, with the wrong level of JAXB
libraries
> being used.
>
> Is this just me - or is this a problem with the build?
>
>
> Yours,  Mike.
>

I've just run through what you have described and it works ok for me.
Could
it be a java level thing, which JDK are you using? I have:
java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)

  ...ant



I just ran it too and it works for me...

WinXp SP2
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201
(SR4))

IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-2007020
1 (JIT enabled)
J9VM - 20070131_11312_lHdSMR
JIT  - 20070109_1805ifx1_r8
GC   - 200701_09)
JCL  - 20070131

Simon



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

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

[Mark Combellack]

Hi,

 

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

 

 

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

java.lang.NoClassDefFoundError

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

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

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

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

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

  at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvo
ker.invoke(JavaImplementationInvoker.java:109)

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

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

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

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

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

  at $Proxy141.getGreetings(Unknown Source)

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

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

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

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

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

  at junit.framework.TestCase.runTest(TestCase.java:168)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

java.lang.NoClassDefFoundError

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

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

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

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

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

  at
org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTargetInvoker.invo
keMethod(OSGiTargetInvoker.java:171)

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

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

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

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

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

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

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

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

  at $Proxy141.getGreetings(Unknow

Re: How do you plug in validation monitoring?

[Simon Laws]

On Tue, Apr 15, 2008 at 3:59 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon,
>
> I was wondering if i can cook up some validation test cases if they do not
> exist. Or should we wait until the monitor issue is resolved ?
>
> Hasan
>
> On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
> >
> > I dont think using an underlying tuscany jdk logger would be useful to
> > plugins as they may not want to log, rather show it somewhere else such
> as
> > console etc. Tuscany can use an underlying logger in it's own monitor (
> as
> > it uses today). But i think the first approach of using a monitor is
> better
> > along with the condition that it be made more usable by the plugins by
> > giving them greater control.
> >
> > Another point is that tuscany should use ResourceBundle for validation
> > messages as well. I dont think this is being done today.
> >
> > regards
> > Hasan
> >
> >
> > On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <[EMAIL PROTECTED]
> >
> > > wrote:
> > >
> > > >
> > > >
> > > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > > Hi Simon,
> > > > >
> > > > > I am on revision 634808. The ContributionServiceImpl has changed
> > > since
> > > > > then,
> > > > > and with the one that i have, it would lead through the
> > > > > CompositeProcessor
> > > > > instead of the CompositeDocumentProcessor. Hence the difference in
> > > > > exceptions..
> > > > >
> > > > > Also, dont you think that with the error that you got should throw
> > > an
> > > > > exception with schema validation, rather than just a warning?
> > > > >
> > > > > Hasan
> > > > >
> > > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > > [EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]
> >
> > > > > wrote:
> > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thank you for the good information. First up i am trying to
> > > verify
> > > > > > whether
> > > > > > > the schema validation works when we point to our schemas. Can
> > > you
> > > > > let me
> > > > > > > know what is a simple error that i can introduce so that i can
> > > > > verify
> > > > > > > this?
> > > > > > > I tried doing this to my composite file (In block red):
> > > > > > >
> > > > > > >  
> > > > > > > > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > > > >**
> > > > > > >
> > > > > > >
> > > > > > >  
> > > > > > >
> > > > > > > This resulted in the following exception, but i think this is
> > > part
> > > > > of
> > > > > > the
> > > > > > > validation done by artifact processor and would result even if
> > > we
> > > > > > comment
> > > > > > > out the schema validation.
> > > > > > >
> > > > > > >
> > > > >
> > > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > > > > > > Unexpected  element found. It should appear inside a
> > > > > 
> > > > > > or
> > > > > > >  element
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> > > > > > >at
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> > > > > > >at
> > > > > > >
> > >

Classloading info

[Simon Laws]

I've been trying to catch up where we are with class loading after the
flurry of mails and wiki entries a few months ago, for example,  [1]-[6].
I've started summarizing for my own benefit [7] but hope that I can turn
this into some documentation at some point when we get the code sorted. I
don't guarantee that these notes are accurate at the moment. If you want a
little light entertainment maybe you could take a look at them, fix errors
and omissions and turn this into a more accurate statement of where we want
to be.

Simon

 [1]
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28235.html
[2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg25100.html
[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg24774.html
[4]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading+in+Tuscany+SCA+Java
[5]
http://cwiki.apache.org/confluence/download/attachments/68801/classloader-dependencies.png
[6]
http://cwiki.apache.org/confluence/download/attachments/68801/desired-classloader.png
[7] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Classloading

Re: Apache Tuscany committer status reaffirmation

[ant elder]

Thanks for replying Rajith and thanks for your participation, our JMS
binding is still based on the code you wrote. Be great to get support for
qpid/amqp sometime so when ever you do get time just say and i'm sure
there'll be no barriers to your rejoining.

   ...ant

On Mon, Apr 14, 2008 at 5:31 PM, Rajith Attapattu <
[EMAIL PROTECTED]> wrote:

> Ant,
>
> I have been inactive for the last 12 months or so.
> The Qpid project is taking so much of my time and judging by the past
> 12 months I think I will be unable to devote enough quality time to
> deserve comittership.
> So I would appreciate if you can revoke it.
>
> I do have a plan to jump back in and update the JMS binding (if
> someone hasn't done yet) and to do an AMQP binding.
> Not sure when it is, but when that happens perhaps I may do enough
> work to earn comittership again.
> But until that happens please take me off the list.
>
> I wish the Tuscany community all the best and hopefully will start
> working again with you guys.
>
> Regards,
>
> Rajith
>
>
>
> On Sat, Apr 12, 2008 at 5:23 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > You are receiving this email because you are listed as an Apache
> >  Tuscany committer. Tuscany is looking to graduate in the near future
> >  and following Apache Incubator practice is cleaning up the committer
> >  list.  Tuscany has 35 committers listed on the status file some of
> >  those have left and some were just listed there when the original
> >  proposal was accepted and have never even once committed anything.
> >  We've decided any one who has interacted with the project within the
> >  last 12 months will automatically remain a committer, anyone else will
> >  need to reply to this email to retain their committer status.
> >
> >  These are the committers who've participated in the last 12 months and
> >  will automatically retain their committer status:
> >
> > adrianocrestani Adriano Crestani
> > amita   Amita Vadhavkar
> > ajborleyAndrew Borley
> > antelderAnt Elder
> > bjohnsonBrady Johnson
> > dkulp   Dan Kulp
> > frankb  Frank Budinsky
> > fuhwei  Fuhwei Lwo
> > giorgio Giorgio Zoppi
> > isilval Ignacio Silva-Lepe
> > jsdelfino   Jean-Sebastien Delfino
> > kelvingoodson   Kelvin Goodson
> > kwilliams   Kevin Williams
> > lresendeLuciano Resende
> > mcombellack Mark Combellack
> > myoder  Michael Yoder
> > edwardsmj   Mike Edwards
> > nashSimon Nash
> > rsivaramRajini Sivaram
> > rfeng   Raymond Feng
> > robbinspg   Pete Robbins
> > slaws   Simon Laws
> > svkrish Venkata Krishnan
> >
> >  So, if you are not on that list but would like to retain your Tuscany
> >  committer status please reply to this email and let us know about how
> >  you would like to be involved with Tuscany. Also, if you are on that
> >  list but no longer want to stay a committer once Tuscany graduates you
> >  can also reply to this email and we'll remove your name.
> >
> >  Many thanks,
> >  The Apache Tuscany PPMC
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> http://rajith.2rlabs.com/
>

[jira] Closed: (TUSCANY-2199) Tests for @Reference annotation

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2199.
--

Resolution: Fixed

So it is, in r644938.

> Tests for @Reference annotation
> ---
>
> Key: TUSCANY-2199
> URL: https://issues.apache.org/jira/browse/TUSCANY-2199
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Attachments: TUSCANY-2199.multiplicity.test.patch
>
>
> Placeholder for tracking additions to the @Reference vtests

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


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

[jira] Closed: (TUSCANY-2195) Test cases for ComponentContext API

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2195.
--

Resolution: Fixed

Applied, many thanks for the code

> Test cases for ComponentContext API
> ---
>
> Key: TUSCANY-2195
> URL: https://issues.apache.org/jira/browse/TUSCANY-2195
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Attachments: ComponentContext.zip, ComponentContext20080404.zip, 
> ComponentContextJira2195.patch
>
>
> Contributions for ComponentContext API testing can be attached here

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


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

[jira] Commented: (TUSCANY-2199) Tests for @Reference annotation

[Gilbert Kwan (JIRA)]

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

Gilbert Kwan commented on TUSCANY-2199:
---

I found the patch already applied.

> Tests for @Reference annotation
> ---
>
> Key: TUSCANY-2199
> URL: https://issues.apache.org/jira/browse/TUSCANY-2199
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Attachments: TUSCANY-2199.multiplicity.test.patch
>
>
> Placeholder for tracking additions to the @Reference vtests

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


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

Re: How do you plug in validation monitoring?

[Hasan Muhammad]

Hi Simon,

I was wondering if i can cook up some validation test cases if they do not
exist. Or should we wait until the monitor issue is resolved ?

Hasan

On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon,
>
> I dont think using an underlying tuscany jdk logger would be useful to
> plugins as they may not want to log, rather show it somewhere else such as
> console etc. Tuscany can use an underlying logger in it's own monitor ( as
> it uses today). But i think the first approach of using a monitor is better
> along with the condition that it be made more usable by the plugins by
> giving them greater control.
>
> Another point is that tuscany should use ResourceBundle for validation
> messages as well. I dont think this is being done today.
>
> regards
> Hasan
>
>
> On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > >
> > >
> > > On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > I am on revision 634808. The ContributionServiceImpl has changed
> > since
> > > > then,
> > > > and with the one that i have, it would lead through the
> > > > CompositeProcessor
> > > > instead of the CompositeDocumentProcessor. Hence the difference in
> > > > exceptions..
> > > >
> > > > Also, dont you think that with the error that you got should throw
> > an
> > > > exception with schema validation, rather than just a warning?
> > > >
> > > > Hasan
> > > >
> > > > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <
> > [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > > wrote:
> > > > >
> > > > > > Hi Simon,
> > > > > >
> > > > > > Thank you for the good information. First up i am trying to
> > verify
> > > > > whether
> > > > > > the schema validation works when we point to our schemas. Can
> > you
> > > > let me
> > > > > > know what is a simple error that i can introduce so that i can
> > > > verify
> > > > > > this?
> > > > > > I tried doing this to my composite file (In block red):
> > > > > >
> > > > > >  
> > > > > > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > > > >**
> > > > > >
> > > > > >
> > > > > >  
> > > > > >
> > > > > > This resulted in the following exception, but i think this is
> > part
> > > > of
> > > > > the
> > > > > > validation done by artifact processor and would result even if
> > we
> > > > > comment
> > > > > > out the schema validation.
> > > > > >
> > > > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > > > > > Unexpected  element found. It should appear inside a
> > > > 
> > > > > or
> > > > > >  element
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
> > > > > >at
> > > > > >
> > > > > >
> > > > >
> > > >
> > com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
> >

[jira] Commented: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2165:


Thanks for the lates patch, I've applied it locally but now running the test i 
get a failure:

Tests run: 7, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 1.546 sec <<< 
FAILURE!
atReference2(org.apache.tuscany.sca.vtest.javaapi.annotations.reference.ReferenceAnnotationTestCase)
  Time elapsed: 0 sec  <<< FAILURE!
java.lang.AssertionError: getB5Name expected to fail with NPE
at org.junit.Assert.fail(Assert.java:69)
at 
org.apache.tuscany.sca.vtest.javaapi.annotations.reference.ReferenceAnnotationTestCase.atReference2(ReferenceAnnotationTestCase.java:122)

Is that expected?





> Java runtime should inject service references to field with common name in 
> absence of @Reference 
> -
>
> Key: TUSCANY-2165
> URL: https://issues.apache.org/jira/browse/TUSCANY-2165
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
> Attachments: TUSCANY-2165-revised-test.patch, TUSCANY-2165.patch
>
>
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> The vTest:  
> org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 
> demonstrates this issue

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


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

[jira] Commented: (TUSCANY-2195) Test cases for ComponentContext API

[Yee-Kang Chang (JIRA)]

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

Yee-Kang Chang commented on TUSCANY-2195:
-

Please apply ComponentContextJira2195.patch.  Thank you!

> Test cases for ComponentContext API
> ---
>
> Key: TUSCANY-2195
> URL: https://issues.apache.org/jira/browse/TUSCANY-2195
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Attachments: ComponentContext.zip, ComponentContext20080404.zip, 
> ComponentContextJira2195.patch
>
>
> Contributions for ComponentContext API testing can be attached here

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


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

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Simon Laws]

On Tue, Apr 15, 2008 at 3:31 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Tue, Apr 15, 2008 at 3:19 PM, Mike Edwards <
> [EMAIL PROTECTED]> wrote:
>
> > Luciano Resende wrote:
> >
> > > Please review and vote on the 1.2 release artifacts of Tuscany SCA for
> > > Java.
> > >
> > > The artifacts are available for review at:
> > > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/
> 
> > >
> > > This includes the signed binary and source distributions, the RAT
> > > report,
> > > and the Maven staging repository.
> > >
> > > The eclipse updatesite for the Tuscany Eclipse plugins is available
> at:
> > > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/
> 
> > >
> > > The release tag is available at :
> > >
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
> > >
> > >
> > > Looks OK to me, here is my +1.
> > >
> > >  Luciano,
> >
> > Sorry to spoil the party, but I run into a problem running the Tutorial
> > following the instructions in the README.
> >
> > So I install the apache-tuscany-sca-1.2-incubating.zip and go to the
> > /tutorial directory and follow the instructions in the README, starting
> the
> > domain manager:
> >
> >   cd domain
> >   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar
> domain
> >
> > This seems to run well (no errors reported)
> >
> > I view the SCA Manager application at:
> >
> > http://localhost:9990/ui/cloud/
> >
> > ...the various nodes appear as they should.
> >
> > I try to start the StoreNode, as recommended in the README, but when I
> > select the Start button, I get an error, with an exception trace in the
> > command window running the SCA server, which starts with:
> >
> > 15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve
> invoke
> > SEVERE: Servlet.service() for servlet /processes/* threw exception
> > java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap
> > classloader, but this RI (from
> > jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
> > axb-impl-2.1.6.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/)
> >
> >
> > ...followed by the usual long exception trace
> >
> >
> > Sounds like a configuration error, with the wrong level of JAXB
> libraries
> > being used.
> >
> > Is this just me - or is this a problem with the build?
> >
> >
> > Yours,  Mike.
> >
>
> I've just run through what you have described and it works ok for me.
> Could
> it be a java level thing, which JDK are you using? I have:
> java -version
> java version "1.5.0_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)
>
>   ...ant
>

I just ran it too and it works for me...

WinXp SP2
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build pwi32dev-20070201
(SR4))

IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-2007020
1 (JIT enabled)
J9VM - 20070131_11312_lHdSMR
JIT  - 20070109_1805ifx1_r8
GC   - 200701_09)
JCL  - 20070131

Simon

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[ant elder]

On Tue, Apr 15, 2008 at 3:19 PM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Luciano Resende wrote:
>
> > Please review and vote on the 1.2 release artifacts of Tuscany SCA for
> > Java.
> >
> > The artifacts are available for review at:
> > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/
> >
> > This includes the signed binary and source distributions, the RAT
> > report,
> > and the Maven staging repository.
> >
> > The eclipse updatesite for the Tuscany Eclipse plugins is available at:
> > http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/
> >
> > The release tag is available at :
> > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
> >
> >
> > Looks OK to me, here is my +1.
> >
> >  Luciano,
>
> Sorry to spoil the party, but I run into a problem running the Tutorial
> following the instructions in the README.
>
> So I install the apache-tuscany-sca-1.2-incubating.zip and go to the
> /tutorial directory and follow the instructions in the README, starting the
> domain manager:
>
>   cd domain
>   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar domain
>
> This seems to run well (no errors reported)
>
> I view the SCA Manager application at:
>
> http://localhost:9990/ui/cloud/
>
> ...the various nodes appear as they should.
>
> I try to start the StoreNode, as recommended in the README, but when I
> select the Start button, I get an error, with an exception trace in the
> command window running the SCA server, which starts with:
>
> 15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve invoke
> SEVERE: Servlet.service() for servlet /processes/* threw exception
> java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap
> classloader, but this RI (from
> jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
> axb-impl-2.1.6.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/)
>
>
> ...followed by the usual long exception trace
>
>
> Sounds like a configuration error, with the wrong level of JAXB libraries
> being used.
>
> Is this just me - or is this a problem with the build?
>
>
> Yours,  Mike.
>

I've just run through what you have described and it works ok for me. Could
it be a java level thing, which JDK are you using? I have:
java -version
java version "1.5.0_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode)

   ...ant

[jira] Updated: (TUSCANY-2218) Endpoint URI resolution precedence for binding.ws reference is incorrect

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2218:
-

Attachment: TUSCANY-2218.patch

TUSCANY-2218.patch: Fixes the precedence as per spec.

> Endpoint URI resolution precedence for binding.ws reference is incorrect
> 
>
> Key: TUSCANY-2218
> URL: https://issues.apache.org/jira/browse/TUSCANY-2218
> Project: Tuscany
>  Issue Type: Bug
>Affects Versions: Java-SCA-1.0
>Reporter: Lou Amodeo
>Assignee: Vamsavardhana Reddy
> Attachments: TUSCANY-2218.patch
>
>
> I believe the order of Endpoint URI resolution precedence is incorrect for 
> binding.ws references.   What I am seeing is that the uri attribute is taking 
> precedence over the location specified in the WSDL.  The spec indicates that 
> the endpoint in the WSDL should take highest precedence.   
> Web Service Binding Spec
> 2.1.1 Endpoint URI resolution
> 71 The rules for resolving the URI at which an SCA service is hosted, or SCA 
> reference targets,
> 72 when used with binding.ws (in precedence order) are:
> 73 1. The URIs in the endpoint(s) of the referenced WSDL
> 74 or
> 75 The URI specified by the wsa:Address element of the wsa:EndpointReference,
> 76 2. The explicitly stated URI in the "uri" attribute of the binding.ws 
> element, which may be
> 77 relative,
> 78 3. The implicit URI as defined by the Assembly specification
> In Axis2ServiceClient getPortLocation looks for uri first and returns it 
> ahead of wsdl location if present. 
>  protected EndpointReference getPortLocationEPR(WebServiceBinding binding) {
>   
> String ep = binding.getURI();  WAS specific
> if (ep == null && binding.getPort() != null) {
> List wsdlPortExtensions = 
> binding.getPort().getExtensibilityElements();
> for (final Object extension : wsdlPortExtensions) {
> if (extension instanceof SOAPAddress) {
> ep = ((SOAPAddress)extension).getLocationURI();
> break;
> }
> if (extension instanceof SOAP12Address) {
> SOAP12Address address = (SOAP12Address)extension;
> ep = address.getLocationURI();
> break;
> }
> }
> }
> return ep == null || "".equals(ep) ? null : new EndpointReference(ep);
> }

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


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

Re: Mirror of release artifacts

[Simon Laws]

On Tue, Apr 15, 2008 at 2:20 PM, ant elder <[EMAIL PROTECTED]> wrote:

> WIth the changes to how the Incubator release artifacts get distributed
> via
> mirrors now I understood we were supposed to have our website download
> pages
> use a script accessing the mirrors.  Looking back at the  SCA 1.1 download
> page change history it did at one point do that (r17) but then it got
> changed back to the non-script approach. Anyone know why? Are there some
> issues with using the script/mirrors?
>
>   ...ant


Hi

Distribution mirroring is part of incubator release best practice [1] so we
should try and put this back in if we can. Happy to help to make this work
if anyone can identify what the original issue was. If we can't identify a
specific issue I would go for going back to the links from r17.

Regards

Simon


[1]
http://incubator.apache.org/guides/releasemanagement.html#distribution-mirroring

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Mike Edwards]

Luciano Resende wrote:

Please review and vote on the 1.2 release artifacts of Tuscany SCA for Java.

The artifacts are available for review at:
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/

This includes the signed binary and source distributions, the RAT report,
and the Maven staging repository.

The eclipse updatesite for the Tuscany Eclipse plugins is available at:
http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/

The release tag is available at :
http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/


Looks OK to me, here is my +1.


Luciano,

Sorry to spoil the party, but I run into a problem running the Tutorial 
following the instructions in the README.


So I install the apache-tuscany-sca-1.2-incubating.zip and go to the 
/tutorial directory and follow the instructions in the README, starting 
the domain manager:


   cd domain
   java -jar ../../modules/tuscany-node2-launcher-1.2-incubating.jar domain

This seems to run well (no errors reported)

I view the SCA Manager application at:

http://localhost:9990/ui/cloud/

...the various nodes appear as they should.

I try to start the StoreNode, as recommended in the README, but when I 
select the Start button, I get an error, with an exception trace in the 
command window running the SCA server, which starts with:


15-Apr-2008 15:09:58 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet /processes/* threw exception
java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap 
classloader, but this RI (from 
jar:file:/C:/Tuscany_1_2/tuscany-sca-1.2-incubating/lib/j
axb-impl-2.1.6.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/)



...followed by the usual long exception trace


Sounds like a configuration error, with the wrong level of JAXB 
libraries being used.


Is this just me - or is this a problem with the build?


Yours,  Mike.

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

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

[Mark Combellack (JIRA)]

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

Mark Combellack resolved TUSCANY-2228.
--

Resolution: Fixed

Added unti test for JavaPropertyValueObjectFactory in SVN revision 648256.

Marking bug as fixed.

> Setting an Integer Property with a non-number throws NumberFormatException - 
> but for which Property?
> 
>
> Key: TUSCANY-2228
> URL: https://issues.apache.org/jira/browse/TUSCANY-2228
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Affects Versions: Java-SCA-Next
> Environment: SVN trunk revision 648161
> Linux
>Reporter: Mark Combellack
>Assignee: Mark Combellack
> Fix For: Java-SCA-Next
>
>
> If I define a Property on my Component as type int and then attempt to set 
> the property value in the XML to a non-number (e.g. the String "Hello"), 
> Tuscany will throw the following exception:
> org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
> input string: ""
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
> 
> Caused by: java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:468)
> at java.lang.Integer.parseInt(Integer.java:497)
> at 
> org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
> at 
> org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
> at 
> org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
> at 
> org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
> at 
> org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
> at 
> org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
> The big problem with this exception is that it does not tell you which field 
> is invalid

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


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

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Dave Sowerby]

+1 from me, all looks good and bug as discussed in TUSCANY-2220 is now resolved.

Cheers!

Dave.

On Tue, Apr 15, 2008 at 8:38 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> +1 from me.  Eclipse update is going fine.  Samples are ok.  Could not spot
>  any problems with licenses.
>
>  Luciano, thanks a ton for all the hard work.
>
>  - Venkat
>
>
>  On Mon, Apr 14, 2008 at 3:36 PM, Luciano Resende <[EMAIL PROTECTED]>
>  wrote:
>
>
> > Please review and vote on the 1.2 release artifacts of Tuscany SCA for
>  > Java.
>  >
>  > The artifacts are available for review at:
>  > 
> http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/
>
> >
>  > This includes the signed binary and source distributions, the RAT report,
>  > and the Maven staging repository.
>  >
>  > The eclipse updatesite for the Tuscany Eclipse plugins is available at:
>  > 
> http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/
>
> >
>  > The release tag is available at :
>  > http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
>  >
>  >
>  > Looks OK to me, here is my +1.
>  >
>  > --
>  > Luciano Resende
>  > Apache Tuscany Committer
>  > http://people.apache.org/~lresende 
>
>
> > http://lresende.blogspot.com/
>  >
>  > -
>  > To unsubscribe, e-mail: [EMAIL PROTECTED]
>  > For additional commands, e-mail: [EMAIL PROTECTED]
>  >
>  >
>



-- 
Dave Sowerby MEng MBCS

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

[jira] Commented: (TUSCANY-2199) Tests for @Reference annotation

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2199:


Thanks for the patch Gilbert. Unfortunately it wont apply correctly for me 
complaining that some characters in the patch can't be mapped to Cp1252 
encoding. I suspect an SVN config mismatch, could you check your SVN client 
config matches whats used by Tuscany and reattach a patch based on that? 
There's been some email on the dev list recently about how to do this, see: 
http://apache.markmail.org/message/kydc2535whfhass3



> Tests for @Reference annotation
> ---
>
> Key: TUSCANY-2199
> URL: https://issues.apache.org/jira/browse/TUSCANY-2199
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
> Attachments: TUSCANY-2199.multiplicity.test.patch
>
>
> Placeholder for tracking additions to the @Reference vtests

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


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

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

[Mark Combellack (JIRA)]

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

Mark Combellack commented on TUSCANY-2228:
--

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

The exception now looks like:

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


> Setting an Integer Property with a non-number throws NumberFormatException - 
> but for which Property?
> 
>
> Key: TUSCANY-2228
> URL: https://issues.apache.org/jira/browse/TUSCANY-2228
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Affects Versions: Java-SCA-Next
> Environment: SVN trunk revision 648161
> Linux
>Reporter: Mark Combellack
>Assignee: Mark Combellack
> Fix For: Java-SCA-Next
>
>
> If I define a Property on my Component as type int and then attempt to set 
> the property value in the XML to a non-number (e.g. the String "Hello"), 
> Tuscany will throw the following exception:
> org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
> input string: ""
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
> 
> Caused by: java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:468)
> at java.lang.Integer.parseInt(Integer.java:497)
> at 
> org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
> at 
> org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
> at 
> org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
> at 
> org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
> at 
> org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
> at 
> org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
> The big problem with this exception is that it does not tell you which field 
> is invalid

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

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

[Mark Combellack (JIRA)]

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

Mark Combellack commented on TUSCANY-2228:
--

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

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

> Setting an Integer Property with a non-number throws NumberFormatException - 
> but for which Property?
> 
>
> Key: TUSCANY-2228
> URL: https://issues.apache.org/jira/browse/TUSCANY-2228
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Affects Versions: Java-SCA-Next
> Environment: SVN trunk revision 648161
> Linux
>Reporter: Mark Combellack
>Assignee: Mark Combellack
> Fix For: Java-SCA-Next
>
>
> If I define a Property on my Component as type int and then attempt to set 
> the property value in the XML to a non-number (e.g. the String "Hello"), 
> Tuscany will throw the following exception:
> org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
> input string: ""
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)
> 
> Caused by: java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:468)
> at java.lang.Integer.parseInt(Integer.java:497)
> at 
> org.apache.tuscany.sca.databinding.impl.XSDDataTypeConverter.parseInt(XSDDataTypeConverter.java:771)
> at 
> org.apache.tuscany.sca.databinding.impl.SimpleTypeMapperImpl.toJavaObject(SimpleTypeMapperImpl.java:280)
> at 
> org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.getInstance(JavaPropertyValueObjectFactory.java:223)
> at 
> org.apache.tuscany.sca.implementation.java.injection.FieldInjector.inject(FieldInjector.java:52)
> at 
> org.apache.tuscany.sca.implementation.java.context.ReflectiveInstanceFactory.newInstance(ReflectiveInstanceFactory.java:80)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaComponentContextProvider.createInstanceWrapper(JavaComponentContextProvider.java:101)
> at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationProvider.createInstanceWrapper(JavaImplementationProvider.java:203)
> at 
> org.apache.tuscany.sca.core.scope.AbstractScopeContainer.createInstanceWrapper(AbstractScopeContainer.java:65)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.getWrapper(CompositeScopeContainer.java:52)
> at 
> org.apache.tuscany.sca.core.scope.CompositeScopeContainer.start(CompositeScopeContainer.java:71)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:540)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:476)
> at 
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:529)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:221)
> at 
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.(DefaultSCADomain.java:109)
> at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:230)
> The big problem with this exception is that it does not tell you which field 
> is invalid

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


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

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

[Mark Combellack (JIRA)]

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


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


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

org.osoa.sca.ServiceRuntimeException: java.lang.NumberFormatException: For 
input string: ""
at 
org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
at 
org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)

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



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

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


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

Mirror of release artifacts

[ant elder]

WIth the changes to how the Incubator release artifacts get distributed via
mirrors now I understood we were supposed to have our website download pages
use a script accessing the mirrors.  Looking back at the  SCA 1.1 download
page change history it did at one point do that (r17) but then it got
changed back to the non-script approach. Anyone know why? Are there some
issues with using the script/mirrors?

   ...ant

Re: SCA 2.0, was Re: Next SCA release

[ant elder]

On Tue, Apr 15, 2008 at 8:29 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:



After a week away I thought we'd have a clearer picture on this. Yesterday I
> put together some improvements of the admin app and some of the tutorial
> modules. I must say I'm a little lost now as to where I should commit that
> stuff.
>

Thats easy - to trunk. Development happens in the trunk.

   ...ant

Re: Python and Service Component Architecture.

[Giorgio Zoppi]

2008/4/15, Jean-Sebastien Delfino <[EMAIL PROTECTED]>:
> Simon Laws wrote:
>
> > On Wed, Apr 9, 2008 at 11:46 AM, Giorgio Zoppi <[EMAIL PROTECTED]>
> > wrote:
> >
> >
> > > I'll do a speech in Florence about SCA and Python next 11th May. If
> > > someone it's interested
> > > here http://www.pycon.it/pycon2/schedule.
> > >
> > >
> > > Ciao,
> > > Giorgio.
> > > ---
> > > Giorgio Zoppi [EMAIL PROTECTED]
> > >
> > >
> -
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > Hey, nice one Giorgio.  I've added this to the News section on the from
> page
> > of the web site wiki (will take a little time for the site itself to
> > update).
> >
> > If you need any general SCA/Tuscany slides there are few linked from
> > previous news items. There may also be a few others knocking around if you
> > need more. Not Python ones though unless Ant has some up his sleeve.
> >
> > Simon
> >
> >
>
>  BTW Giorgio do you know what level of support for Python do we have at the
> moment? Do we support references, properties? any limitations in terms of
> interfaces?
>
>  I think it'd be nice to have some samples that show some SCA Python
> components.
Yes. I'm planning a online store or a library. I've not started yet, but
I suppose that using Python with SCA-native or Jython will be easy.
I tried svn C++ native, but I've problems building it. I'll try it
again this evening.
Cheers,
Giorgio.
---
"The only people for me are the mad ones, the ones who are mad to
live, mad to talk, mad to be saved. The ones who never yawn or say a
commonplace thing, but burn, burn, burn like fabulous yellow roman
candles exploding like spiders across the stars"
On The Road - Jack Kerouac

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

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

[Simon Laws]

On Tue, Apr 15, 2008 at 9:35 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Comments inline.
>
>
> Simon Laws wrote:
>
> > On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <
> > [EMAIL PROTECTED]>
> > wrote:
> >
> >  Lou Amodeo wrote:
> > >
> > >  This is a request to propogate the value of a references target=
> > > > attribute
> > > > as a first class attribute on its associated bindings model object.
> > > > This request is based on a requirement to provide support to
> > > > implement a
> > > > late-endpoint resolution capability for service references when a
> > > > reference
> > > > specifies the target= attribute. This value in conjunction with a
> > > > domain
> > > > wide services registry allows the binding invokers to use the value
> > > > specified for  > > > lookup
> > > > to
> > > > obtain the services endpoint URI dynamically during the invocation
> > > > of
> > > > the
> > > > service rather than during compositie startup. The primary benefits
> > > > of
> > > > this
> > > > approach are to provide a degree of location transparency for
> > > > services
> > > > and
> > > > remove the requirement of the client from knowing the services
> > > > endpoint
> > > > at
> > > > installation time. This would only apply to clients that are running
> > > > in
> > > > the
> > > > same domain as the services they reference.
> > > >
> > > >
> > > >  After reading the whole thread I'm confused and would like to walk
> > > through
> > > a simple scenario with two composites A and B, A containing component
> > > references to components in B.
> > >
> > > Here are the steps I'm thinking about for A and B:
> > >
> > > A1. contribution A is installed in the domain.
> > > A2. deployable composite A is selected for deployment.
> > > A3. policy sets are configured and applied to elements of A.
> > > A4. A's references and dependencies are validated and satisfied.
> > > A5. composite A is deployed to SCA machine 1.
> > > A6. components in composite A are started.
> > > A7. a reference wired to a component in B is invoked.
> > >
> > > B1. contribution B is installed in the domain.
> > > B2. deployable composite B is selected for deployment.
> > > B3. policy sets are configured and applied to elements of A.
> > > B4. B's references and dependencies are validated and satisfied.
> > > B5. composite B is deployed to SCA machine 2.
> > > B6. components in composite B are started.
> > > B7. a reference wired to a component in B is invoked.
> > >
> > > By SCA machine I mean a logical processor responsible for
> > > instantiating
> > > components and executing their implementations (a server, a process, a
> > > node,
> > > a webapp, or whatever applies to your particular architecture).
> > >
> > > Would it be possible to describe the timing of the A steps function of
> > > the
> > > B steps, for example
> > > A1 < B1
> > > A2 < B1
> > > A3 < B1
> > > A4 > B5?
> > > etc?
> > >
> > > That will help me understand your requirement and what you're
> > > expecting of
> > > the various configuration and resolution steps.
> > >
> > > Thanks!
> > > --
> > > Jean-Sebastien
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >  Hi
> >
> > This conversation proved inconclusive but has been dormant for a while
> > so
> > I'm raising it again as there have been several emails recently that
> > touch
> > on peoples different perceptions of how Tuscany could/should operate ,
> > e.g.
> > [1], . Maybe we shouldn't be debating the merits of early vs late
> > binding of
> > reference targets in isolation but use this as very specific example of
> > a
> > more general question.
> >
> > How much flexibility of distributed operation does Tuscany allow for
> > people
> > implementing extensions.
> >
> > Going back to Lou's reference target question that started the
> > referenced
> > thread. IIUC the two views stated are.
> >
> > 1 - Reference targets are resolved before composites are deployed and
> > run
> > and in this way the assembly model is fully specified when
> > bindings/implementations are activated and started
> > 2 - Reference targets are resolved when the first request is made and in
> > this way the assembly model remains incomplete in terms of runtime
> > detail up
> > until the point when a binding is selected, configured and started.
> >
>
> (2) confuses me a little.
>
> The first part: "Reference targets are resolved when the first request is
> made" seems like what you wanted to say under (2).
>
> But then the second part "the assembly model remains incomplete in terms
> of runtime detail up until the point when a binding is selected, configured
> and started." sounds like (1) "the assembly model is fully specified when
> bindings/implementations are activated and started"
>
> Did I mis-understand what you meant in (2)?
>
>
> > Tuscany has taken both of th

[jira] Resolved: (TUSCANY-2191) A @Service annotation with no attributes causes exception

[Simon Laws (JIRA)]

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

Simon Laws resolved TUSCANY-2191.
-

Resolution: Fixed

Patch applied at revision 648192. Thanks Vamsi.

> A @Service annotation with no attributes causes exception
> -
>
> Key: TUSCANY-2191
> URL: https://issues.apache.org/jira/browse/TUSCANY-2191
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2191.patch
>
>
> Line 1635 of the Java Annotations spec says:
>A @Service annotation with no attributes is meaningless, it is the same as 
> not having the annotation there at all.
> However, the presence of the the annotation without attributes results in the 
> following:
> org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.contribution.service.ContributionResolveException: 
> org.apache.tuscany.sca.implementation.java.introspect.impl.IllegalServiceDefinitionException:
>  No interfaces specified
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)

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


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

[jira] Assigned: (TUSCANY-2191) A @Service annotation with no attributes causes exception

[Simon Laws (JIRA)]

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

Simon Laws reassigned TUSCANY-2191:
---

Assignee: Simon Laws

> A @Service annotation with no attributes causes exception
> -
>
> Key: TUSCANY-2191
> URL: https://issues.apache.org/jira/browse/TUSCANY-2191
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: TUSCANY-2191.patch
>
>
> Line 1635 of the Java Annotations spec says:
>A @Service annotation with no attributes is meaningless, it is the same as 
> not having the annotation there at all.
> However, the presence of the the annotation without attributes results in the 
> following:
> org.osoa.sca.ServiceRuntimeException: org.osoa.sca.ServiceRuntimeException: 
> org.apache.tuscany.sca.contribution.service.ContributionResolveException: 
> org.apache.tuscany.sca.implementation.java.introspect.impl.IllegalServiceDefinitionException:
>  No interfaces specified
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:264)
>   at 
> org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:69)

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


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

Re: Tutorial marketplace scenario ready

[Jean-Sebastien Delfino]

Antollini, Mario wrote:

I have finished coding the tutorial marketplace scenario.

I have attached all the necessary files in
https://issues.apache.org/jira/browse/TUSCANY-2224



Mario, that looks pretty good, I just got it working :)

One minor comment:

MarketCatalogImpl could be simplified a bit to call   each catalog once 
instead of twice.


And some ideas:

- We could add more catalogs to the list (a local one, the Web service 
ones, and the EJB catalog running on Geronimo) to really leverage the 
reference with multiplicity 0..n. We'd just need to change the contents 
of the different catalogs (for example have fruits/vegetables from 
different places).


That raises an interesting question about the mix of bindings that can 
be used on a reference with multiplicity 0..n. Can different targets use 
different bindings or do they have to all use the same binding? I think 
it's worth investigating.


- Use standalone  elements in a different .composite file in a 
different contribution to wire the goodsCatalog reference to the catalogs.


IMO this is a typical scenario where people want to add catalogs without 
changing the market contribution which has already been installed in the 
domain.


- Another idea, add a Web Service binding to your StoreMarket catalog 
component, add a markup to the prices, and that makes it a broker :)


Thoughts?
--
Jean-Sebastien

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

[ANNOUNCE] Apache Tuscany Java SDO 1.1 released

[ant elder]

The Apache Tuscany team are pleased to announce the 1.1-incubating
release of the Java SDO project.

Service Data Objects (SDO) are designed to simplify and unify the way
in which applications handle data. Using SDO, application programmers
can uniformly access and manipulate data from heterogeneous data
sources, including relational databases, XML data sources, Web
services, and enterprise information systems. Tuscany SDO provides an
implementation of the SDO 2.1 specification, this 1.1 release includes
several new features and improvements over the 1.0 release such as:

- the ability to generate SDO test classes using the maven-sdo-plugin
- support for custom data binding of DataObjects in a Swing UI
- Using the HelperContext for scope in the Tuscany API
- improved diagnostics

along with many bug fixes. See the RELEASE_NOTES for full details.

For more information and to download the SDO 1.1 release please go to:
http://incubator.apache.org/tuscany/sdo-java-releases.html

Apache Tuscany welcomes your help. Any contribution, including code,
testing, improving the documentation, or bug reporting is always
appreciated. For more information on how to get involved in Apache
Tuscany visit the website at: http://incubator.apache.org/tuscany.

Thank you for your interest in Apache Tuscany!
The Apache Tuscany Team.
---

Tuscany is an effort undergoing incubation at the Apache Software Foundation
(ASF), sponsored by the Apache Web services PMC. Incubation is required of
all newly accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have stabilized
in a manner consistent with other successful ASF projects. While incubation
status is not necessarily a reflection of the completeness or stability of
the code, it does indicate that the project has yet to be fully endorsed by
the ASF.

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

Re: Registering ModuleActivators without specifying a META-INF/services/org.apache.tuscany.sca.core.ModuleActivator file

[Jean-Sebastien Delfino]

Richard Mah wrote:
Can someone point me to some examples or info on how I can register 
ModuleActivators without specifying a 
META-INF/services/org.apache.tuscany.sca.core.ModuleActivator file. 

...

I'm assuming that you only want to run a subset of Tuscany, not the 
whole Tuscany runtime. The simplest then is to do this:


ExtensionPointRegistry extensionPoints =
new DefaultExtensionPointRegistry();

ModuleActivator activator = new YourModuleActivator();
activator.start(extensionPoints);

Basically new up your ModuleActivator and call its start method.

Which ModuleActivators are you interested in initializing that way?
--
Jean-Sebastien

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

[jira] Updated: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2165:
-

Attachment: TUSCANY-2165-revised-test.patch

TUSCANY-2165-revised-test.patch: AService interface has changed since the last 
time I attached a patch.  Revised the test to account for the changes.

> Java runtime should inject service references to field with common name in 
> absence of @Reference 
> -
>
> Key: TUSCANY-2165
> URL: https://issues.apache.org/jira/browse/TUSCANY-2165
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
> Attachments: TUSCANY-2165-revised-test.patch, TUSCANY-2165.patch
>
>
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> The vTest:  
> org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 
> demonstrates this issue

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


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

[jira] Updated: (TUSCANY-2165) Java runtime should inject service references to field with common name in absence of @Reference

[Vamsavardhana Reddy (JIRA)]

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

Vamsavardhana Reddy updated TUSCANY-2165:
-

Attachment: (was: TUSCANY-2165-revised-test.patch)

> Java runtime should inject service references to field with common name in 
> absence of @Reference 
> -
>
> Key: TUSCANY-2165
> URL: https://issues.apache.org/jira/browse/TUSCANY-2165
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
>Reporter: Kevin Williams
>Priority: Minor
> Attachments: TUSCANY-2165.patch
>
>
> The Java Annotations&APIs specification Lines 1407, 1408, 1409, 1410 ...
>  * References may also be injected via public setter methods even when the
>  * "@Reference" annotation is not present. However, the "@Reference"
>  * annotation must be used in order to inject a reference onto a non 
> public
>  * field. In the case where there is no "@Reference" annotation, the name 
> of
>  * the reference is the same as the name of the field or setter.
> The vTest:  
> org.apache.tuscany.sca.vtest.javaapi.ReferenceAnnotationTestCase.atReference2 
> demonstrates this issue

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


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

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

[Jean-Sebastien Delfino]

Comments inline.

Simon Laws wrote:

On Sun, Feb 3, 2008 at 5:36 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:


Lou Amodeo wrote:


This is a request to propogate the value of a references target=
attribute
as a first class attribute on its associated bindings model object.
This request is based on a requirement to provide support to implement a
late-endpoint resolution capability for service references when a
reference
specifies the target= attribute. This value in conjunction with a domain
wide services registry allows the binding invokers to use the value
specified for 
After reading the whole thread I'm confused and would like to walk through
a simple scenario with two composites A and B, A containing component
references to components in B.

Here are the steps I'm thinking about for A and B:

A1. contribution A is installed in the domain.
A2. deployable composite A is selected for deployment.
A3. policy sets are configured and applied to elements of A.
A4. A's references and dependencies are validated and satisfied.
A5. composite A is deployed to SCA machine 1.
A6. components in composite A are started.
A7. a reference wired to a component in B is invoked.

B1. contribution B is installed in the domain.
B2. deployable composite B is selected for deployment.
B3. policy sets are configured and applied to elements of A.
B4. B's references and dependencies are validated and satisfied.
B5. composite B is deployed to SCA machine 2.
B6. components in composite B are started.
B7. a reference wired to a component in B is invoked.

By SCA machine I mean a logical processor responsible for instantiating
components and executing their implementations (a server, a process, a node,
a webapp, or whatever applies to your particular architecture).

Would it be possible to describe the timing of the A steps function of the
B steps, for example
A1 < B1
A2 < B1
A3 < B1
A4 > B5?
etc?

That will help me understand your requirement and what you're expecting of
the various configuration and resolution steps.

Thanks!
--
Jean-Sebastien


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



Hi

This conversation proved inconclusive but has been dormant for a while so
I'm raising it again as there have been several emails recently that touch
on peoples different perceptions of how Tuscany could/should operate , e.g.
[1], . Maybe we shouldn't be debating the merits of early vs late binding of
reference targets in isolation but use this as very specific example of a
more general question.

How much flexibility of distributed operation does Tuscany allow for people
implementing extensions.

Going back to Lou's reference target question that started the referenced
thread. IIUC the two views stated are.

1 - Reference targets are resolved before composites are deployed and run
and in this way the assembly model is fully specified when
bindings/implementations are activated and started
2 - Reference targets are resolved when the first request is made and in
this way the assembly model remains incomplete in terms of runtime detail up
until the point when a binding is selected, configured and started.


(2) confuses me a little.

The first part: "Reference targets are resolved when the first request 
is made" seems like what you wanted to say under (2).


But then the second part "the assembly model remains incomplete in terms 
of runtime detail up until the point when a binding is selected, 
configured and started." sounds like (1) "the assembly model is fully 
specified when bindings/implementations are activated and started"


Did I mis-understand what you meant in (2)?



Tuscany has taken both of these approaches and is now tending toward 1. It
would be useful to have some confirmation Lou's view with comments on
Sebastien's previously stated scenario.

Generally there are a number of points of interest (to me at least).

A - Access to model information. Bindings are not configured with
information about their intended target and I guess there could be other
information that bindings require for late resolution.
B - Open building phases that give extensions the opportunity to override
Tuscany logic, for example, binding matching and selection.
C - Recognition of the flexibility of extension operation,  for example, in
this late resolution case [1] points out that functions like getService()
should cater for the case that a proxy may be requested for a reference that
is not yet resolved.

So should Tuscany mandate the mechanism for distributed operation or should
extension developer have the flexibility to influence it.

Thoughts?

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30309.htm



--
Jean-Sebastien

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

Re: New Eclipse update site in SCA 1.2 release

[Jean-Sebastien Delfino]

ant elder wrote:

In the 1.2 release candidate we've now an Eclipse update site. I can't find
any mention of this happening anywhere, do we have any doc at all on it
happening somewhere that I missed?

   ...ant



We've been referring to it under different names, mostly 'plugin', as 
the update site is how Eclipse plugins are installed.


A quick search gave me the following, but there's probably more:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Release+-+Java+SCA+1.2
http://issues.apache.org/jira/browse/TUSCANY-2119
http://issues.apache.org/jira/browse/TUSCANY-2142
http://issues.apache.org/jira/browse/TUSCANY-2157
http://issues.apache.org/jira/browse/TUSCANY-2166
http://issues.apache.org/jira/browse/TUSCANY-2175
http://issues.apache.org/jira/browse/TUSCANY-2179
http://marc.info/?l=tuscany-dev&m=120650695831123
http://marc.info/?l=tuscany-dev&m=120656320414940
http://marc.info/?l=tuscany-dev&m=120694778015549
http://marc.info/?l=tuscany-dev&m=120699934118018
http://marc.info/?l=tuscany-dev&m=120613784003868

--
Jean-Sebastien

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

Re: distribution target-last-successful copies

[Jean-Sebastien Delfino]

Luciano Resende wrote:

This was created to allow users to keep downloading nightly builds for
test verification purposes when we were having a period of not so
stable builds on the continuum machine.

I guess I'm fine with removing. Although a more secure approach would
be to add this task to a profile that would be run on the continuum
machine only, as it looks like that people have been running the
"distribution" profile often ?

On Fri, Apr 11, 2008 at 2:09 AM, Simon Laws <[EMAIL PROTECTED]> wrote:

On Fri, Apr 11, 2008 at 9:31 AM, ant elder <[EMAIL PROTECTED]> wrote:

 > On Thu, Apr 10, 2008 at 9:22 AM, ant elder <[EMAIL PROTECTED]> wrote:
 >
 > > The current distribution build copies the binary artifacts to the
 > > target-last-successful folder which takes about 130Meg. I'm guessing
 > this is
 > > something to do with the continuum builds but does anyone know for sure?
 > If
 > > so could we change it so it only happens on the continuum machine (have
 > the
 > > continuum build use a specific profile?), or if not can i just delete
 > the
 > > copy task?
 > >
 > >...ant
 > >
 >
 >
 > OK maybe if I ask a different way...
 >
 > It looks like the target-last-successful copies aren't actually required
 > anymore so unless i hear otherwise I'll remove the copy from the
 > distribution pom.xml.
 >
 >   ...ant
 >

 That's easier to answer ;-)

 +1. I've no idea what it is for so remove it and see if anything breaks.

 Simon



This was there to allow people to download the last successful build at 
all times.


Not sure if this is related or not but clicking "Nightly build download" 
on our download page [1] gives an error [2]. That's not great.


[1] 
http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
[2] 
http://vmbuild1.apache.org/continuum/workingCopy.action?projectId=277&projectName=Apache%20Tuscany%20SCA%20Implementation%20Project&userDirectory=distribution%2Ftarget&file=apache-tuscany-sca-1.1-incubating-SNAPSHOT.tar.gz

--
Jean-Sebastien

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

Re: Python and Service Component Architecture.

[Jean-Sebastien Delfino]

Simon Laws wrote:

On Wed, Apr 9, 2008 at 11:46 AM, Giorgio Zoppi <[EMAIL PROTECTED]>
wrote:


I'll do a speech in Florence about SCA and Python next 11th May. If
someone it's interested
here http://www.pycon.it/pycon2/schedule.


Ciao,
Giorgio.
---
Giorgio Zoppi [EMAIL PROTECTED]

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



Hey, nice one Giorgio.  I've added this to the News section on the from page
of the web site wiki (will take a little time for the site itself to
update).

If you need any general SCA/Tuscany slides there are few linked from
previous news items. There may also be a few others knocking around if you
need more. Not Python ones though unless Ant has some up his sleeve.

Simon



BTW Giorgio do you know what level of support for Python do we have at 
the moment? Do we support references, properties? any limitations in 
terms of interfaces?


I think it'd be nice to have some samples that show some SCA Python 
components.

--
Jean-Sebastien

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

Re: [(GSoC] Time to rank the Google Summer of Code Proposals

[Jean-Sebastien Delfino]

Giorgio Zoppi wrote:

For map/hadoop if you need a part time mentor till 30 June, ask me. After
that time I'll travel around Spain all summer.



Giorgio, that's great! I'll be happy to mentor the map-reduce / tuscany 
/ hadoop project with you as a co-mentor.


Can you sign up as a mentor and indicate which applications you're 
willing to co-mentor? I'm still catching up with email but I think the 
instructions to sign up are discussed in this thread too.


I wished I could travel around Spain all summer too :)
--
Jean-Sebastien

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

Re: Error Logging - how should it done in Tuscany?

[Simon Laws]

On Tue, Apr 15, 2008 at 8:44 AM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:

> Simon Laws wrote:
>
> > On Mon, Apr 14, 2008 at 2:49 PM, Mark Combellack <[EMAIL PROTECTED]
> > >
> > wrote:
> >
> >  Hi,
> > >
> > > Whilst fixing a bug[1] I wanted to log an error message. I've realised
> > > that
> > > I'm not clear on Tuscany's policy on how this should be done.
> > >
> > > I've had a look through the developer guides [2] and [3] (we have more
> > > than
> > > 1?) but neither mention anything about logging.
> > >
> > >
> > > To narrow the scope of this question a little bit, I am not talking
> > > about
> > > tracing execution (method entry/exit). I am talking about logging
> > > runtime
> > > errors.
> > >
> > >
> > > Having a scan through the Developer Mailing List, I could not find
> > > anything
> > > conclusive on the subject. There was a discussion in August 2007 [4]
> > > that
> > > seems to suggest the use of AOP and JDK Logging although no formal
> > > decision
> > > seems to have been made.
> > >
> > > Looking through the code, there appears to be a few strategies for
> > > logging:
> > >
> > >  *) Don't do any logging
> > >  *) Log to the Console - e.g. e.printStackTrace()
> > >  *) Use JDK logging.
> > >
> > >
> > >
> > > The scenario I ran into in the bug [1] was that a @OneWay invocation
> > > has
> > > thrown a RuntimeException (e.g. NullPointerException). The original
> > > invoking
> > > client is no longer around as a new Thread has been used to invoke the
> > > @OneWay operation. The exception could just ripple up through and
> > > "kill"
> > > the
> > > thread but this is not very nice. What I want to do is log the
> > > Exception
> > > so
> > > the fact it happened can be recorded in a log.
> > >
> > >
> > >
> > > From a personal perspective, I think we could consider using something
> > > like
> > > SL4J [5]. Tuscany is very likely to be integrated into other
> > > applications/containers (e.g. Tomcat, WebSphere, etc) so SL4J would
> > > allow
> > > the same Tuscany logging code to use different logging back ends (e.g.
> > > log4j, JDK Logging, console, etc) depending on the environment in
> > > which it
> > > is running.
> > >
> > >
> > >
> > > So  (takes a step back as he fears he might be opening a can of
> > > worms) what is the general opinion on how logging should be done
> > > in
> > > Tuscany?
> > >
> > > Thanks,
> > >
> > > Mark
> > >
> > > [1] https://issues.apache.org/jira/browse/TUSCANY-2225
> > > [2] http://cwiki.apache.org/TUSCANY/sca-java-development.html
> > > [3] http://cwiki.apache.org/TUSCANY/java-sca-developer-guide.html
> > > [4]
> > > http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg21735.html
> > > [5] http://www.slf4j.org/
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > Hi Mark
> > >
> >
> > Funny you should mention this. Way back when (your [1]) we decided to go
> > with the JDK logger as there were so many opinions this seemed to be the
> > lowest common denominator.
> >
>
> After having used it for a while now, my preference is still for the JDK
> logger for debug trace and logging.
>
>
> > As a slight aside I'm just now looking at the monitoring that goes on in
> > assembly where validation problem reports are collected and reported at
> > a
> > later date rather than just logged out (well actually they are just
> > logged
> > out at the moment by the monitor but I want to make it pluggable). There
> > is
> > a discussion here [1]. I'm just about to check in a pass at separating
> > out
> > the monitor to appreciate any comments. I'll post separately on this.
> >
> >
> Simon, for monitoring (which I consider differently from tracing/logging)
> the monitor discussed in [1] looks good to me.
>
> I would only suggest to rename MonitorImpl to DefaultLoggingMonitor to
> make clear that (1) it's a default impl that can be replaced and (2) it
> logs.
>
>  Regards
> >
> > Simon
> >
> > [1]
> > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30294.html
> >
> >
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Ok, thanks for the feedback Sebastien. I'll make the change you suggest.
I'll give it a bit longer and then change the current points that do
monitoring (as opposed to logging/tracing) to use this new version.

Regards

Simon

RE: Adding SVN version to Java files

[Mark Combellack]

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


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

Mark


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

Re: Error Logging - how should it done in Tuscany?

[Jean-Sebastien Delfino]

Simon Laws wrote:

On Mon, Apr 14, 2008 at 2:49 PM, Mark Combellack <[EMAIL PROTECTED]>
wrote:


Hi,

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

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


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


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

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

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



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



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



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

Thanks,

Mark

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



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

Hi Mark


Funny you should mention this. Way back when (your [1]) we decided to go
with the JDK logger as there were so many opinions this seemed to be the
lowest common denominator.


After having used it for a while now, my preference is still for the JDK 
logger for debug trace and logging.




As a slight aside I'm just now looking at the monitoring that goes on in
assembly where validation problem reports are collected and reported at a
later date rather than just logged out (well actually they are just logged
out at the moment by the monitor but I want to make it pluggable). There is
a discussion here [1]. I'm just about to check in a pass at separating out
the monitor to appreciate any comments. I'll post separately on this.



Simon, for monitoring (which I consider differently from 
tracing/logging) the monitor discussed in [1] looks good to me.


I would only suggest to rename MonitorImpl to DefaultLoggingMonitor to 
make clear that (1) it's a default impl that can be replaced and (2) it 
logs.



Regards

Simon

[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30294.html



--
Jean-Sebastien

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

Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

[Venkata Krishnan]

+1 from me.  Eclipse update is going fine.  Samples are ok.  Could not spot
any problems with licenses.

Luciano, thanks a ton for all the hard work.

- Venkat

On Mon, Apr 14, 2008 at 3:36 PM, Luciano Resende <[EMAIL PROTECTED]>
wrote:

> Please review and vote on the 1.2 release artifacts of Tuscany SCA for
> Java.
>
> The artifacts are available for review at:
> http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/
>
> This includes the signed binary and source distributions, the RAT report,
> and the Maven staging repository.
>
> The eclipse updatesite for the Tuscany Eclipse plugins is available at:
> http://people.apache.org/~lresende/tuscany/sca-1.2-RC4/updatesite/
>
> The release tag is available at :
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC4/
>
>
> Looks OK to me, here is my +1.
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: SCA 2.0, was Re: Next SCA release

[Jean-Sebastien Delfino]

Luciano Resende wrote:

On Fri, Apr 11, 2008 at 3:28 AM, ant elder <[EMAIL PROTECTED]> wrote:

On Thu, Apr 10, 2008 at 10:33 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

 


+1.  Many of the items suggested for 2.0 have previously been the
 > subject of discussions that have not been easy to close.  Until
 > we have agreement on how to approach these things, I think it's
 > better for 2.0 development to happen in an "investigative" branch.
 > Doing this will allow us to try different approaches and see
 > which we prefer, without causing a lot of churn to the trunk.
 >

 So based on the comments so far I think we should hold off on moving to 2.0
 for now.


+1, let's get consensus first.


 That said I'm extremely wary of the having work going on in "investigative"
 branches, given Tuscany's history of branches and forks I really really hope
 this doesn't happen much and we'd instead all try to work together in the
 trunk.



+1


   ...ant





After a week away I thought we'd have a clearer picture on this. 
Yesterday I put together some improvements of the admin app and some of 
the tutorial modules. I must say I'm a little lost now as to where I 
should commit that stuff.


It's difficult to see where we are in this long thread. Is there a 
consensus? Can somebody please summarize where we are?


Thanks.
--
Jean-Sebastien

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

Re: SCA 2.0, was Re: Next SCA release

[Jean-Sebastien Delfino]

ant elder wrote:

On Wed, Apr 9, 2008 at 10:23 PM, Jean-Sebastien Delfino <
[EMAIL PROTECTED]> wrote:





1.3 sounds good to me. I'm assuming that we'll cut that branch out of
trunk?

I'm asking because I'm interested in working on some improvements of 1.2
in the next few weeks. This shouldn't delay any 2.0 work however, which can
go in parallel.



That sounds scary.

Are you saying you don't think its the right time for 2.0?


No, and I'm not sure about what's not clear in "I'm interested in 
working on some improvements of 1.2 in the next few weeks. This 
shouldn't delay any 2.0 work however, which can go in parallel." and why 
it sounds scary.


--
Jean-Sebastien

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

Re: Apache Tuscany committer status reaffirmation

[Rajith Attapattu]

Ant,

I have been inactive for the last 12 months or so.
The Qpid project is taking so much of my time and judging by the past
12 months I think I will be unable to devote enough quality time to
deserve comittership.
So I would appreciate if you can revoke it.

I do have a plan to jump back in and update the JMS binding (if
someone hasn't done yet) and to do an AMQP binding.
Not sure when it is, but when that happens perhaps I may do enough
work to earn comittership again.
But until that happens please take me off the list.

I wish the Tuscany community all the best and hopefully will start
working again with you guys.

Regards,

Rajith



On Sat, Apr 12, 2008 at 5:23 AM, ant elder <[EMAIL PROTECTED]> wrote:
> You are receiving this email because you are listed as an Apache
>  Tuscany committer. Tuscany is looking to graduate in the near future
>  and following Apache Incubator practice is cleaning up the committer
>  list.  Tuscany has 35 committers listed on the status file some of
>  those have left and some were just listed there when the original
>  proposal was accepted and have never even once committed anything.
>  We've decided any one who has interacted with the project within the
>  last 12 months will automatically remain a committer, anyone else will
>  need to reply to this email to retain their committer status.
>
>  These are the committers who've participated in the last 12 months and
>  will automatically retain their committer status:
>
> adrianocrestani Adriano Crestani
> amita   Amita Vadhavkar
> ajborleyAndrew Borley
> antelderAnt Elder
> bjohnsonBrady Johnson
> dkulp   Dan Kulp
> frankb  Frank Budinsky
> fuhwei  Fuhwei Lwo
> giorgio Giorgio Zoppi
> isilval Ignacio Silva-Lepe
> jsdelfino   Jean-Sebastien Delfino
> kelvingoodson   Kelvin Goodson
> kwilliams   Kevin Williams
> lresendeLuciano Resende
> mcombellack Mark Combellack
> myoder  Michael Yoder
> edwardsmj   Mike Edwards
> nashSimon Nash
> rsivaramRajini Sivaram
> rfeng   Raymond Feng
> robbinspg   Pete Robbins
> slaws   Simon Laws
> svkrish Venkata Krishnan
>
>  So, if you are not on that list but would like to retain your Tuscany
>  committer status please reply to this email and let us know about how
>  you would like to be involved with Tuscany. Also, if you are on that
>  list but no longer want to stay a committer once Tuscany graduates you
>  can also reply to this email and we'll remove your name.
>
>  Many thanks,
>  The Apache Tuscany PPMC
>



-- 
Regards,

Rajith Attapattu
http://rajith.2rlabs.com/

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