date:20080415

Yes, I'd expect the stack overflow as we would keep delegating back
and forth for the import/export model resolvers. Please file a jira,
and let's work together to find a solution for this issue.

On Mon, Apr 14, 2008 at 10:39 PM, Wang Feng [EMAIL PROTECTED] wrote:
 Hi  Luciano

  Thank you for your quick response.

  When a contribution metadata contains a deployable composite but the 
 composite is not exist,
  there will be recursive resolve the composite and will stack overflow.

  I will create a jira and  put my testcase.

  Thanks,
  Wang Feng




  On 2008-04-15,Luciano Resende [EMAIL PROTECTED] wrote:

  I'd say that the scenario is valid, but as mentioned in [1], we were
  not handling cycles very well in our import/export model resolvers.
  Are you experiencing a specific issue that I could try helping ?
  
  
  [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28147.html
  
  On Mon, Apr 14, 2008 at 8:14 PM, Wang Feng [EMAIL PROTECTED] wrote:
   Hi all
I have a scenario like this.There are two contributions and each one 
 contribution
contains one composite which has the same namespace.  The namespace has 
 been
imported and exported on every contribution.
I am not sure this scenario is right or wrong,can anybody give me an 
 advice?
  
Contribution metadata like below:
Contribution A
contribution xmlns=http://www.osoa.org/xmlns/sca/1.0;
 targetNamespace=http://hello;
 xmlns:hello=http://hello;
  deployable composite=hello:helloworldws/
  import namespace=http://hello/
  export namespace=http://hello/
/contribution
  
Contribution B
contribution xmlns=http://www.osoa.org/xmlns/sca/1.0;
 targetNamespace=http://hello;
 xmlns:hello=http://hello;
  deployable composite=hello:helloworld/
  import namespace=http://hello/
  export namespace=http://hello/
/contribution
  
--
Wang Feng
2008-04-15
  
  
-
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]
  


  -
  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: Can composite namespace equal in different contribution?


Mike Edwards wrote:

Wang Feng wrote:

Hi all
I have a scenario like this.There are two contributions and each one 
contribution contains one composite which has the same namespace.  The 
namespace has been imported and exported on every contribution.
I am not sure this scenario is right or wrong,can anybody give me an 
advice?


Contribution metadata like below:
Contribution A   
contribution xmlns=http://www.osoa.org/xmlns/sca/1.0;

  targetNamespace=http://hello;
  xmlns:hello=http://hello;
   deployable composite=hello:helloworldws/
   import namespace=http://hello/
   export namespace=http://hello/
/contribution   

Contribution B   
contribution xmlns=http://www.osoa.org/xmlns/sca/1.0;

  targetNamespace=http://hello;
  xmlns:hello=http://hello;
   deployable composite=hello:helloworld/
   import namespace=http://hello/
   export namespace=http://hello/
/contribution   


--
Wang Feng
2008-04-15

Wang Feng,

It is perfectly acceptable to use the same namespace for artifacts such 
as composites in multiple contributions.  Your example is just fine.


What you should not do is to have the same name for the same type of 
artifact in the same namespace, whereever they are placed - that is to 
invite trouble.  So names composite1 and composite2 are OK, but to 
have two composites named composite1 is not wise, even if they are in 
separate contributions.



Yours,  Mike.



For examples of contributions that share a namespace, see the folders 
under sca/java/tutorial, many of the contributions in the tutorial share 
the same http://store namespace.


Hope this helps.
--
Jean-Sebastien

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

Re: Apache Tuscany committer status reaffirmation

2008-04-15 Thread 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]

Re: SCA 2.0, was Re: Next SCA release


ant elder wrote:

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

snip



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

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



That sounds scary.

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


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: SCA 2.0, was Re: Next SCA release


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:

 snip


+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: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

2008-04-15 Thread 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/http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/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://people.apache.org/%7Elresende
 http://lresende.blogspot.com/

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

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


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: Error Logging - how should it done in Tuscany?

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: [(GSoC] Time to rank the Google Summer of Code Proposals


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

2008-04-15 Thread 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: Python and Service Component Architecture.


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: distribution target-last-successful copies


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=277projectName=Apache%20Tuscany%20SCA%20Implementation%20ProjectuserDirectory=distribution%2Ftargetfile=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: New Eclipse update site in SCA 1.2 release


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-devm=120650695831123
http://marc.info/?l=tuscany-devm=120656320414940
http://marc.info/?l=tuscany-devm=120694778015549
http://marc.info/?l=tuscany-devm=120699934118018
http://marc.info/?l=tuscany-devm=120613784003868

--
Jean-Sebastien

-
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


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]

[ANNOUNCE] Apache Tuscany Java SDO 1.1 released

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]

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

2008-04-15 Thread 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 AnnotationsAPIs 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

2008-04-15 Thread 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 AnnotationsAPIs 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


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 reference target= as a key to perform a service 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 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

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.


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

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

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 reference target= as a key to perform a service
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 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

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

2008-04-15 Thread 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]

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

2008-04-15 Thread 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]

Re: Python and Service Component Architecture.

2008-04-15 Thread 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: SCA 2.0, was Re: Next SCA release

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

snip

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

Mirror of release artifacts

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

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

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


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


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

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



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

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


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

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


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

Mark Combellack commented on TUSCANY-2228:
--

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

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

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

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


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

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


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

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


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

Mark Combellack commented on TUSCANY-2228:
--

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

The exception now looks like:

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


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

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


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

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

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


[ 
https://issues.apache.org/jira/browse/TUSCANY-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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]

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

2008-04-15 Thread 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/http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/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://people.apache.org/%7Elresende

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] Resolved: (TUSCANY-2228) Setting an Integer Property with a non-number throws NumberFormatException - but for which Property?


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

Mark Combellack resolved TUSCANY-2228.
--

Resolution: Fixed

Added unti test for JavaPropertyValueObjectFactory in SVN revision 648256.

Marking bug as fixed.

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

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


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

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


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

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

2008-04-15 Thread 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

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)

2008-04-15 Thread 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]

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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/
 http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/
 http://people.apache.org/%7Elresende/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: How do you plug in validation monitoring?

2008-04-15 Thread 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):
 
   component name=MyServiceComponentNew
 implementation.java
 class=mysca.test.myservice.impl.MyServiceImpl/
 *binding.ws/*
 property name=location source=$newLocation/
 property name=year source=$newYear/
   /component
 
  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 binding element found. It should appear inside a
service
 or
  reference 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)
 at
 
 

   
  com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:281)
 at
 
 

   
  com.ibm.ws.runtime.component.CompositionUnitMgrImpl$CUInitializer.run(CompositionUnitMgrImpl.java:768)
 at
 
 

   
  com.ibm.wsspi.runtime.component.WsComponentImpl$_AsynchInitializer.run(WsComponentImpl.java:348)
 at
  com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1487)
 
 
  regards
 
  On Tue, Apr 8, 2008

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


[ 
https://issues.apache.org/jira/browse/TUSCANY-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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]

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


[ 
https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 AnnotationsAPIs 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: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

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/http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/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] Commented: (TUSCANY-2199) Tests for @Reference annotation


[ 
https://issues.apache.org/jira/browse/TUSCANY-2199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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]

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


 [ 
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] Closed: (TUSCANY-2199) Tests for @Reference annotation


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

Re: Apache Tuscany committer status reaffirmation

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/

Classloading info

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

 http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28235.html[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: How do you plug in validation monitoring?

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):
  
component name=MyServiceComponentNew
  implementation.java
  class=mysca.test.myservice.impl.MyServiceImpl/
  *binding.ws/*
  property name=location source=$newLocation/
  property name=year source=$newYear/
/component
  
   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 binding element found. It should appear inside a
 service
  or
   reference 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)
  at
  
  
 

  
 com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:281)
  at

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

2008-04-15 Thread Mark Combellack

Hi,

 

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

 

 

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

java.lang.NoClassDefFoundError

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

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

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

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

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

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

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

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

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

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

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

  at $Proxy141.getGreetings(Unknown Source)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

java.lang.NoClassDefFoundError

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  at $Proxy141.getGreetings(Unknown

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

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: tuscany-dev@ws.apache.org
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 JAVA_HOME/lib/endorsed to 
override the API jars that ship with the JDK
3) Use the -Djava.endorsed.dir=a folder containing our JAXB jars 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: tuscany-dev@ws.apache.org; [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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/
http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/
http://people.apache.org/%7Elresende/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

2008-04-15 Thread 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]

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 JAVA_HOME/lib/endorsed to override the 
API jars that ship with the JDK
3) Use the -Djava.endorsed.dir=a folder containing our JAXB jars 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: tuscany-dev@ws.apache.org; [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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/
http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/
http://people.apache.org/%7Elresende/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]

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

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 JAVA_HOME/lib/endorsed to override
 the API jars that ship with the JDK
 3) Use the -Djava.endorsed.dir=a folder containing our JAXB jars 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: tuscany-dev@ws.apache.org; [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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/
   http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/
   http://people.apache.org/%7Elresende/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/http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/
   http://people.apache.org/%7Elresende/tuscany/sca-1.2-RC4/updatesite/
   http://people.apache.org/%7Elresende/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]


For the record I ran some samples, demos etc and RC4 looks good to me so +1.


Assuming that Raymond's solution solves Mikes problem I'd be happy with a
FAQ entry and possible a

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

2008-04-15 Thread 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]

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

2008-04-15 Thread 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: Mirror of release artifacts

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]

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


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: Run Tuscany with JDK 6: was: Re: [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)


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]

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


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: Apache Tuscany committer status reaffirmation

2008-04-15 Thread 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?

2008-04-15 Thread 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

2008-04-15 Thread 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 wire 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 wire 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]

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

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: tuscany-dev@ws.apache.org
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: Got WARNING if @Context is used to annotate a setter method

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: tuscany-dev@ws.apache.org
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: [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

2008-04-15 Thread 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: JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

2008-04-15 Thread 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: Got WARNING if @Context is used to annotate a setter method

2008-04-15 Thread Gilbert Kwan

my composite just simply as:

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

component name=BComponent
implementation.java
class=org.apache.tuscany.sca.vtest.javaapi.impl.BServiceImpl/
/component

/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: tuscany-dev@ws.apache.org
 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: Got WARNING if @Context is used to annotate a setter method


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: tuscany-dev@ws.apache.org
Subject: Re: Got WARNING if @Context is used to annotate a setter method


my composite just simply as:

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

   component name=BComponent
   implementation.java
class=org.apache.tuscany.sca.vtest.javaapi.impl.BServiceImpl/
   /component

/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: tuscany-dev@ws.apache.org
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: Should we move to SDO 1.1-incubating version for SCA Java?

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]

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


[ 
https://issues.apache.org/jira/browse/TUSCANY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 AnnotationsAPIs 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] Created: (TUSCANY-2229) Got WARNING if @Context is used to annotate a setter method

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:
=
composite xmlns=http://www.osoa.org/xmlns/sca/1.0; 
   targetNamespace=http://java-api-tests;
   name=AB-Composite
   component name=BComponent
   implementation.java
class=org.apache.tuscany.sca.vtest.javaapi.impl.BServiceImpl/
   /component
/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] Updated: (TUSCANY-2230) Test Cases for RequestContext API


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

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

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] Created: (TUSCANY-2231) Test Cases for CallableReference API

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] Updated: (TUSCANY-2231) Test Cases for CallableReference API


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

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


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]

[DISCUSS] Evolving Implementation-data-xml

2008-04-15 Thread 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:

resultSet
record
column name=NAME type=VARCHARNew Coorporation I/column
column name=PHONE type=INTEGER+5511990202146/column
 . . .
/record
/resultSet

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] Created: (TUSCANY-2233) Test Cases for Conversation API

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]

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


 [ 
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-2232) Test Cases for ServiceReference API

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-2233) Test Cases for Conversation API


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

Re: [DISCUSS] Evolving Implementation-data-xml

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:

  resultSet
 record
 column name=NAME type=VARCHARNew Coorporation I/column
 column name=PHONE type=INTEGER+5511990202146/column
  . . .
 /record
  /resultSet

  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]

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

2008-04-15 Thread 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
 keTarget(OSGiTargetInvoker.java:143)

  at

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

  at

Usability improvements to admin application


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: JAXB 2.1 and JDK level, was [VOTE] Release Tuscany Java SCA 1.2-incubating (RC4)

2008-04-15 Thread 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]

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

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]

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


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

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

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!
  
   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
   )

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

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]

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

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]

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