[VOTE] Release Tuscany Java SCA 1.2-incubating (RC3b)

[Luciano Resende]

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-RC3b/

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-RC3b/updatesite/

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


Looks OK to me, here is my +1.

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

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

Project Ideas - Let's get the community involved !!!

[Luciano Resende]

I have noticed that the approach we used for GSoC, where we described
small project ideas, with a proper description and a suggested
scenario to guide the development of the idea is generating much more
interest from the community.

I'd like us to keep on this path, and I have created a page for us to
post these ideas [1], and also modified our website page to advertise
these ideas for possible "contributors" [2][3].

Please provide your feedback, and help by adding new ideas to the page.

NOTE: pages should be live in about 1 hour.

[1] http://incubator.apache.org/tuscany/getting-involved-projects.html
[2] http://incubator.apache.org/tuscany/
[3] http://incubator.apache.org/tuscany/getting-involved.html

-- 
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-2109) Conflicts between component reference interface and promoted composite reference interface are not detected

[wangfeng (JIRA)]

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

wangfeng commented on TUSCANY-2109:
---

Hi Simon
According to the spec,line 1358 to 1360 define the reference interface 
restriction.
1358 If an interface is specified it must provide an interface which is the 
same or which is a  
1359 compatible superset of the interface declared by the promoted component 
reference, i.e. provide  
1360 a superset of the operations defined by the component for the reference. 

I think the interface only need to compare the operation is compatible or not.
My understanding about 'namespace'  is that if the interface is compatible ,the 
package name of java interface must be consistent to the  target namespace of 
wsdl interface,is my understanding  right?


> Conflicts between component reference interface and promoted composite 
> reference interface are not detected 
> 
>
> Key: TUSCANY-2109
> URL: https://issues.apache.org/jira/browse/TUSCANY-2109
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: All
>Reporter: Simon Nash
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: jira2109.patch, jira2109.zip
>
>
> See TUSCANY-2033 for the background to this problem.
> When a component reference defined with  (either explicitly 
> or implicitly by introspection) is promoted to a composite reference defined 
> with , and there is a namespace conflict between the 
> component reference's  and the composite reference's 
> . this conflict should be diagnosed as an error because it 
> violates the spec rule that an interface specified on a composite reference 
> must be a compatible superset of the interface of the promoted component 
> reference. In this case, the composite interface is incompatible with the 
> component reference because it has a different namespace.
> There is code in CompositeWireBuilderImpl.connectCompositeReferences() to 
> handle connections between composite references and promoted compoennt 
> references. The only interface processing performed in this method is to copy 
> the component reference's interface contract to the composite reference's 
> interface contract if the composite reference does not have an interface 
> contract. Code should be added here to check for conflicts between the 
> composite reference's interface and the component reference's interface if 
> both interfaces are specified.
> Similar code should be added to 
> CompositeWireBuilderImpl.connectCompositeServices() to check that the 
> composite service interface is a compatible subset of the component service 
> interface as required by the spec. 

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

Setting the SVN config for the correct file properties, was : Re: Tuscany Java SCA 1.2-incubating (RC3a) - SVN issues

[Raymond Feng]

Hi,

For each Tuscany committers, they should configure properties in the 
per-user SVN config. On Unix-like systems, it is home>/.subversion/config. On Win32 systems, it is \Application 
Data\Subversion\config (by the way, the Application Data folder is usually a 
hidden directory).


Please make sure the following properties are set in the "config" file:

[miscellany]
...
enable-auto-props = yes

[auto-props]
### The format of the entries is:
###   file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?').  All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.

*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.h = svn:eol-style=native
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sh = svn:eol-style=native;svn:executable
*.txt = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
Makefile = svn:eol-style=native

*.java = svn:eol-style=native;svn:keywords=Rev Date
*.xml = svn:eol-style=native;svn:keywords=Rev Date
*.xsd = svn:eol-style=native;svn:keywords=Rev Date
*.html = svn:eol-style=native;svn:keywords=Rev Date
*.properties = svn:eol-style=native;svn:keywords=Rev Date
*.jelly = svn:eol-style=native;svn:keywords=Rev Date
*.ipr = svn:eol-style=native
*.iml = svn:eol-style=native

I have added it to the developer guide and also checked in a template at: 
https://svn.apache.org/repos/asf/incubator/tuscany/java/etc/svn-config.


Thanks,
Raymond

--
From: "Luciano Resende" <[EMAIL PROTECTED]>
Sent: Wednesday, April 09, 2008 6:24 PM
To: 
Subject: Re: Tuscany Java SCA 1.2-incubating (RC3a) - SVN issues


Thanks Sebb, I have applied this to the SCA 1.2 branch and will later
merge to trunk.

BTW, do you have an automated way to check for these issues ? we could
enhance our release page to avoid issues in the future.

[1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases

On Wed, Apr 9, 2008 at 5:40 AM, sebb <[EMAIL PROTECTED]> wrote:

There are a lot of .java (and other) files in SVN without the correct
 eol-style:native settings.

 Also some files incorrectly have executable:*

 I've created a script that can be used to fix these; try to run it on
 the same OS as was last used to update the files to reduce the SVN
 mail noise.

 See the file tuscany-sca-1.2-RC3a.sh in:

 http://people.apache.org/~sebb/SVNfixes/

 Just rename as .cmd to use on Windows.

 The same script should probably be applied to trunk.

 S///

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

Re: Tuscany Java SCA 1.2-incubating (RC3a) - SVN issues

[Luciano Resende]

Thanks Sebb, I have applied this to the SCA 1.2 branch and will later
merge to trunk.

BTW, do you have an automated way to check for these issues ? we could
enhance our release page to avoid issues in the future.

[1] http://cwiki.apache.org/confluence/display/TUSCANY/Making+releases

On Wed, Apr 9, 2008 at 5:40 AM, sebb <[EMAIL PROTECTED]> wrote:
> There are a lot of .java (and other) files in SVN without the correct
>  eol-style:native settings.
>
>  Also some files incorrectly have executable:*
>
>  I've created a script that can be used to fix these; try to run it on
>  the same OS as was last used to update the files to reduce the SVN
>  mail noise.
>
>  See the file tuscany-sca-1.2-RC3a.sh in:
>
>  http://people.apache.org/~sebb/SVNfixes/
>
>  Just rename as .cmd to use on Windows.
>
>  The same script should probably be applied to trunk.
>
>  S///
>
>  -
>  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: SCA 2.0, was Re: Next SCA release

[Jean-Sebastien Delfino]

haleh mahbod wrote:

1 - [] Put V2 doc changes in V1 pages and mark them as such
2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current

site wiki

3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces


Option 2 seems reasonable.  Option 3 can be considered in the future if
there is a need.
It would be good to get user's perspective on all this.



+0.5 for options [1], [2] and maybe [3] later :)

I'm just saying 0.5 as looking at our current docs as I'm not sure about 
 how people are planning to change them in 2.0. It's a little difficult 
to discuss a process to manage changes without knowing the extent and 
nature of the changes :)


--
Jean-Sebastien

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

Re: SCA 2.0, was Re: Next SCA release

[Jean-Sebastien Delfino]

Simon Laws wrote:

I'm +1 on this. Comments in line

Simon.



- Continue with SCA 1.x maintenance releases based on the current SCA
1.2 branch. This would be a more stable codebase, and we should avoid
big changes that could brake backward compatibility here.




I propose that we create the branch for 1.x develop directly after 1.2 is
out to make clear our intentions. It's not clear if the suggestion here is
to create sca-java-1.X or sca-java-1.3. My vote would be for the latter
(reserving sca-java-1.2.1 in case we need to address specific concerns in
1.2 that are not subject to ongoing maintenance activities).



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.


--
Jean-Sebastien

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

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

[Luciano Resende]

Thanks for all the input here. I have fixed all the important issues
reported with RC3a and I'm in the process of making a RC3b.

On Wed, Apr 9, 2008 at 11:02 AM, Adriano Crestani
<[EMAIL PROTECTED]> wrote:
> +1 everything worked now : )
>
>
>  On Wed, Apr 9, 2008 at 5:40 AM, Dan Becker <[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-RC3a/
>
>
> > >
>  > >
>  > +1
>  >
>  > Working from your zip package at the above site, I was able to unzip, ant
>  > build and run the calculator sample. At least we know 3 + 2= 5.0!
>  >
>  > Doing an svn update and mvn  build, I had no trouble working in Eclipse.
>  >
>  > --
>  > Thanks, Dan Becker
>  >
>  >
>  > -
>  > 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: SCA 2.0, was Re: Next SCA release

[haleh mahbod]

>1 - [] Put V2 doc changes in V1 pages and mark them as such
>2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
site wiki
>3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces

Option 2 seems reasonable.  Option 3 can be considered in the future if
there is a need.
It would be good to get user's perspective on all this.


On 4/9/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 9, 2008 at 5:03 PM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > +1 on versioning SCA docs
> > > >
> > > > Assuming two versions of SCA Java, I can see that the following page
> > > will
> > > > change to point to two different versions of SCA Java, 1.x and 2.x
> and
> > > > their
> > > > related documentation.
> > > >
> > > >
> > >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> > > >
> > > > Tuscany SCA Java general page would contain general information that
> > > would
> > > > pertain to both versions. So, it might need to change.
> > > > http://incubator.apache.org/tuscany/sca-java.html
> > > >
> > > > On the left navigation of sca-java page, we would have two boxes
> > > > SCA Java 2.x
> > > > SCA Java 1.x
> > > >
> > > > each would point to their own releases and their own documentations
> > and
> > > > source code tree.
> > > >
> > > > There is a set of documentations under SCA Java that are generic,
> like
> > > > development guide. We could share these pages between the two
> > versions.
> > > >
> > > > Does this make sense?
> > > >
> > > >
> > > Generally make sense to me.
> > >
> > > On the particular question of where to host V2  and V2 docs we have
> > > identified 3 choices so far.
> > >
> > > 1 - [] Put V2 doc changes in V1 pages and mark them as such
> > > 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> > > current
> > > site wiki
> > > 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
> > >
> > > Are there other cunning options we need to consider. I'm for option 2
> at
> > > the
> > > current time.
> > >
> > > Simon
> > >
> >
> > How would that option [2] actually work?
> >
> > Lets say I change the way the dwr binding works and want to update the
> doc
> > for V2, the current wiki page is at
> > http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what
> > would
> > i do for the new v2 page?
> >
> >   ...ant
>
>
> You would make
> http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html<
> http://incubator.apache.org/tuscany/sca-java-bindingajax.html>.
> Copy the existing contents there. Edit them which whatever change you need
> to make and and then add a link to this page to the V2 index (which I
> expect
> will, by default, link to the existing pages).
>
> Simon
>

Re: STP SCA Component -> STP SCA Tools sub project

[Jean-Sebastien Delfino]

Stéphane Drapeau wrote:

Hi,

I created an entry [0] in the Eclipse bugzilla with the proposal.
Your comments are welcome.

Best regards

Stéphane Drapeau
Obeo

[0]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=225956



The proposal looks pretty good to me. I have a few comments/questions:

- Are you going to have tools to create SCA contributions, 
imports/exports, contribution dependencies etc?


- You mention validation rules in the EMF model. Will the tool create 
problems, warnings, tasks etc in the Eclipse problem view?


- Do you have any plans to provide hooks to Run/Debug SCA components 
from the tool?


- Are you going to cover any of the SCA domain and deployment aspects, 
like deploying SCA contributions and composites to an SCA domain shared 
by a team for example?



+1 from me to have Tuscany listed as an interested party.

--
Jean-Sebastien

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

RE: Unable to create a distributed SCA binding provider for reference: currencyConverter

[Antollini, Mario]

Luciano and Simon, 

thanks for the replies.

I was running everything from Eclipse. I installed the Tuscany plugin
developed by Jean-Sebastien (it automatically downloaded a bunch of
Tuscany jar files, which I guess are old ones). Therefore, I am sure
that the problem is what Simon mentioned: an old version of the
domain/node is being used.

I will try to run everything by hand the way Luciano described and I'll
let you know how everything went.

Best regards,
Mario

-Original Message-
From: Luciano Resende [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 09, 2008 2:37 PM
To: tuscany-dev@ws.apache.org
Subject: Re: Unable to create a distributed SCA binding provider for
reference: currencyConverter

I was having a similar issue with catalog-webapp, you might need to
start the domain admin and start the currency converter service ?

Runing from a distribution, you should be able to start the service
with something like  :

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

To access the SCA Manager application, point your Web browser to:
   http://localhost:9990/ui/cloud/

You should then be able to start the service...

Let me finish the fixes to 1.2 RC and I'll give this a try and provide
a more concrete feedback here.


On Tue, Apr 8, 2008 at 6:03 AM, Antollini, Mario
<[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
>  I am trying to run the tutorial but I get the following error when
>  executing the tutorial/web-services/catalogs.composite from Eclipse:
>
>
>
>  Apr 8, 2008 9:46:54 AM
>  org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
>  problem
>  WARNING: Component reference target not found, it might be a remote
>  service: CurrencyConverterWebService
>  Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
>  Exception starting node
>  org.apache.tuscany.sca.node.NodeException:
>  org.apache.tuscany.sca.core.assembly.ActivationException:
>  java.lang.IllegalStateException: Unable to create a distributed SCA
>  binding provider for reference: currencyConverter and target:
>  CurrencyConverterWebService
> at
>
org.apache.tuscany.sca.node.impl.SCANodeImpl.startComposites(SCANodeImpl
>  .java:491)
> at
>
org.apache.tuscany.sca.node.impl.SCANodeImpl.start(SCANodeImpl.java:253)
> at
>
org.apache.tuscany.sca.node.launch.SCANodeLauncher.main(SCANodeLauncher.
>  java:51)
>  Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
>  java.lang.IllegalStateException: Unable to create a distributed SCA
>  binding provider for reference: currencyConverter and target:
>  CurrencyConverterWebService
> at
>
org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(Com
>  positeActivatorImpl.java:745)
>
>
>
>  I am trying to test the store-market module, so, what I am doing is:
>
>  1 - I successfully started tutorial/web-services/currency.composite
from
>  Eclipse
>
>  2 - I want to execute tutorial/web-services/catalogs.composite and I
get
>  the mentioned error.
>
>
>
>  Can someone give me a hint of what I am doing wrong? I did not modify
>  anything within tutorial/web-services so I assume everything is OK.
>  However I did check the names of the components and references within
>  the composites and they are OK.
>
>
>
>  Thanks and regards,
>
>
>
>
>
>  Mario E. Antollini
>  Intel Software
>  ASDC
>  +54 351 526 5594
>  [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]

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

[Adriano Crestani]

+1 everything worked now : )

On Wed, Apr 9, 2008 at 5:40 AM, Dan Becker <[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-RC3a/
> >
> >
> +1
>
> Working from your zip package at the above site, I was able to unzip, ant
> build and run the calculator sample. At least we know 3 + 2= 5.0!
>
> Doing an svn update and mvn  build, I had no trouble working in Eclipse.
>
> --
> Thanks, Dan Becker
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Unable to create a distributed SCA binding provider for reference: currencyConverter

[Luciano Resende]

I was having a similar issue with catalog-webapp, you might need to
start the domain admin and start the currency converter service ?

Runing from a distribution, you should be able to start the service
with something like  :

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

To access the SCA Manager application, point your Web browser to:
   http://localhost:9990/ui/cloud/

You should then be able to start the service...

Let me finish the fixes to 1.2 RC and I'll give this a try and provide
a more concrete feedback here.


On Tue, Apr 8, 2008 at 6:03 AM, Antollini, Mario
<[EMAIL PROTECTED]> wrote:
> Hello,
>
>
>
>  I am trying to run the tutorial but I get the following error when
>  executing the tutorial/web-services/catalogs.composite from Eclipse:
>
>
>
>  Apr 8, 2008 9:46:54 AM
>  org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
>  problem
>  WARNING: Component reference target not found, it might be a remote
>  service: CurrencyConverterWebService
>  Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
>  Exception starting node
>  org.apache.tuscany.sca.node.NodeException:
>  org.apache.tuscany.sca.core.assembly.ActivationException:
>  java.lang.IllegalStateException: Unable to create a distributed SCA
>  binding provider for reference: currencyConverter and target:
>  CurrencyConverterWebService
> at
>  org.apache.tuscany.sca.node.impl.SCANodeImpl.startComposites(SCANodeImpl
>  .java:491)
> at
>  org.apache.tuscany.sca.node.impl.SCANodeImpl.start(SCANodeImpl.java:253)
> at
>  org.apache.tuscany.sca.node.launch.SCANodeLauncher.main(SCANodeLauncher.
>  java:51)
>  Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
>  java.lang.IllegalStateException: Unable to create a distributed SCA
>  binding provider for reference: currencyConverter and target:
>  CurrencyConverterWebService
> at
>  org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(Com
>  positeActivatorImpl.java:745)
>
>
>
>  I am trying to test the store-market module, so, what I am doing is:
>
>  1 - I successfully started tutorial/web-services/currency.composite from
>  Eclipse
>
>  2 - I want to execute tutorial/web-services/catalogs.composite and I get
>  the mentioned error.
>
>
>
>  Can someone give me a hint of what I am doing wrong? I did not modify
>  anything within tutorial/web-services so I assume everything is OK.
>  However I did check the names of the components and references within
>  the composites and they are OK.
>
>
>
>  Thanks and regards,
>
>
>
>
>
>  Mario E. Antollini
>  Intel Software
>  ASDC
>  +54 351 526 5594
>  [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-2212) SCA Java builds are getting very large

[Luciano Resende (JIRA)]

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

Luciano Resende commented on TUSCANY-2212:
--

To generate deptotal

cd sca
mvn -o -Pdependencies -Dmaven.test.skip=true 
find . -name dependency.txt -exec cat '{}' >> deptotal.txt \;

> SCA Java builds are getting very large
> --
>
> Key: TUSCANY-2212
> URL: https://issues.apache.org/jira/browse/TUSCANY-2212
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Build System
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> As discussed on the ML SCA Java builds are getting very large. See 
> http://apache.markmail.org/message/u7ebawcoicyqi55a
> Current size for me is 1.5GB so this jira is to track fixes to reduce that. 
> Looking at the build and repo there's here's some things OTTOMH to start with:
> - the distribution build copies the distros to the target-last-successful 
> folder. this is only needed for the continuum build and adds 120MB 
> - where ever JMS is used the ActiveMQ default is persistence=true which adds 
> about 50MB for the dbs, changing to persistence=false avoids that
> - a large amount of the mvn repository size is webapp samples but we don't 
> need these installed into the mvn repo, is there a way to prevent that 
> happening? 
>  
>   
>   

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


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

Re: How do you plug in validation monitoring?

[Simon Laws]

On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

>
>
> On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
> >
> > I am on revision 634808. The ContributionServiceImpl has changed since
> > then,
> > and with the one that i have, it would lead through the
> > CompositeProcessor
> > instead of the CompositeDocumentProcessor. Hence the difference in
> > exceptions..
> >
> > Also, dont you think that with the error that you got should throw an
> > exception with schema validation, rather than just a warning?
> >
> > Hasan
> >
> > On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Hi Simon,
> > > >
> > > > Thank you for the good information. First up i am trying to verify
> > > whether
> > > > the schema validation works when we point to our schemas. Can you
> > let me
> > > > know what is a simple error that i can introduce so that i can
> > verify
> > > > this?
> > > > I tried doing this to my composite file (In block red):
> > > >
> > > >  
> > > > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > > >**
> > > >
> > > >
> > > >  
> > > >
> > > > This resulted in the following exception, but i think this is part
> > of
> > > the
> > > > validation done by artifact processor and would result even if we
> > > comment
> > > > out the schema validation.
> > > >
> > > >
> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > > > Unexpected  element found. It should appear inside a
> > 
> > > or
> > > >  element
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> > > >at
> > > >
> > > >
> > >
> > org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
> > > >at
> > > >
> > > >
> > >
> > com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
> > > >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 at 5:56 AM, Simon Laws <
> > [EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > On Mon, Apr 7, 2008 at 4:33 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > > wrote:
> > > > >
> > > > > > Currently, i see that we have various places where we can plug
> > in
> > > > > > validation
> > > > > > monitoring. Some of the ones that i found are in the
> > > > > > ReallySmallRuntimeBuilder as shown below:
> > > > > >
> > > > > >public static CompositeBuilder
> > > > createCompositeBuilder(AssemblyFactory
> > > > > > assemblyFactory,
> > > > > >
> > > > >  SCABindingFactory
> > > > > > scaBindingFactory,
> > > > > >
> > > > > > IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> > > > > >
> > > > > > InterfaceContractMapper interfaceContractMapper,
> > > > > >
> > > >  List
> > > > > > domainPolicySets) {
> > > > > >return new CompositeBuilderImpl(assemblyFactory,
> > > > > scaBindingFactory,
> > > > > > 

Re: SCA 2.0, was Re: Next SCA release

[Simon Laws]

On Wed, Apr 9, 2008 at 5:03 PM, ant elder <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <[EMAIL PROTECTED]> wrote:
> >
> > > +1 on versioning SCA docs
> > >
> > > Assuming two versions of SCA Java, I can see that the following page
> > will
> > > change to point to two different versions of SCA Java, 1.x and 2.x and
> > > their
> > > related documentation.
> > >
> > >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> > >
> > > Tuscany SCA Java general page would contain general information that
> > would
> > > pertain to both versions. So, it might need to change.
> > > http://incubator.apache.org/tuscany/sca-java.html
> > >
> > > On the left navigation of sca-java page, we would have two boxes
> > > SCA Java 2.x
> > > SCA Java 1.x
> > >
> > > each would point to their own releases and their own documentations
> and
> > > source code tree.
> > >
> > > There is a set of documentations under SCA Java that are generic, like
> > > development guide. We could share these pages between the two
> versions.
> > >
> > > Does this make sense?
> > >
> > >
> > Generally make sense to me.
> >
> > On the particular question of where to host V2  and V2 docs we have
> > identified 3 choices so far.
> >
> > 1 - [] Put V2 doc changes in V1 pages and mark them as such
> > 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> > current
> > site wiki
> > 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
> >
> > Are there other cunning options we need to consider. I'm for option 2 at
> > the
> > current time.
> >
> > Simon
> >
>
> How would that option [2] actually work?
>
> Lets say I change the way the dwr binding works and want to update the doc
> for V2, the current wiki page is at
> http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what
> would
> i do for the new v2 page?
>
>   ...ant


You would make
http://incubator.apache.org/tuscany/sca-java-v2-bindingajax.html.
Copy the existing contents there. Edit them which whatever change you need
to make and and then add a link to this page to the V2 index (which I expect
will, by default, link to the existing pages).

Simon

Re: [jira] Commented: (TUSCANY-2212) SCA Java builds are getting very large

[ant elder]

Thats a handy report, how do you generate it?

   ...ant

On Wed, Apr 9, 2008 at 4:45 PM, Simon Laws (JIRA) 
wrote:

>
>[
> https://issues.apache.org/jira/browse/TUSCANY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587242#action_12587242]
>
> Simon Laws commented on TUSCANY-2212:
> -
>
> Here is the list of dependencies from the latest trunk (
> http://people.apache.org/~slaws/deptotal.htm
> ).
>
> Not as bad as it was but we do, for example, depend on 3 versions of
> xerces and jaxb.
>
> > SCA Java builds are getting very large
> > --
> >
> > Key: TUSCANY-2212
> > URL: https://issues.apache.org/jira/browse/TUSCANY-2212
> > Project: Tuscany
> >  Issue Type: Improvement
> >  Components: Build System
> >Affects Versions: Java-SCA-Next
> >Reporter: ant elder
> > Fix For: Java-SCA-Next
> >
> >
> > As discussed on the ML SCA Java builds are getting very large. See
> http://apache.markmail.org/message/u7ebawcoicyqi55a
> > Current size for me is 1.5GB so this jira is to track fixes to reduce
> that.
> > Looking at the build and repo there's here's some things OTTOMH to start
> with:
> > - the distribution build copies the distros to the
> target-last-successful folder. this is only needed for the continuum build
> and adds 120MB
> > - where ever JMS is used the ActiveMQ default is persistence=true which
> adds about 50MB for the dbs, changing to persistence=false avoids that
> > - a large amount of the mvn repository size is webapp samples but we
> don't need these installed into the mvn repo, is there a way to prevent that
> happening?
> >
> >
> >
>
> --
> 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: SCA 2.0, was Re: Next SCA release

[ant elder]

On Wed, Apr 9, 2008 at 4:56 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <[EMAIL PROTECTED]> wrote:
>
> > +1 on versioning SCA docs
> >
> > Assuming two versions of SCA Java, I can see that the following page
> will
> > change to point to two different versions of SCA Java, 1.x and 2.x and
> > their
> > related documentation.
> >
> >
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
> >
> > Tuscany SCA Java general page would contain general information that
> would
> > pertain to both versions. So, it might need to change.
> > http://incubator.apache.org/tuscany/sca-java.html
> >
> > On the left navigation of sca-java page, we would have two boxes
> > SCA Java 2.x
> > SCA Java 1.x
> >
> > each would point to their own releases and their own documentations and
> > source code tree.
> >
> > There is a set of documentations under SCA Java that are generic, like
> > development guide. We could share these pages between the two versions.
> >
> > Does this make sense?
> >
> >
> Generally make sense to me.
>
> On the particular question of where to host V2  and V2 docs we have
> identified 3 choices so far.
>
> 1 - [] Put V2 doc changes in V1 pages and mark them as such
> 2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our
> current
> site wiki
> 3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces
>
> Are there other cunning options we need to consider. I'm for option 2 at
> the
> current time.
>
> Simon
>

How would that option [2] actually work?

Lets say I change the way the dwr binding works and want to update the doc
for V2, the current wiki page is at
http://incubator.apache.org/tuscany/sca-java-bindingajax.html so what would
i do for the new v2 page?

   ...ant

Re: SCA 2.0, was Re: Next SCA release

[Simon Laws]

On Wed, Apr 9, 2008 at 4:47 PM, haleh mahbod <[EMAIL PROTECTED]> wrote:

> +1 on versioning SCA docs
>
> Assuming two versions of SCA Java, I can see that the following page will
> change to point to two different versions of SCA Java, 1.x and 2.x and
> their
> related documentation.
>
> http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html
>
> Tuscany SCA Java general page would contain general information that would
> pertain to both versions. So, it might need to change.
> http://incubator.apache.org/tuscany/sca-java.html
>
> On the left navigation of sca-java page, we would have two boxes
> SCA Java 2.x
> SCA Java 1.x
>
> each would point to their own releases and their own documentations and
> source code tree.
>
> There is a set of documentations under SCA Java that are generic, like
> development guide. We could share these pages between the two versions.
>
> Does this make sense?
>
>
Generally make sense to me.

On the particular question of where to host V2  and V2 docs we have
identified 3 choices so far.

1 - [] Put V2 doc changes in V1 pages and mark them as such
2 - [] Create SCA Java 1.x/ SCA Java 2.x documentation pages on our current
site wiki
3 - [] Create separate SCA Java 1.x/ SCA Java 2.x wiki spaces

Are there other cunning options we need to consider. I'm for option 2 at the
current time.

Simon

[jira] Commented: (TUSCANY-2212) SCA Java builds are getting very large

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-2212:
-

Here is the list of dependencies from the latest trunk 
(http://people.apache.org/~slaws/deptotal.htm).

Not as bad as it was but we do, for example, depend on 3 versions of xerces and 
jaxb. 

> SCA Java builds are getting very large
> --
>
> Key: TUSCANY-2212
> URL: https://issues.apache.org/jira/browse/TUSCANY-2212
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Build System
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> As discussed on the ML SCA Java builds are getting very large. See 
> http://apache.markmail.org/message/u7ebawcoicyqi55a
> Current size for me is 1.5GB so this jira is to track fixes to reduce that. 
> Looking at the build and repo there's here's some things OTTOMH to start with:
> - the distribution build copies the distros to the target-last-successful 
> folder. this is only needed for the continuum build and adds 120MB 
> - where ever JMS is used the ActiveMQ default is persistence=true which adds 
> about 50MB for the dbs, changing to persistence=false avoids that
> - a large amount of the mvn repository size is webapp samples but we don't 
> need these installed into the mvn repo, is there a way to prevent that 
> happening? 
>  
>   
>   

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

[haleh mahbod]

+1 on versioning SCA docs

Assuming two versions of SCA Java, I can see that the following page will
change to point to two different versions of SCA Java, 1.x and 2.x and their
related documentation.

http://incubator.apache.org/tuscany/tuscany-downloads-documentations.html

Tuscany SCA Java general page would contain general information that would
pertain to both versions. So, it might need to change.
http://incubator.apache.org/tuscany/sca-java.html

On the left navigation of sca-java page, we would have two boxes
SCA Java 2.x
SCA Java 1.x

each would point to their own releases and their own documentations and
source code tree.

There is a set of documentations under SCA Java that are generic, like
development guide. We could share these pages between the two versions.

Does this make sense?

On 4/9/08, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker <[EMAIL PROTECTED]> wrote:
>
> > ant elder wrote:
> >
> > > On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > We may need to branch the documentation also. Normally I would suggest
> > > that
> > >
> > > > we ask for a new space but as our documentation could not be
> > > > considered
> > > > complete for 1.1 and as the suggested first actions are internal
> > > > restructuring we may find it less onerous to maintain 2.X documents
> > > > alongside the the 1.X documents with suitable comments to point out
> > > > where
> > > > they diverge. Do people have a preference.
> > > >
> > > >
> > > >  I wondered about the doc too, if there was a new wiki space for 2.x
> > > could it
> > > be initially be populated with the existing content? If so then it
> seems
> > > to
> > > me like it would be easiest to have the new space than to try point
> out
> > > the
> > > differences for each release all in the one space.
> > >
> >
> >
> > +1 on versioning and branching the docs and the wikis. Customers on
> older
> > levels will want to see the proper docs, configs, and samples for their
> > version, and customers on newer levels will want to see proper docs,
> > configs, and samples for their version. We should support them both.
> >
> > (This is also how the Geronimo team is tacking docs and samples.)
> >
> > --
> > Thanks, Dan Becker
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> If the concensus is for a completely separate space then it would seem
> that
> we need a new space to hold just Java SCA V2 docs (The current site space
> holds all the pages for all of the Tuscany projects).  Maybe we want to
> reorganize along the same lines as Geronimo e.g. multiple spaces such as
>
> Apache Tuscany - our current site wiki
> Apache Tuscany SCA Java V1
> Apache Tuscany SCA Java V2
>
> I still slightly favour creating a "V2 Documentation" page on the existing
> wiki and populate it as and when required for the time being though.
>
> Simon
>

Re: Next SCA release

[Simon Laws]

>
>
> Was going to start separate threads for each item related to those but do
> think its helpful to keep a thread going with a high level summary like
> this.
>
>   ...ant
>


+1 If we keep this thread going with the high level shopping list and spin
of threads for the detail we have a chance of spotting where people have
complimentary/conflicting objectives.

Simon

Re: Next SCA release

[ant elder]

On Wed, Apr 9, 2008 at 3:47 PM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Tue, Apr 8, 2008 at 8:55 AM, ant elder <[EMAIL PROTECTED]> wrote:
>
> > With 1.2 almost out the door how about starting to think about our next
> > release...
> >
> > We've had several discussions in the past about restructuring and
> cleaning
> > up the distributions, build, and SPIs etc, is this the time to do that?
> > Looking about the code there's many things that could be tidied up but
> > we've
> > been leaving them to keep backward compatibility, if we start this type
> of
> > thing now it will make the next release not backward compatible so we
> need
> > to agree this is the right time. We could make a new 1.x branch to use
> as
> > a
> > maintenance branch for the previous releases so we can still get fixes
> out
> > for them.
> >
> > Leaving aside for now any detail about what the clean up and breaking
> > changes might be what do you all think about doing this in the next
> > release?
> > I think its the right time so am in favour of starting this.
> >
> >   ...ant
> >
>
> Ant
>
> Now discussion of the prospect of moving to 1.X and 2.X releases has moved
> to a separate thread [1] was your intention to separately start
> enumerating
> the burning issues that we feel would be too disruptive in the context of
> a
> 1.X release.
>
> An issue that has been on my mind is that I think it would be useful to
> restructure the way that the runtime is started so, instead of relying on
> the black box ReallySmallRuntime to perform explicit module configuration,
> we could provide the registry to each module and let it configure itself.
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30209.html
>


Was first hoping for a few more responses to help judge if there was much
consensus to do this type of thing in the next release, i know several
people out out at conferences etc at the moment but ok here's some of the
things I think it would be good to try to do:

- module cleanup

- spi cleanup

- runtime restructure

- distribution restructure

I guess the ReallySmallRuntime  change you mention could go in the runtime
restructure bit. There's probably also things we could do with the web 2.0
extensions (jsonrpc / dwr / taglibs / impl.web / impl.widget) to be a bit
more consistent but i'm a bit unclear in my own mind to talk about that just
yet.

Was going to start separate threads for each item related to those but do
think its helpful to keep a thread going with a high level summary like
this.

   ...ant

Re: Unable to create a distributed SCA binding provider for reference: currencyConverter

[Simon Laws]

On Tue, Apr 8, 2008 at 2:03 PM, Antollini, Mario <[EMAIL PROTECTED]>
wrote:

> Hello,
>
>
>
> I am trying to run the tutorial but I get the following error when
> executing the tutorial/web-services/catalogs.composite from Eclipse:
>
>
>
> Apr 8, 2008 9:46:54 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBuilderImpl$1
> problem
> WARNING: Component reference target not found, it might be a remote
> service: CurrencyConverterWebService
> Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
> Exception starting node
> org.apache.tuscany.sca.node.NodeException:
> org.apache.tuscany.sca.core.assembly.ActivationException:
> java.lang.IllegalStateException: Unable to create a distributed SCA
> binding provider for reference: currencyConverter and target:
> CurrencyConverterWebService
>at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.startComposites(SCANodeImpl
> .java:491)
>at
> org.apache.tuscany.sca.node.impl.SCANodeImpl.start(SCANodeImpl.java:253)
>at
> org.apache.tuscany.sca.node.launch.SCANodeLauncher.main(SCANodeLauncher.
> java:51)
> Caused by: org.apache.tuscany.sca.core.assembly.ActivationException:
> java.lang.IllegalStateException: Unable to create a distributed SCA
> binding provider for reference: currencyConverter and target:
> CurrencyConverterWebService
>at
> org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.activate(Com
> positeActivatorImpl.java:745)
>
>
>
> I am trying to test the store-market module, so, what I am doing is:
>
> 1 - I successfully started tutorial/web-services/currency.composite from
> Eclipse
>
> 2 - I want to execute tutorial/web-services/catalogs.composite and I get
> the mentioned error.
>
>
>
> Can someone give me a hint of what I am doing wrong? I did not modify
> anything within tutorial/web-services so I assume everything is OK.
> However I did check the names of the components and references within
> the composites and they are OK.
>
>
>
> Thanks and regards,
>
>
>
>
>
> Mario E. Antollini
> Intel Software
> ASDC
> +54 351 526 5594
> [EMAIL PROTECTED] 
>
>
>
>
Hi Mario

What version of Tuscany are you working with? The errors you have here refer
to the old version of the domain/node support and I think Sebastien has
updated the tutorial to use the new workspace based approach. Let me know
what version you are on and how you are starting the nodes and we can work
from there.

Regards

Simon

Re: Next SCA release

[Simon Laws]

On Tue, Apr 8, 2008 at 8:55 AM, ant elder <[EMAIL PROTECTED]> wrote:

> With 1.2 almost out the door how about starting to think about our next
> release...
>
> We've had several discussions in the past about restructuring and cleaning
> up the distributions, build, and SPIs etc, is this the time to do that?
> Looking about the code there's many things that could be tidied up but
> we've
> been leaving them to keep backward compatibility, if we start this type of
> thing now it will make the next release not backward compatible so we need
> to agree this is the right time. We could make a new 1.x branch to use as
> a
> maintenance branch for the previous releases so we can still get fixes out
> for them.
>
> Leaving aside for now any detail about what the clean up and breaking
> changes might be what do you all think about doing this in the next
> release?
> I think its the right time so am in favour of starting this.
>
>   ...ant
>

Ant

Now discussion of the prospect of moving to 1.X and 2.X releases has moved
to a separate thread [1] was your intention to separately start enumerating
the burning issues that we feel would be too disruptive in the context of a
1.X release.

An issue that has been on my mind is that I think it would be useful to
restructure the way that the runtime is started so, instead of relying on
the black box ReallySmallRuntime to perform explicit module configuration,
we could provide the registry to each module and let it configure itself.

Simon

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

Re: STP SCA Component -> STP SCA Tools sub project

[ant elder]

+1, good for both projects. And to reply to a comment in the original email
- I'm not sure that we really need an explicit vote for this can just assume
from all the positive comments so far and lazy consensus that its fine
unless someone complains (which i'm sure they wont).

   ...ant

On Tue, Apr 8, 2008 at 5:17 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> This proposal looks good to me.  I'd be happy to see the
> Apache Tuscany project listed as an interested party.
>
>  Simon
>
>
> Stéphane Drapeau wrote:
>
> > Hi,
> >
> > I created an entry [0] in the Eclipse bugzilla with the proposal.
> > Your comments are welcome.
> >
> > Best regards
> >
> > Stéphane Drapeau
> > Obeo
> >
> > [0]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=225956
> >
> > On Thu, Apr 3, 2008 at 11:10 AM, Stéphane Drapeau <[EMAIL PROTECTED]>
> > wrote:
> >
> >  Haleh, Raymond,
> > >
> > > Thank you for your answers.
> > >
> > > Haleh, you're right. I make no distinction between tools for SCA
> > > developers and tools for SCA users. The goal of the project is to
> > > develop
> > > tools to help users of the SCA technology. I will modify my sentence.
> > >
> > > Stéphane Drapeau
> > > Obeo
> > >
> > >
> > > On Thu, Apr 3, 2008 at 6:21 AM, haleh mahbod <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > >  Hi Stephan,
> > > >
> > > > This looks good since it looks like tools for SCA will get more
> > > > focus :)
> > > > I have a question.
> > > >
> > > > You mention "the goals of the new sub-project are to develop a set
> > > > of
> > > > tools for SCA developers and SCA users".
> > > >
> > > > What is the difference between SCA developer and SCA user in this
> > > > context?
> > > >
> > > > Haleh
> > > >
> > > > On 4/2/08, Stéphane Drapeau <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Hi Jean-Sebastien, Haleh, all,
> > > > >
> > > > > The proposal is a 3 pages document describing the scope/intent of
> > > > > the
> > > > > proposed project.
> > > > >
> > > > > The outline is:
> > > > > 1. Introduction: the proposition of the transformation of the
> > > > > STP/SCA
> > > > > component into a sub-project named SCA Tools under the top level
> > > > >
> > > > project
> > > >
> > > > > STP.
> > > > > 2. Background: presentation of STP + presentation of the existing
> > > > >
> > > > STP/SCA
> > > >
> > > > > component.
> > > > > 3. Description: the goals of the new sub-project are to develop a
> > > > > set
> > > > >
> > > > of
> > > >
> > > > > tools for SCA developers and SCA users. Another goal is also to
> > > > > link
> > > > >
> > > > this
> > > >
> > > > > sub-project with other components of STP (Service Creation, Policy
> > > > >
> > > > Editor)
> > > >
> > > > > 4. Proposed components: SCA Domain Model (SCA meta model), SCA
> > > > >
> > > > Composite
> > > >
> > > > > Designer, SCA Composite Editors (tree, xml and form), SCA
> > > > > Integration
> > > > > (integration with other STP components)
> > > > > 5. Relationship with Other Eclipse Projects: STP, EMF, GMF, M2M,
> > > > > ...
> > > > > 6. Organization: this sub-project will take place under the top
> > > > > level
> > > > > project STP.
> > > > > 7. A list of proposed initial committers.
> > > > > 8. Code Contribution: the Eclipse STP/SCA component will be the
> > > > >
> > > > initial
> > > >
> > > > > code.
> > > > > 9. Interested parties: this section lists companies and
> > > > > communities
> > > > >
> > > > that
> > > >
> > > > > support the creation of the project. They don't take other
> > > > >
> > > > engagements.
> > > >
> > > > > 10. Tentative Plan for 2008 and 2009.
> > > > >
> > > > > Our goal is to identify formally the scope of the tools that we
> > > > >
> > > > develop
> > > >
> > > > > around SCA. The new status will provide some advantages.
> > > > > - I think that the SCA tools will be more visible in the Eclipse
> > > > >
> > > > community
> > > >
> > > > > if we are identified as a sub-project.
> > > > > - From the users point of view, it will not change anything.
> > > > > - Concerning us, we should be more formal: clear roadmap, new
> > > > > features
> > > > > described/discussed first in bugzilla, ...
> > > > > - It will also present some advantages for Obeo by becoming a
> > > > >
> > > > sub-project
> > > >
> > > > > leader.
> > > > >
> > > > > In the near future all STP components will become STP
> > > > > sub-projects. To
> > > > > summarize, all of this is purely administrative.
> > > > > I will send you the proposal document ASAP.
> > > > > If you have any questions, don't hesitate.
> > > > >
> > > > > Haleh, yesterday I sent you more information about the SCA
> > > > > Composite
> > > > > Designer on the thread named "[Website] - Tooling for Java SCA".
> > > > > You
> > > > >
> > > > can
> > > >
> > > > > add
> > > > > it on the web page. Tell me if you need more/different
> > > > > information.
> > > > > My post describes what version of Tuscany can be used. I also
> > > > >
> > > > introduce a
> > > >
> > > > > tutorial that I made. This tu

[jira] Commented: (TUSCANY-2212) SCA Java builds are getting very large

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2212:


- clean up use of multiple releases of dependencies by different modules
some of the dependencies are several meg  and we use several diff releases 
- jaxb-xjc, derby, xerces, saxon, cleaning this up would reduce the size and 
speed up builds from an empty repo   

> SCA Java builds are getting very large
> --
>
> Key: TUSCANY-2212
> URL: https://issues.apache.org/jira/browse/TUSCANY-2212
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Build System
>Affects Versions: Java-SCA-Next
>Reporter: ant elder
> Fix For: Java-SCA-Next
>
>
> As discussed on the ML SCA Java builds are getting very large. See 
> http://apache.markmail.org/message/u7ebawcoicyqi55a
> Current size for me is 1.5GB so this jira is to track fixes to reduce that. 
> Looking at the build and repo there's here's some things OTTOMH to start with:
> - the distribution build copies the distros to the target-last-successful 
> folder. this is only needed for the continuum build and adds 120MB 
> - where ever JMS is used the ActiveMQ default is persistence=true which adds 
> about 50MB for the dbs, changing to persistence=false avoids that
> - a large amount of the mvn repository size is webapp samples but we don't 
> need these installed into the mvn repo, is there a way to prevent that 
> happening? 
>  
>   
>   

-- 
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 (RC3a)

[Dan Becker]

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-RC3a/



+1

Working from your zip package at the above site, I was able to unzip, 
ant build and run the calculator sample. At least we know 3 + 2= 5.0!


Doing an svn update and mvn  build, I had no trouble working in Eclipse.

--
Thanks, Dan Becker

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

[jira] Closed: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2092.
--

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

Applied in r646335, thanks for the fix Ramkumar!

> ConcurrentModificationException in ExtensibleContributionListener
> -
>
> Key: TUSCANY-2092
> URL: https://issues.apache.org/jira/browse/TUSCANY-2092
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Greg Dritschler
>Assignee: ant elder
> Fix For: Java-SCA-Next
>
> Attachments: JIRA-2092.patch
>
>
> java.util.ConcurrentModificationException
>   at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
>   at 
> org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> The problem occurs if two threads try to add a contribution simultaneously.
> DefaultContributionListenerExtensionPoint does not synchronize the list of 
> listeners.  In particular loadListeners does not prevent multiple threads 
> from trying to load the list of listeners.  One thread completes first while 
> the other is still loading.  This leads to the exception shown above when a 
> thread tries to iterate the listener list.

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


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

[jira] Assigned: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener

[ant elder (JIRA)]

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

ant elder reassigned TUSCANY-2092:
--

Assignee: ant elder  (was: Ramkumar Ramalingam)

> ConcurrentModificationException in ExtensibleContributionListener
> -
>
> Key: TUSCANY-2092
> URL: https://issues.apache.org/jira/browse/TUSCANY-2092
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Greg Dritschler
>Assignee: ant elder
> Attachments: JIRA-2092.patch
>
>
> java.util.ConcurrentModificationException
>   at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
>   at 
> org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> The problem occurs if two threads try to add a contribution simultaneously.
> DefaultContributionListenerExtensionPoint does not synchronize the list of 
> listeners.  In particular loadListeners does not prevent multiple threads 
> from trying to load the list of listeners.  One thread completes first while 
> the other is still loading.  This leads to the exception shown above when a 
> thread tries to iterate the listener list.

-- 
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 (RC3a)

[sebb]

On 09/04/2008, 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-RC3a/
>

L&N look O; digests and sigs OK.

Extraneous files:
---
Do the following really belong in the source archive?
They are not in SVN.

itest/transaction/derbydb/
modules/osgi-runtime/.felix/

Various automatically generated test cases (e.g.
InteropDatabindingTestCase.java)

===

Odd file:
---
OSGiRuntimeTestCase.java in
modules\implementation-osgi\src\test\java\org\apache\tuscany\sca\implementation\osgi\runtime
is completely empty.

Minor points:

BUILDING mentions using Java 1.5.0_06 and Maven 2.0.5. Both of these
have been superseded; perhaps the text should mention that later
versions are OK as well (unless they are not; the text is not clear
about this).

Manifests
--
It would be nice to have the java compiler source and target versions
in all the binary jars.

It would be nice to have the Specification and Implementation headers
in all the manifests, as is done
inrg.apache.tuscany.sca.core-1.2-incubating.jar

>
>  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-RC3a/updatesite/
>

-1:
org.apache.tuscany.sca.feature-1.2-incubating.jar and
org.apache.tuscany.sca.core-1.2-incubating.jar NOTICE says:
${pom.name}
Copyright (c) 2005 - 2008 The Apache Software Foundation

The first line is wrong in both.

-1:
Also, the top-level NOTICE file in the archive does not have the same
attributions
as in the org.apache.tuscany.sca.core-1.2-incubating.jar.
The overall NOTICE file should contain all subordinate attributions.


>  The release tag is available at :
>  http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC3a/
>
>
>  Looks OK to me, here is my +1.
>
>
>  --
>  Luciano Resende
>  Apache Tuscany Committer
>  http://people.apache.org/~lresende
>  http://lresende.blogspot.com/
>

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

Tuscany Java SCA 1.2-incubating (RC3a) - SVN issues

[sebb]

There are a lot of .java (and other) files in SVN without the correct
eol-style:native settings.

Also some files incorrectly have executable:*

I've created a script that can be used to fix these; try to run it on
the same OS as was last used to update the files to reduce the SVN
mail noise.

See the file tuscany-sca-1.2-RC3a.sh in:

http://people.apache.org/~sebb/SVNfixes/

Just rename as .cmd to use on Windows.

The same script should probably be applied to trunk.

S///

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

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

[Giorgio Zoppi]

Luciano databinding-job should not included in sca-1.2 because it's
useless at this moment.



2008/4/9, Luciano Resende <[EMAIL PROTECTED]>:
> 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-RC3a/
>
>
>  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-RC3a/updatesite/
>
>  The release tag is available at :
>  http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC3a/
>
>
>  Looks OK to me, here is my +1.
>
>  --
>  Luciano Resende
>  Apache Tuscany Committer
>  http://people.apache.org/~lresende
>  http://lresende.blogspot.com/
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

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

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

[Simon Laws]

On Wed, Apr 9, 2008 at 4:57 AM, 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-RC3a/
>
>
> 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-RC3a/updatesite/
>
> The release tag is available at :
> http://svn.apache.org/repos/asf/incubator/tuscany/tags/java/sca/1.2-RC3a/
>
>
> Looks OK to me, here is my +1.
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende 
> http://lresende.blogspot.com/
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Luciano

I ran a few samples (WinXP, IBM JDK5, Tomcat 6). The only issue I found I've
recorded here (https://issues.apache.org/jira/browse/TUSCANY-2214) but it's
to do with an external web site not being available so It's not a blocker
from my point of view. We may want to reconsider the use of this site in the
future though.

LICENSES/NOTICES look OK to me except that
tuscany-node2-launcher-webapp-1.2-incubating.war still appears in the maven
repo [1] (without NOTICE/LICENSE files). If you take this out of the repo
I'll be +1 for the release.

Simon

[1]
http://people.apache.org/~lresende/tuscany/sca-1.2-RC3a/maven/org/apache/tuscany/sca/tuscany-node2-launcher-webapp/

[jira] Created: (TUSCANY-2214) xml-bigbank demo relies on http://www.swanandmokashi.com which is not (currently) available

[Simon Laws (JIRA)]

xml-bigbank demo relies on http://www.swanandmokashi.com  which is not 
(currently) available


 Key: TUSCANY-2214
 URL: https://issues.apache.org/jira/browse/TUSCANY-2214
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Demos
Affects Versions: Java-SCA-1.2
 Environment: WinXP SP2, IBM JDK5
Reporter: Simon Laws
Priority: Minor
 Fix For: Java-SCA-1.2


demo/xml-bingbank fails with the error below because the web site the demo is 
trying to contact is not (currently) available to me. It may be temporary or 
may be permanent. At a minimum we should note in the README that this can 
happen and that the demo will not work it this is the case. 


ant run
Buildfile: build.xml

run:
 [java] 09-Apr-2008 13:06:11 org.apache.tuscany.sca.contribution.processor.E
xtensibleStAXArtifactProcessor read
 [java] WARNING: Element {http://tuscany.apache.org/xmlns/sca/1.0}binding.rs
s cannot be processed. ([row,col {unknown-source}]: [34,13])
 [java] [Fatal Error] StockQuotes.asmx?WSDL:1:133: The element type "META" m
ust be terminated by the matching end-tag "".
 [java] Exception in thread "main" org.osoa.sca.ServiceRuntimeException: jav
a.lang.RuntimeException: org.apache.tuscany.sca.contribution.service.Contributio
nReadException: javax.wsdl.WSDLException: WSDLException (at /wsdl:definitions/ws
dl:import): faultCode=PARSER_ERROR: Problem parsing 'http://www.swanandmokashi.c
om/HomePage/WebServices/StockQuotes.asmx?WSDL'.: org.xml.sax.SAXParseException:
The element type "META" must be terminated by the matching end-tag "".
 [java] at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInsta
nce(SCADomain.java:264)
 [java] at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SC
ADomain.java:69)
 [java] at bigbank.BigBankClient.main(BigBankClient.java:30)
 [java] Caused by: java.lang.RuntimeException: org.apache.tuscany.sca.contri
bution.service.ContributionReadException: javax.wsdl.WSDLException: WSDLExceptio
n (at /wsdl:definitions/wsdl:import): faultCode=PARSER_ERROR: Problem parsing 'h
ttp://www.swanandmokashi.com/HomePage/WebServices/StockQuotes.asmx?WSDL'.: org.x
ml.sax.SAXParseException: The element type "META" must be terminated by the matc
hing end-tag "".
 [java] at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolve
r.loadOnDemand(WSDLModelResolver.java:290)
 [java] at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolve
r.aggregate(WSDLModelResolver.java:223)
 [java] at org.apache.tuscany.sca.interfacedef.wsdl.xml.WSDLModelResolve
r.resolveModel(WSDLModelResolver.java:256)
 [java] at org.apache.tuscany.sca.contribution.resolver.ExtensibleModelR
esolver.resolveModel(ExtensibleModelResolver.java:150)
 [java] at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProces
sor.resolve(WebServiceBindingProcessor.java:269)
 [java] at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProces
sor.resolve(WebServiceBindingProcessor.java:59)
 [java] at org.apache.tuscany.sca.contribution.processor.DefaultStAXArti
factProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifac
tProcessorExtensionPoint.java:252)
 [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXA
rtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
 [java] at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.res
olveContracts(BaseAssemblyProcessor.java:362)
 [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolv
e(CompositeProcessor.java:822)
 [java] at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolv
e(CompositeProcessor.java:80)
 [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXA
rtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:109)
 [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcesso
r.resolve(CompositeDocumentProcessor.java:138)
 [java] at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcesso
r.resolve(CompositeDocumentProcessor.java:53)
 [java] at org.apache.tuscany.sca.contribution.processor.ExtensibleURLAr
tifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:86)
 [java] at org.apache.tuscany.sca.contribution.service.impl.Contribution
ServiceImpl.processResolvePhase(ContributionServiceImpl.java:464)
 [java] at org.apache.tuscany.sca.contribution.service.impl.Contribution
ServiceImpl.addContribution(ContributionServiceImpl.java:348)
 [java] at org.apache.tuscany.sca.contribution.service.impl.Contribution
ServiceImpl.contribute(ContributionServiceImpl.java:161)
 [java] at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.ad
dContribution(DefaultSCADomain.jav

[jira] Commented: (TUSCANY-2085) ConcurentModExc in DefaultDataBindingExtensionPoint

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam commented on TUSCANY-2085:
--

To prevent ConcurrentModificationException, one way is to lock the entire List 
while you are iterating by wrapping it with a synchronized block, which inturn 
looks costly as the this would block the other thread to access the list for 
reading.

A better solution i would consider for the above problem would be, using 
CopyOnWriteArrayList class from util.concurrent (which will also appear in the 
java.util.concurrent package in JDK 1.5) is a thread-safe implementation of 
ArrayList that offers far better concurrency. Multiple reads can almost always 
execute concurrently, simultaneous reads and writes can usually execute 
concurrently, and multiple simultaneous writes can often execute concurrently. 
Also CopyOnWriteArrayList contains a mutable reference to an immutable array, 
so as long as that reference is held fixed, you get all the thread-safety 
benefits of immutability without the need for locking.

The code change required would be just to replace the ArrayList with 
CopyOnWriteArrayList:

private final List databindings = new 
CopyOnWriteArrayList();

> ConcurentModExc in DefaultDataBindingExtensionPoint 
> 
>
> Key: TUSCANY-2085
> URL: https://issues.apache.org/jira/browse/TUSCANY-2085
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Data Binding Runtime
>Affects Versions: Java-SCA-1.1
>Reporter: Scott Kurz
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: 2085.patch
>
>
> Get an exception like the following, 
> java.util.ConcurrentModificationException
> at java.util.AbstractList$SimpleListIterator.next(Unknown Source)at 
> org.apache.tuscany.sca.databinding.DefaultDataBindingExtensionPoint.introspectType(DefaultDataBindingExtensionPoint.java:223)
> at 
> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSFaultExceptionMapper.introspectFaultDataType(JAXWSFaultExceptionMapper.java:214)
> at 
> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.introspectFaultTypes(JAXWSJavaInterfaceProcessor.java:178)
> at 
> org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.visitInterface(JAXWSJavaInterfaceProcessor.java:90)
> at 
> org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:91)
> as this thread, A, is in a for-loop looping through 'databindings'
>  public boolean introspectType(DataType dataType, Annotation[] annotations, 
> boolean isException) {
> loadDataBindings();
> for (DataBinding binding : databindings) {
> while another thread, B, is still in loadDataBindings() and is still adding 
> to the databindings ArrayList.
> I'm working around this by putting a lock around the whole body  of 
> loadDataBindings()
> private final byte[] loadingLock = new byte[0];
> ...
> private void loadDataBindings() {
> synchronized (loadingLock) {
> if (loadedDataBindings)
> return;
>...
>}
>}
> Another option might be to change addDataBinding() to look at the 'bindings' 
> Map before adding to 'databindings'.   
> I'll attach a patch and leave it for a second opinion.  

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


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

Re: How do you plug in validation monitoring?

[Simon Laws]

On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:

> Hi Simon,
>
> I am on revision 634808. The ContributionServiceImpl has changed since
> then,
> and with the one that i have, it would lead through the CompositeProcessor
> instead of the CompositeDocumentProcessor. Hence the difference in
> exceptions..
>
> Also, dont you think that with the error that you got should throw an
> exception with schema validation, rather than just a warning?
>
> Hasan
>
> On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
> >
> > > Hi Simon,
> > >
> > > Thank you for the good information. First up i am trying to verify
> > whether
> > > the schema validation works when we point to our schemas. Can you let
> me
> > > know what is a simple error that i can introduce so that i can verify
> > > this?
> > > I tried doing this to my composite file (In block red):
> > >
> > >  
> > > > class="mysca.test.myservice.impl.MyServiceImpl"/>
> > >**
> > >
> > >
> > >  
> > >
> > > This resulted in the following exception, but i think this is part of
> > the
> > > validation done by artifact processor and would result even if we
> > comment
> > > out the schema validation.
> > >
> > > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > > Unexpected  element found. It should appear inside a
> 
> > or
> > >  element
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> > >at
> > >
> > >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> > >at
> > >
> > >
> >
> com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> > >at
> > >
> > >
> >
> com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> > >at
> > >
> > >
> >
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> > >at
> > >
> > >
> >
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> > >at
> > >
> > >
> >
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
> > >at
> > >
> > >
> >
> com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
> > >at
> > >
> > >
> >
> com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
> > >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 at 5:56 AM, Simon Laws <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Mon, Apr 7, 2008 at 4:33 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > Currently, i see that we have various places where we can plug in
> > > > > validation
> > > > > monitoring. Some of the ones that i found are in the
> > > > > ReallySmallRuntimeBuilder as shown below:
> > > > >
> > > > >public static CompositeBuilder
> > > createCompositeBuilder(AssemblyFactory
> > > > > assemblyFactory,
> > > > >
> > > >  SCABindingFactory
> > > > > scaBindingFactory,
> > > > >
> > > > > IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> > > > >
> > > > > InterfaceContractMapper interfaceContractMapper,
> > > > >
> > >  List
> > > > > domainPolicySets) {
> > > > >return new CompositeBuilderImpl(assemblyFactory,
> > > > scaBindingFactory,
> > > > > intentAttachPointTypeFactory, interfaceContractMapper,
> > > domainPolicySets,
> > > > > null);
> > > > >}
> > > > >
> > > > >public static DomainBuilder createDomainBuilder(AssemblyFactory
> > > > > assemblyFactory,
> > > > >SCABindingFactory scaBindingFactory,
> > > > >IntentAttachPointTypeFactory
> > intentAttachPointTypeFactory,
> > > > >InterfaceContractMapper interfaceContr

[jira] Updated: (TUSCANY-2092) ConcurrentModificationException in ExtensibleContributionListener

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam updated TUSCANY-2092:
-

Attachment: JIRA-2092.patch

> ConcurrentModificationException in ExtensibleContributionListener
> -
>
> Key: TUSCANY-2092
> URL: https://issues.apache.org/jira/browse/TUSCANY-2092
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Greg Dritschler
>Assignee: Ramkumar Ramalingam
> Attachments: JIRA-2092.patch
>
>
> java.util.ConcurrentModificationException
>   at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
>   at 
> org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> The problem occurs if two threads try to add a contribution simultaneously.
> DefaultContributionListenerExtensionPoint does not synchronize the list of 
> listeners.  In particular loadListeners does not prevent multiple threads 
> from trying to load the list of listeners.  One thread completes first while 
> the other is still loading.  This leads to the exception shown above when a 
> thread tries to iterate the listener list.

-- 
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-2092) ConcurrentModificationException in ExtensibleContributionListener

[Ramkumar Ramalingam (JIRA)]

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

Ramkumar Ramalingam commented on TUSCANY-2092:
--

Using Vectors OR Collections.synchronizedList for listeners synchronizes your 
list object. However, the iterators implemented in the java.util Collections 
classes are fail-fast, which means that if one thread changes a collection 
while another thread is traversing it through an Iterator, the next 
Iterator.hasNext() or Iterator.next() call will throw 
ConcurrentModificationException. If we have to prevent 
ConcurrentModificationException, we must lock the entire List while you are 
iterating by wrapping it with a synchronized block, which inturn is costly.

A better solution to the above problem seems to be, the CopyOnWriteArrayList 
class from util.concurrent (which will also appear in the java.util.concurrent 
package in JDK 1.5) is a thread-safe implementation of ArrayList that offers 
far better concurrency. Multiple reads can almost always execute concurrently, 
simultaneous reads and writes can usually execute concurrently, and multiple 
simultaneous writes can often execute concurrently. Also CopyOnWriteArrayList 
contains a mutable reference to an immutable array, so as long as that 
reference is held fixed, you get all the thread-safety benefits of immutability 
without the need for locking.

I have attached a patch using the above solution to this issue.

> ConcurrentModificationException in ExtensibleContributionListener
> -
>
> Key: TUSCANY-2092
> URL: https://issues.apache.org/jira/browse/TUSCANY-2092
> Project: Tuscany
>  Issue Type: Bug
>Reporter: Greg Dritschler
>Assignee: Ramkumar Ramalingam
> Attachments: JIRA-2092.patch
>
>
> java.util.ConcurrentModificationException
>   at java.util.AbstractList$SimpleListIterator.next(Unknown Source)
>   at 
> org.apache.tuscany.sca.contribution.service.ExtensibleContributionListener.contributionAdded(ExtensibleContributionListener.java:40)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:389)
>   at 
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> The problem occurs if two threads try to add a contribution simultaneously.
> DefaultContributionListenerExtensionPoint does not synchronize the list of 
> listeners.  In particular loadListeners does not prevent multiple threads 
> from trying to load the list of listeners.  One thread completes first while 
> the other is still loading.  This leads to the exception shown above when a 
> thread tries to iterate the listener list.

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


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

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

[Mark Combellack (JIRA)]

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

Mark Combellack commented on TUSCANY-2213:
--

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

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

> Cannot Serialize and deserailize a CallableReference injected using a 
> @Callback - Is this a valid use case?
> ---
>
> Key: TUSCANY-2213
> URL: https://issues.apache.org/jira/browse/TUSCANY-2213
> Project: Tuscany
>  Issue Type: Task
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: svn trunk revision 645821
> Linux
>Reporter: Mark Combellack
>Assignee: Mark Combellack
>Priority: Minor
> Fix For: Java-SCA-Next
>
>
> I've got a bidirectional Service that uses @Callback to inject a 
> CalalbleReference 
> When a method is called on the Service, I Serialise and then deserialise the 
> CallableReference before it is used to invoke the client. I do this to 
> simulate persisting the CallableReference and then using it again later.
> The stack trace I get is:
> java.io.IOException
>   at 
> org.apache.tuscany.sca.core.context.CallableReferenceImpl.writeExternal(CallableReferenceImpl.java:361)
>   at 
> java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310)
>   at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288)
>   at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
>   at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
>   at 
> org.apache.tuscany.sca.itest.servicereference.utils.ServiceReferenceUtils.serialize(ServiceReferenceUtils.java:57)
>   at 
> org.apache.tuscany.sca.itest.servicereference.StatelessServiceImpl.triggerCallback(StatelessServiceImpl.java:70)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy14.triggerCallback(Unknown Source)
>   at 
> org.apache.tuscany.sca.itest.servicereference.SCAManagedClientImpl.testSerializeCallbackToStatelessServiceInsideSCA(SCAManagedClientImpl.java:126)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:109)
>   at 
> org.apache.tuscany.sca.binding.sca.impl.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:286)
>   at 
> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:154)
>   at $Proxy13.testSerializeCallbackToStatelessServiceInsideSCA(Unknown 
> Source)
>   at 
> org.apache.tuscany.sca.itest.servicereference.SerializeServiceReferenceTestCase.testSerializeCallbackToStatelessServiceInsideSCA(SerializeServiceReferenceTestCase.java:103)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:585)
>   at 
> org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99)
>   at 
> org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81)
>   at 
> org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
>   at 
> org.junit.internal.runners

Re: What are my chances of being able to "inherit" behaviour from implementation.java?

[Mike Edwards]

Folks,

implementation.spring has many of the same dependencies.  Once you have 
an implementation type that is based on Java classes in some way, then 
you end up needing a lot of the same mechanics that is there in 
implementation.java



Yours,  Mike.


Rajini Sivaram wrote:

implementation.osgi and implementation.spring reuse introspection code from
implementation.java. Both of these can avoid dependencies on
implementation.java if the introspection/injection code is refactored to
provide a proper SPI.



On 3/4/08, Matthew Peters <[EMAIL PROTECTED]> wrote:

Bad form to reply to my own posting I know but I wanted to ask: can or
should I raise this as formal requirement in some manner? It seems to me
that I won't be the only one who wants an architected way to reuse the
functionality from  - anything that is like a
servlet, in being both a java class and something else at the same time,
might want to do so.

Matthew Peters




Matthew Peters/UK/[EMAIL PROTECTED]
29/02/2008 17:50
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?






Hi Jean-Sebastien, thanks for a fast response.

What I am most interested in is the introspection and the ability to drive

injection. Life cycle and invocation on the other hand are not a concernt
because servlets have a very defined lifecycle and ideally that should all

be looked after by the web container.

Here is an example:

The .composite file might look like this:
   
  
  
   ...

   

   
   
   

And with the servlet containing a setter for the reference, so looking for

all the world like a java component in this respect
   @Reference
   public void setCatalogService(Catalog catalogService) {
   this.catalogService = catalogService;
   }
   private Catalog catalogService;

Yet doing something special with some of the properties, presenting them
as servlet init parameters, or example. So, I'm interested in:

1, introspection for references and properties
2. driving injection for references
3. driving injecttion for some properties
4. not doing injection for some other properties but doing something
different for them


Matthew Peters




Jean-Sebastien Delfino <[EMAIL PROTECTED]>
29/02/2008 16:51
Please respond to
tuscany-dev@ws.apache.org


To
tuscany-dev@ws.apache.org
cc

Subject
Re: What are my chances of being able to "inherit" behaviour from
implementation.java?






Matthew Peters wrote:

Suppose I wanted to create a new implementation that shared much of the
behaviour of  and then added a bit. Suppose I

wanted

to make  for example, to be an implementation

that

did what  does WRT understanding @Reference and

@Property

and getters and setters, but did some extra - for example looked in the
web.xml file for the servlet and added some extra properties. How could

I

architect this to take advantage of all the code that already exists
within the support for ?

Matthew Peters


We may need to refactor some of that function to make it available to
others as a proper SPI. Could you describe the bits you'd want to reuse
in more details?

- some of the implementation model?

- introspection of a Java class and creation of the corresponding
componentType model?

- injection of properties and references?

- invocation? I guess it's different here as a servlet has a fixed
interface pattern?

- anything else?

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

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

[Mark Combellack (JIRA)]

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

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


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

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

The stack trace I get is:

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

Re: Python and Service Component Architecture.

[Simon Laws]

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

Re: How do you plug in validation monitoring?

[Hasan Muhammad]

Hi Simon,

I am on revision 634808. The ContributionServiceImpl has changed since then,
and with the one that i have, it would lead through the CompositeProcessor
instead of the CompositeDocumentProcessor. Hence the difference in
exceptions..

Also, dont you think that with the error that you got should throw an
exception with schema validation, rather than just a warning?

Hasan

On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws <[EMAIL PROTECTED]>
wrote:

> On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
>
> > Hi Simon,
> >
> > Thank you for the good information. First up i am trying to verify
> whether
> > the schema validation works when we point to our schemas. Can you let me
> > know what is a simple error that i can introduce so that i can verify
> > this?
> > I tried doing this to my composite file (In block red):
> >
> >  
> > class="mysca.test.myservice.impl.MyServiceImpl"/>
> >**
> >
> >
> >  
> >
> > This resulted in the following exception, but i think this is part of
> the
> > validation done by artifact processor and would result even if we
> comment
> > out the schema validation.
> >
> > org.apache.tuscany.sca.contribution.service.ContributionReadException:
> > Unexpected  element found. It should appear inside a 
> or
> >  element
> >at
> >
> >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
> >at
> >
> >
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
> >at
> >
> >
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
> >at
> >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
> >at
> >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
> >at
> >
> >
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
> >at
> >
> >
> com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
> >at
> >
> >
> com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
> >at
> >
> >
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
> >at
> >
> >
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
> >at
> >
> >
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
> >at
> >
> >
> com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
> >at
> >
> >
> com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
> >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 at 5:56 AM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Mon, Apr 7, 2008 at 4:33 PM, Hasan Muhammad <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > Currently, i see that we have various places where we can plug in
> > > > validation
> > > > monitoring. Some of the ones that i found are in the
> > > > ReallySmallRuntimeBuilder as shown below:
> > > >
> > > >public static CompositeBuilder
> > createCompositeBuilder(AssemblyFactory
> > > > assemblyFactory,
> > > >
> > >  SCABindingFactory
> > > > scaBindingFactory,
> > > >
> > > > IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> > > >
> > > > InterfaceContractMapper interfaceContractMapper,
> > > >
> >  List
> > > > domainPolicySets) {
> > > >return new CompositeBuilderImpl(assemblyFactory,
> > > scaBindingFactory,
> > > > intentAttachPointTypeFactory, interfaceContractMapper,
> > domainPolicySets,
> > > > null);
> > > >}
> > > >
> > > >public static DomainBuilder createDomainBuilder(AssemblyFactory
> > > > assemblyFactory,
> > > >SCABindingFactory scaBindingFactory,
> > > >IntentAttachPointTypeFactory
> intentAttachPointTypeFactory,
> > > >InterfaceContractMapper interfaceContractMapper,
> > > >List domainPolicySets) {
> > > >return new DomainWireBuilderImpl(assemblyFactory,
> > > > scaBindingFactory,
> > > > intentAttachPointTypeFactory, interfaceContractMapper,
> > domainPolicySets,
> > > > null);
> > > >}
> > > >
> > > > Instead of passing null, we can pass in our own
> CompositeBuildMonitor.
> > > Are
> > > > these the only places where we need to do 

Re: SCA 2.0, was Re: Next SCA release

[Simon Laws]

On Tue, Apr 8, 2008 at 6:57 PM, Dan Becker <[EMAIL PROTECTED]> wrote:

> ant elder wrote:
>
> > On Tue, Apr 8, 2008 at 6:11 PM, Simon Laws <[EMAIL PROTECTED]>
> > wrote:
> >
> > We may need to branch the documentation also. Normally I would suggest
> > that
> >
> > > we ask for a new space but as our documentation could not be
> > > considered
> > > complete for 1.1 and as the suggested first actions are internal
> > > restructuring we may find it less onerous to maintain 2.X documents
> > > alongside the the 1.X documents with suitable comments to point out
> > > where
> > > they diverge. Do people have a preference.
> > >
> > >
> > >  I wondered about the doc too, if there was a new wiki space for 2.x
> > could it
> > be initially be populated with the existing content? If so then it seems
> > to
> > me like it would be easiest to have the new space than to try point out
> > the
> > differences for each release all in the one space.
> >
>
>
> +1 on versioning and branching the docs and the wikis. Customers on older
> levels will want to see the proper docs, configs, and samples for their
> version, and customers on newer levels will want to see proper docs,
> configs, and samples for their version. We should support them both.
>
> (This is also how the Geronimo team is tacking docs and samples.)
>
> --
> Thanks, Dan Becker
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

If the concensus is for a completely separate space then it would seem that
we need a new space to hold just Java SCA V2 docs (The current site space
holds all the pages for all of the Tuscany projects).  Maybe we want to
reorganize along the same lines as Geronimo e.g. multiple spaces such as

Apache Tuscany - our current site wiki
Apache Tuscany SCA Java V1
Apache Tuscany SCA Java V2

I still slightly favour creating a "V2 Documentation" page on the existing
wiki and populate it as and when required for the time being though.

Simon

Python and Service Component Architecture.

[Giorgio Zoppi]

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]

Re: How do you plug in validation monitoring?

[Simon Laws]

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):
>
>  
>
>**
>
>
>  
>
> This resulted in the following exception, but i think this is part of the
> validation done by artifact processor and would result even if we comment
> out the schema validation.
>
> org.apache.tuscany.sca.contribution.service.ContributionReadException:
> Unexpected  element found. It should appear inside a  or
>  element
>at
>
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:373)
>at
>
> org.apache.tuscany.sca.assembly.xml.CompositeProcessor.read(CompositeProcessor.java:75)
>at
>
> org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.read(ExtensibleStAXArtifactProcessor.java:83)
>at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processReadPhase(ContributionServiceImpl.java:475)
>at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:383)
>at
>
> org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:202)
>at
>
> com.ibm.ws.soa.sca.runtime.impl.DomainCompositeHelper.addContribution(DomainCompositeHelper.java:75)
>at
>
> com.ibm.ws.soa.sca.runtime.impl.SCAContainerComponentImpl.startComposite(SCAContainerComponentImpl.java:235)
>at
>
> com.ibm.ws.soa.sca.admin.runtime.tuscany.SCATuscanyRuntimeHandlerImpl.startModule(SCATuscanyRuntimeHandlerImpl.java:125)
>at
>
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:349)
>at
>
> com.ibm.ws.soa.sca.admin.runtime.impl.SCARuntimeImpl.start(SCARuntimeImpl.java:446)
>at
>
> com.ibm.ws.runtime.component.CompositionUnitMgrImpl.start(CompositionUnitMgrImpl.java:331)
>at
>
> com.ibm.ws.runtime.component.CompositionUnitImpl.start(CompositionUnitImpl.java:126)
>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 at 5:56 AM, Simon Laws <[EMAIL PROTECTED]>
> wrote:
>
> > On Mon, Apr 7, 2008 at 4:33 PM, Hasan Muhammad <[EMAIL PROTECTED]> wrote:
> >
> > > Currently, i see that we have various places where we can plug in
> > > validation
> > > monitoring. Some of the ones that i found are in the
> > > ReallySmallRuntimeBuilder as shown below:
> > >
> > >public static CompositeBuilder
> createCompositeBuilder(AssemblyFactory
> > > assemblyFactory,
> > >
> >  SCABindingFactory
> > > scaBindingFactory,
> > >
> > > IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> > >
> > > InterfaceContractMapper interfaceContractMapper,
> > >
>  List
> > > domainPolicySets) {
> > >return new CompositeBuilderImpl(assemblyFactory,
> > scaBindingFactory,
> > > intentAttachPointTypeFactory, interfaceContractMapper,
> domainPolicySets,
> > > null);
> > >}
> > >
> > >public static DomainBuilder createDomainBuilder(AssemblyFactory
> > > assemblyFactory,
> > >SCABindingFactory scaBindingFactory,
> > >IntentAttachPointTypeFactory intentAttachPointTypeFactory,
> > >InterfaceContractMapper interfaceContractMapper,
> > >List domainPolicySets) {
> > >return new DomainWireBuilderImpl(assemblyFactory,
> > > scaBindingFactory,
> > > intentAttachPointTypeFactory, interfaceContractMapper,
> domainPolicySets,
> > > null);
> > >}
> > >
> > > Instead of passing null, we can pass in our own CompositeBuildMonitor.
> > Are
> > > these the only places where we need to do this? or are there other
> > places
> > > as
> > > well?
> > >
> > > Hasan
> > >
> >
> > Hi Hasan
> >
> > There are a few places that logically we need to be able to validate
> input
> > and hence add monitors. The story is changing a little as we are moving
> > toward the new "workspace"  code for managing contributions but
> logically
> > I
> > would expect to be running validating on at least the following
> >
> > - Contribution processing
> >   - dependency (imports/exports) analysis
> >
> >
> [org.apache.tuscany.sca.workspace.builder.impl.ContributionDependencyBuilderImpl]
> > - Composite read
> >   - schema compliance
> >
> >
> [org.apache.tuscany.sca.contribution.processor.DefaultValidatingXMLInputFactory
> > - only appears to be initialized in ReallySmallRuntimeBuilder so need 

Re: java.lang.SecurityException: class "com.sun.xml.bind.DatatypeConverterImpl"'s signer information does not match signer information

[Simon Laws]

On Wed, Apr 9, 2008 at 7:45 AM, Nishant Joshi <[EMAIL PROTECTED]>
wrote:

> Hi All,
> Is anybody has faced this error before...?
> I m using Tuscany 1.2-incubating RC3
>
> java.lang.SecurityException: class
> "com.sun.xml.bind.DatatypeConverterImpl"'s signer information does not
> match
> signer information of other classes in the same package
>at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)
>at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)
>at java.lang.ClassLoader.defineClass(ClassLoader.java:614)
>at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
>at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
>at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
>at java.security.AccessController.doPrivileged(Native Method)
>at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
>at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>at
>
> com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:258)
>at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:139)
>at
> com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:117)
>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 javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:211)
>at javax.xml.bind.ContextFinder.find(ContextFinder.java:372)
>at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:574)
>at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:522)
>at
>
> org.apache.tuscany.sca.databinding.jaxb.JAXBContextHelper.createJAXBContext(JAXBContextHelper.java:59)
> --
> Thanks
> Nishant Joshi
>

Hi Nishant

On the face of it this looks like a classpath error where classes from the
same package are bring picked up from differently signed jars, e.g. [1].
What are you running from RC3 and how are you running it?

Regards

Simon

[1] http://forum.java.sun.com/thread.jspa?threadID=647962&messageID=3834232

[jira] Commented: (TUSCANY-2209) Question about Conversational OSGi Services and Service References

[Daniel Stucky (JIRA)]

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

Daniel Stucky commented on TUSCANY-2209:


Hi Rajini,

I just tested your fix and I'm not able to reproduce the former errors. 
Everything seems to work fine now !
Thanks for your help and the quick fix.

Bye,
Daniel

> Question about Conversational OSGi Services and Service References
> --
>
> Key: TUSCANY-2209
> URL: https://issues.apache.org/jira/browse/TUSCANY-2209
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-1.2
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10 
>Reporter: Daniel Stucky
>Assignee: Rajini Sivaram
> Attachments: OneWay_Conversation_OSGi_SCA_test.zip
>
>
> For an overview of the problem please check this thread on the mailing-list: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html

-- 
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-2109) Conflicts between component reference interface and promoted composite reference interface are not detected

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-2109:
-

Hi wangfeng

I've applied the patch locally and taken SimonN's test from here and created an 
itest. The changes you have made to the assembly builders to introduce 
interface compatibility tests look good (although, as an aside, we may need to 
revisit the exception throwing in light of the ongoing discussion on monitoring 
of builder faults) but currently the code in 
InterfaceContractMapper.checkCompatibility doesn't perform a namespace 
compatibility test so the change doesn't fix the problem reported. Do you have 
more changes to added to this?

SimonL

> Conflicts between component reference interface and promoted composite 
> reference interface are not detected 
> 
>
> Key: TUSCANY-2109
> URL: https://issues.apache.org/jira/browse/TUSCANY-2109
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-1.1
> Environment: All
>Reporter: Simon Nash
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: jira2109.patch, jira2109.zip
>
>
> See TUSCANY-2033 for the background to this problem.
> When a component reference defined with  (either explicitly 
> or implicitly by introspection) is promoted to a composite reference defined 
> with , and there is a namespace conflict between the 
> component reference's  and the composite reference's 
> . this conflict should be diagnosed as an error because it 
> violates the spec rule that an interface specified on a composite reference 
> must be a compatible superset of the interface of the promoted component 
> reference. In this case, the composite interface is incompatible with the 
> component reference because it has a different namespace.
> There is code in CompositeWireBuilderImpl.connectCompositeReferences() to 
> handle connections between composite references and promoted compoennt 
> references. The only interface processing performed in this method is to copy 
> the component reference's interface contract to the composite reference's 
> interface contract if the composite reference does not have an interface 
> contract. Code should be added here to check for conflicts between the 
> composite reference's interface and the component reference's interface if 
> both interfaces are specified.
> Similar code should be added to 
> CompositeWireBuilderImpl.connectCompositeServices() to check that the 
> composite service interface is a compatible subset of the component service 
> interface as required by the spec. 

-- 
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-2209) Question about Conversational OSGi Services and Service References

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram commented on TUSCANY-2209:
-

Daniel,

I think you were seeing three instances of Gamma being created because the 
first instance was created before the annotations were processed, due to a race 
in OSGiImplementationProvider.startBundle, which is not synchronized. I have 
committed a fix under revision 646232. Could you try it out?

Thank you.


> Question about Conversational OSGi Services and Service References
> --
>
> Key: TUSCANY-2209
> URL: https://issues.apache.org/jira/browse/TUSCANY-2209
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-1.2
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10 
>Reporter: Daniel Stucky
>Assignee: Rajini Sivaram
> Attachments: OneWay_Conversation_OSGi_SCA_test.zip
>
>
> For an overview of the problem please check this thread on the mailing-list: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html

-- 
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: SCA Java builds are getting very large

[ant elder]

On Sat, Feb 16, 2008 at 11:48 PM, Simon Nash <[EMAIL PROTECTED]> wrote:

> It isn't long since I could do a complete checkout and build of
> Tuscany SCA Java in around 400 MB of disk space.  Today I was amazed
> when I ran out of space despite having cleared over a gigabyte
> before starting.
>
> I tend to keep a few builds around for various reasons and the
> space factor is rapidly becoming more and more of an inhibitor to my
> development productivity.  The full checkout and build that I did
> a week ago occupied 718 MB on disk.  Today's version weighs in at a
> hefty 1020 MB.  I've done some digging around, and there's nothing
> that seems very easy to eliminate.  The biggest files are webapp
> samples and ActiveMQ logs.
>
> This size explosion adds more weight to the evidence that we need to
> split up the codebase into more modular chunks that can be built and
> tested independently.
>
>  Simon
>

To do a complete build of trunk now takes 1.5GB of disk space on my machine,
thats for the trunk src build folder and the local maven repository. As part
of the cleanup being talked about for the next release I'd like to try to
reduce this a lot, i've raised TUSCANY-2212 to track this, if you've any
ideas to help please feel free to add a comment/help.

   ...ant

[jira] Created: (TUSCANY-2212) SCA Java builds are getting very large

[ant elder (JIRA)]

SCA Java builds are getting very large
--

 Key: TUSCANY-2212
 URL: https://issues.apache.org/jira/browse/TUSCANY-2212
 Project: Tuscany
  Issue Type: Improvement
  Components: Build System
Affects Versions: Java-SCA-Next
Reporter: ant elder
 Fix For: Java-SCA-Next


As discussed on the ML SCA Java builds are getting very large. See 
http://apache.markmail.org/message/u7ebawcoicyqi55a

Current size for me is 1.5GB so this jira is to track fixes to reduce that. 

Looking at the build and repo there's here's some things OTTOMH to start with:

- the distribution build copies the distros to the target-last-successful 
folder. this is only needed for the continuum build and adds 120MB 
- where ever JMS is used the ActiveMQ default is persistence=true which adds 
about 50MB for the dbs, changing to persistence=false avoids that
- a large amount of the mvn repository size is webapp samples but we don't need 
these installed into the mvn repo, is there a way to prevent that happening? 



 





-- 
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: SCADefinitionsProviderExtensionPoint interface

[Adriano Crestani]

Thanks Venkata,

It seems my trunk is out of date. I'm not sure, because the
org.apache.tuscany.sca.definitions.SCADefinitionsProviderExtensionPoint is
not included on svn files and it's there :S.

I will delete this file anyway ; )

Adriano Crestani

On Tue, Apr 8, 2008 at 10:47 PM, Venkata Krishnan <[EMAIL PROTECTED]>
wrote:

> Hi Adriano,
>
> The SCADefinitionsProviderExtensionPoint  has been moved out of the
> 'definitions' module and into the core-spi module.   So you should not be
> seeing
> org.apache.tuscany.sca.definitions.SCADefinitionsProviderExtensionPoint
> anywhere.  Could you please point me to where you are observing this
> duplication ?  Thanks
>
> - Venkat
>
> On Wed, Apr 9, 2008 at 11:59 AM, Adriano Crestani <
> [EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Can anybody tell me what is the difference between
> > org.apache.tuscany.sca.definitions.SCADefinitionsProviderExtensionPoint
> > and
> > org.apache.tuscany.sca.provider.SCADefinitionsProviderExtensionPoint
> > interface? Because they do have the same methods signature.
> >
> > Thanks in advance for the replies
> >
> > Adriano Crestani
> >
>

Re: policy itest question

[Venkata Krishnan]

Hi Greg,

Please find my comments / answers inline.  Thanks

- Venkat

From: Greg Dritschler <[EMAIL PROTECTED]>
> Date: Apr 8, 2008 7:05 PM
> Subject: Re: policy itest question
> To: tuscany-dev@ws.apache.org
>
> D'oh!  I didn't think to look at the java classes for annotations.  That
> explains a lot.
>
> I agree the itest had some limitations.  In particular I think it would
> catch if the policy handlers were created with the wrong policy sets, but
> it
> didn't verify if some expected policy handlers were not created.


Over here I assume that the expected PolicyHandlers are called.  If there is
no PolicyHandler found for a PolicySet, then that would get flagged.  My
intention was only to verify if the right PolicySets get applied which I
could only verify by checking if the  PolicyHanlder is called with the right
PolicySet.  The simpler option would be to get hold of the Composite just
after its built and verify the PolicySets that have been attached to the
various SCA Artifacts.

But all of this is subject to revisit and change as the PolicyHandler is on
its way out with the arrival of PolicyProviders.  So verifying from handlers
is not going to stay for long.


>
>
> Doesn't the test in the assembly module do read/resolve/build
> testing?  How
> would this be different?  I think the assembly module can't test the full
> inheritance of intents down to implementation or binding given assembly is
> so early in the build.  Would this new test address that?
>

With the assembly module, as you point out rightly, I could just about test
for the inheritance excluding the bindings and implementation extensions.
If this was also to be done in the assembly module there are issues with
pulling in the extensions as dependencies.  So, I'd like to cover more
comprehensive tests here including binding and implementation extensions.
And to do this I intend to do the read, resolve and build explicitly and
verify against the built up composite instead of starting the runtime.  I'd
like to hear if people have objections to this as in all our itests we
typically start up the runtime.


>
> The reason I'm asking about this is that I'm working on the support for
> mutually-exclusive intents and I would like to modify an existing test
> rather than start from scratch.
>

Yes, this makes sense.  We should have all sorts of test for policies in
this itest module.


>
> On Tue, Apr 8, 2008 at 9:20 AM, Venkata Krishnan <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Greg,
> >
> > This itest needs to be re-written after the changes to the
> PolicyHandling
> > story for the java implementation extension.
> >
> > Also I put in this itest to get some cases of policy annotations
> verified
> > at
> > a rudimentary level - like checking to see if the annotations ever get
> > picked up and applied.  IMO, using interceptors for this testing is
> quite
> > ugly and not going to go very far.  I am going to change this to
> > explicitly
> > execute read, resolve and build phases and simply verify against the
> built
> > up composite.
> >
> > Thanks
> >
> > - Venkat
> >
> > On Mon, Apr 7, 2008 at 4:12 AM, Greg Dritschler <
> [EMAIL PROTECTED]
> > >
> > wrote:
> >
> > > What is the status of the policy itest?  It uses the PolicyHandler
> > > interface
> > > to do its verification and that doesn't seem to work anymore, at least
> > for
> > > Java implementations.  (The call to instantiate the
> > > JavaPolicyHandlingRuntimeWireProcessor in JavaRuntimeModuleActivator
> is
> > > commented out.)  Is this itest going to be rewritten?
> > >
> > > I can't say that I understand how this itest was supposed to have
> > worked.
> > > The composite uses only one intent, TestIntent_3, on the
> implementation
> > of
> > > AddServiceComponent.  That intent is provided by one policy set
> > > TestPolicySet_3_implementation.  Yet it looks to me like
> > > TestImplPolicyHandler is quite happy if various other policy sets are
> > > selected, such TestPolicySet_1_implementation or
> > > TestPolicySet_2_implementation.  What's the story?
> > >
> > > Greg Dritschler
> > >
> >
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam

[jira] Assigned: (TUSCANY-2209) Question about Conversational OSGi Services and Service References

[Rajini Sivaram (JIRA)]

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

Rajini Sivaram reassigned TUSCANY-2209:
---

Assignee: Rajini Sivaram

> Question about Conversational OSGi Services and Service References
> --
>
> Key: TUSCANY-2209
> URL: https://issues.apache.org/jira/browse/TUSCANY-2209
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA OSGi Integration
>Affects Versions: Java-SCA-1.2
> Environment: Windows XP SP2, Intel Core 2 CPU, 2.6, 2GB Ram, jdk 
> 1.5.0_10 
>Reporter: Daniel Stucky
>Assignee: Rajini Sivaram
> Attachments: OneWay_Conversation_OSGi_SCA_test.zip
>
>
> For an overview of the problem please check this thread on the mailing-list: 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg02833.html

-- 
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-2162) Spring SCA specification should accomodate common beans/aspects used by different composites/components

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2162:


We (as in Apache Tuscany) can not enhance the actual specification, for that 
you'd need to send feed back to the OASIS committee, you can do that through 
the comments mailing lists - see http://www.oasis-opencsa.org/mailing-lists. 
What we can do in Tuscany is implement additional functionality thats not 
described in a spec and this sounds like it could help with what you want, and 
if we get something working we can then feed that back to OASIS to get the 
specs enhanced.

Could you give a little more detail about what you're proposing, maybe with 
some snippets of code and/or SCDL to demonstrate what you mean? 

> Spring SCA specification should accomodate common beans/aspects used by 
> different composites/components
> ---
>
> Key: TUSCANY-2162
> URL: https://issues.apache.org/jira/browse/TUSCANY-2162
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Java SCA Spring Implementation Extension
>Reporter: Catalin Boloaja
>
> The use case : service composites using components or composites as Spring 
> beans. Those beans rely on other injected common beans or applied aspects.
> We should not instantiate a new bean or aspect for every Spring component or 
> composite if the beans and aspects are shared .
> The Spring way would be to declare a parent context to accommodate the common 
> beans / aspects.
> The Spring SCA implementation specification says a new Spring context will be 
> created for each composite. Unclear for component.
> Can we enhance the specification in the sense of a parent application context 
> ?

-- 
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-1802) RMI Implementation Error Handling lost inner exception's detail information

[Simon Laws (JIRA)]

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

Simon Laws commented on TUSCANY-1802:
-

Great. Thanks Venkat. Sorry for the confusion. 

> RMI Implementation Error Handling lost inner exception's detail information
> ---
>
> Key: TUSCANY-1802
> URL: https://issues.apache.org/jira/browse/TUSCANY-1802
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Java Implementation Extension
>Reporter: Yang Sun
>Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
> Attachments: 1802.patch
>
>
> Here is an email I sent to the tuscany user group. Raymond Feng confirms it 
> may be a potential bug. Please have a look.
> /--
> Hi,
> I am a new user of Tuscany and I am very excited with this great software. I 
> am trying to introduce it into my project and currently I am evaluate it with 
> every possible situations. 
> Currently, I met a small problem with the spring implementation. I am not 
> sure if I understand the background and configure the composites right. 
> Please correct me if I make anything wrong. 
> The problem I met is that I cannot get the detailed original exception when 
> the server-side throw any kinds of exceptions. After a rough looking at the 
> src code and debugging, I see the following code in SpringInvoker.java :
> ---
> private Object doInvoke(Object payload) throws SpringInvocationException {
> if (theMethod == null)
> setupMethod(); 
> if (badInvoker)
> throw new SpringInvocationException("Spring invoker incorrectly 
> configured");
> // Invoke the method on the Spring bean using the payload, returning 
> the results 
> try {
> Object ret;
> if (payload != null && !payload.getClass().isArray()) {
> ret = theMethod.invoke(bean, payload);
> } else {
> ret = theMethod.invoke(bean, (Object[])payload);
> }
> return ret;
> } catch (InvocationTargetException e) {
> throw new SpringInvocationException(e.getMessage());
> } catch (Exception e) { 
> throw new SpringInvocationException(e.getMessage());
> }
> } // end method doInvoke
>  
> When the invoked method throw an exception (checked or unchecked), the 
> program flow will go to the InvocationTargetException exception handler. Then 
> the program only put the message of the original message to the wrapper 
> exception SpringInvocationException. The detailed information of the original 
> exception is missing. I am thinking it is here that will lost the detailed 
> information of the original exception detail. 
> The reason for me to bring this question is that if we cannot get the 
> detailed information of the original exception, how can we deal with the 
> application exceptions (such as NotEnoughMoneyException)? The only thing I 
> can get is the java.lang.reflect.InvocationTargetException wrapped in 
> java.rmi.UnexpectedException. And with those information, I cannot get the 
> right information to make the further decision in the program.
> I am not sure whether I got the right point or if I misunderstand anything. 
> Please give me some suggestions on this problem. 
> Best Regards,
> Yang Sun
> /

-- 
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-2170) Synchronizing the access to SCADefinitions

[Venkatakrishnan (JIRA)]

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

Venkatakrishnan resolved TUSCANY-2170.
--

Resolution: Fixed

Patch applied in r646208.   Thanks for the patch.

> Synchronizing the access to SCADefinitions
> --
>
> Key: TUSCANY-2170
> URL: https://issues.apache.org/jira/browse/TUSCANY-2170
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: SVN revision 642920 - Windows
>Reporter: Ramkumar Ramalingam
>Assignee: Venkatakrishnan
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: SCADefinitionsImpl-JIRA-2170.patch
>
>
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html

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


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

[jira] Assigned: (TUSCANY-2170) Synchronizing the access to SCADefinitions

[Venkatakrishnan (JIRA)]

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

Venkatakrishnan reassigned TUSCANY-2170:


Assignee: Venkatakrishnan

> Synchronizing the access to SCADefinitions
> --
>
> Key: TUSCANY-2170
> URL: https://issues.apache.org/jira/browse/TUSCANY-2170
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core Runtime
>Affects Versions: Java-SCA-Next
> Environment: SVN revision 642920 - Windows
>Reporter: Ramkumar Ramalingam
>Assignee: Venkatakrishnan
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: SCADefinitionsImpl-JIRA-2170.patch
>
>
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html

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


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

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

[ant elder (JIRA)]

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

ant elder commented on TUSCANY-2195:


I'm a bit confused about the difference between the three patches - is it just 
the ComponentContextJira2195.patch from the 7th that needs applying or are the 
other two still relevant as well?

> 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] Resolved: (TUSCANY-2211) New tests for Java @Property annotaion

[Venkatakrishnan (JIRA)]

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

Venkatakrishnan resolved TUSCANY-2211.
--

Resolution: Fixed

Patch and code applied under r646203.   Thanks for this contribution.

> New tests for Java @Property annotaion 
> ---
>
> Key: TUSCANY-2211
> URL: https://issues.apache.org/jira/browse/TUSCANY-2211
> Project: Tuscany
>  Issue Type: Test
>  Components: Java SCA Verification Tests
>Affects Versions: Java-SCA-Next
>Reporter: Gilbert Kwan
>Assignee: Venkatakrishnan
> Attachments: TUSCANY-2211.test.patch, vtest.property.zip
>
>
> New tests for Java Common Annotations and APIs Specification of @Property 
> 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]

[jira] Closed: (TUSCANY-2207) First steps towards Axis MTOM Support

[ant elder (JIRA)]

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

ant elder closed TUSCANY-2207.
--

Resolution: Fixed

Applied. Thanks Giorgio.

> First steps towards Axis MTOM Support 
> --
>
> Key: TUSCANY-2207
> URL: https://issues.apache.org/jira/browse/TUSCANY-2207
> Project: Tuscany
>  Issue Type: New Feature
>Affects Versions: Java-SCA-1.2
>Reporter: Giorgio Zoppi
>Priority: Minor
> Fix For: Java-SCA-Next
>
> Attachments: value.diff
>
>
> This is my first steps towards MTOM support in Tuscany using intent, as it 
> was debated in 
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg26726.html. 
> Currently it supports only client generated communication. I opened this jira 
> for tracking.

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