Hi,
Brady suggested to use CxxTest only on development process and don't
distribute it with the released source. However, whoever wants to modify the
code from a release would want to test it, to check if the modifications
does not compromise the software. So, I suggest to look for another text
[
https://issues.apache.org/jira/browse/TUSCANY-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gengshaoguang updated TUSCANY-1861:
---
Attachment: TM-Related-Object.png
JCAReceiver or JCAMessageListener is responsible for
snip/
Also, I'd like to nominate Raymond to be release manager for this.
+1
...ant
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/TUSCANY-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gengshaoguang updated TUSCANY-1861:
---
Attachment: TM-secquence-in-axis2.png
This diagram shows the invoke/relay secquence of a
Sebastien,
I think we could implement the following classloading changes to Tuscany (in
this order). I will post a more detailed proposal (along with
some questions) based on the feedback.
1. Application classloading - move from a single thread context based
classloader to OSGi-style
I have just committed some enhancements to JSONRPC binding. It should
now be able to work with the Tuscany Databinding framework (I
particulary tested with SDO). I have also added initial code to
support References for the JSONRPC Binding, although this is not
completely finished yet.
Note that
How about changing this to be a completely separate new binding? That way
we'll be able to keep backward compatibility - new users can use the new
extension but people already using binding.jsonrpc from the 1.0 release can
continue to use the old json-rpc-java based extension till they're ready to
Why does the test tool need to be distributed with a Tuscany release?
If the build depends on having the tool available, then I can see some
justification for this, but even then it would be possible for people
who build the source to download the tool separately.
Simon
Adriano Crestani
Rajini Sivaram wrote:
Sebastien,
I think we could implement the following classloading changes to Tuscany (in
this order). I will post a more detailed proposal (along with
some questions) based on the feedback.
1. Application classloading - move from a single thread context based
*An overview of the proposed classloader design for Tuscany*
Thank you for all your emails. Based on your feedback, I would like to
propose a new classloader architecture for Tuscany. I have created new
bundles in OSGi to reflect the kind of classloader-based isolation that we
may like to have,
On 10/20/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
On 10/17/07, Raymond Feng [EMAIL PROTECTED] wrote:
I collected all the input we have so far at the following WIKI page:
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion
Thanks
+1
Raymond, let me know if/how I can help.
On 10/21/07, ant elder [EMAIL PROTECTED] wrote:
On 10/20/07, ant elder [EMAIL PROTECTED] wrote:
On 10/19/07, ant elder [EMAIL PROTECTED] wrote:
We've had a Java SCA release every month for a while now so to keep up
that momentum I
DataObject.delete() should either a). not call unset() on value properties or
b). handle value properties as a special case
---
Key: TUSCANY-1862
[
https://issues.apache.org/jira/browse/TUSCANY-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536641
]
Kelvin Goodson commented on TUSCANY-1853:
-
Hi Czarek, I'm just looking at what to do with this JIRA on
[
https://issues.apache.org/jira/browse/TUSCANY-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-1842:
Patch Info: [Patch Available]
Setting PAtach Available: Ron's suggestion gives us a
Simon,
Comments inline.
Thank you...
Regards,
Rajini
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Rajini Sivaram wrote:
Sebastien,
I think we could implement the following classloading changes to Tuscany
(in
this order). I will post a more detailed proposal (along with
[
https://issues.apache.org/jira/browse/TUSCANY-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536655
]
Kelvin Goodson commented on TUSCANY-1659:
-
Luciano,
can you confirm whether this is still an issue
[
https://issues.apache.org/jira/browse/TUSCANY-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536659
]
Kelvin Goodson commented on TUSCANY-1263:
-
An alternative to using another tool is the approach adopted in
[
https://issues.apache.org/jira/browse/TUSCANY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536660
]
Kelvin Goodson commented on TUSCANY-1178:
-
TODO: given the discussion above, and the unresolved SDO spec
[
https://issues.apache.org/jira/browse/TUSCANY-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1283.
-
Resolution: Fixed
The basis of the plan described above is in place. The split
[
https://issues.apache.org/jira/browse/TUSCANY-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536664
]
Kelvin Goodson commented on TUSCANY-1180:
-
Resolution of this issue is dependent on
[
https://issues.apache.org/jira/browse/TUSCANY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536669
]
Kelvin Goodson commented on TUSCANY-1192:
-
Note, related to this issue is that
[
https://issues.apache.org/jira/browse/TUSCANY-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson updated TUSCANY-152:
---
Component/s: (was: Java SDO Implementation)
Java SDO Tools
Java SDO
Hi,
I need to add/remove dynamically a reference to another component. For
example i've configured a component MyComponentA in a node:
public class MyComponentA implements ComponentA
{
private OtherService serviceA;
@Reference
public void seOtherService(OtherService wService) {
Distributed Workpool Sample over Distributed SCA Bindings
-
Key: TUSCANY-1863
URL: https://issues.apache.org/jira/browse/TUSCANY-1863
Project: Tuscany
Issue Type: New Feature
[
https://issues.apache.org/jira/browse/TUSCANY-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Giorgio Zoppi updated TUSCANY-1863:
---
Attachment: wp.zip
Distributed Workpool Sample over Distributed SCA Bindings
[
https://issues.apache.org/jira/browse/TUSCANY-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-1206:
Attachment: 1206.a.patch
This is a patch created against r558780. It is, for a few reasons,
OK... so at least it sounds reasonable ;) I attached a patch a the
r558780 level to TUSCANY-1206 to keep the discussion going.It could
really use some careful review from you, Raymond, at least, and some rework
is needed to the newest code level, as this is pretty old.
There are some
Thanks for these clarifications. One question inline below.
Simon
Rajini Sivaram wrote:
Simon,
Comments inline.
Thank you...
Regards,
Rajini
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Rajini Sivaram wrote:
Sebastien,
I think we could implement the following classloading
[
https://issues.apache.org/jira/browse/TUSCANY-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende reassigned TUSCANY-1337:
Assignee: Luciano Resende
The JSONRPC biding fails when transforming SDO to
[
https://issues.apache.org/jira/browse/TUSCANY-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1337.
--
Resolution: Fixed
Fixed under revision #587029.
More details on this thread :
The upgrade process is very harmless, two line of code, one for the js
reference and another for the reference declaration. Also, seems like
there are some bugs on the scaDomain.js [1] that would not happen
while using the manual reference. I also think that, having the two
very similar bindings
Thanks for all your work on progressing this. Comments inline.
Simon
Rajini Sivaram wrote:
*An overview of the proposed classloader design for Tuscany*
Thank you for all your emails. Based on your feedback, I would like to
propose a new classloader architecture for Tuscany. I have created
Hi Simon,
Yes, you are right, I forgot this option, there is no problem to distribute
the unit test source code :P. But anyway, the list contained on the web site
I could be helpful :)
Regards,
Adriano Crestani
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Why does the test tool need to be
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Thanks for these clarifications. One question inline below.
Simon
Rajini Sivaram wrote:
Simon,
Comments inline.
Thank you...
Regards,
Rajini
On 10/22/07, Simon Nash [EMAIL PROTECTED] wrote:
Rajini Sivaram
Venkata Krishnan wrote:
Hi,
To me, option (1) seems to be viable given that we want to call on a vote on
Wednesday. We'd have better control pushing pieces from the trunk over to
the branch until the time for cutting an RC.
This makes sense to me. As I understand it, this is a small
Hi,
As it was originally proposed, we'll do a SCA Java 1.0.1 release using the
1.0 branch as the base line. The 1.0.1 is intended to be a bug fix release
and it should contain only non-disruptive changes. The approach we take is
to pull post-1.0 commits of incremental bug fixes from the trunk
Raymond Feng wrote:
Hi,
I did a brief counting of changes we made into trunk after the 1.0
release. There are around 170 commits with 1560 total file changes.
What's the best way to decide what commits should be pulled into SCA
java 1.0.1?
I see a few options on the table:
1) Starting
Simon Nash wrote:
I just posted a proposal to tuscany-dev for fixing TUSCANY-1849
without breaking interoperability. If we do this, I think it would
be better to defer this change until Tuscany SCA 1.1 as it would
involve adding a new protocol versioning mechanism as well as fixing
the actual
I have two questions.
[snip]
Rajini Sivaram wrote:
We have the following bundles in Tuscany - the names in brackets refer to
maven module names
1. SCA API (sca-api)
2. Tuscany SPI (core-spi, assembly, contribution, policy, interface,
interface-java, interface-wsdl, databinding)
3.
ant elder wrote:
On 10/20/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Simon Laws wrote:
On 10/17/07, Raymond Feng [EMAIL PROTECTED] wrote:
I collected all the input we have so far at the following WIKI page:
[snip]
ant elder wrote:
Also, I'd like to nominate Raymond to be release manager for this.
...ant
+1 from me
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
[snip]
Venkata Krishnan wrote:
Hi Raymond,
Please see my comments inline.
Also, now that you are with this, may I request your views on the problem
that I am facing with attaching intents and policysets on implementation
model instances. Presently, atleast for the JavaImplementation model
Hi Raymond,
I nominated the fixes that add ant scripts to the notification samples,
which did not quite make it into the 1.0 release. Depending on one's point
of view, these fixes may/ma not be considered bug fixes, so feel free not
to include them, but they are small an non-disruptive enough,
See [1] for the OASIS thread, and [2] for the Tuscany thread that agreed
on the incorrect use of wsa:To. The proposal to use wsa:To was a mistake
on my part. I completely missed the statement in the WS-Addressing spec
that wsa:To is a URI, unline wsa:From and wsa:EeplyTo which are endpoint
Hi,
I have a few comments:
1) I think it's out of 1.0.1 release considering TUSCANY-1849 is too big for
a point release.
2) Can you explain why we need to have tuscany:SOAPExtensions/ in the
WSDL? I'm not keen on requiring extensions on WSDLs as it doesn't work with
existing WSDLs and
Antollini, Mario wrote:
Jean-Sebastien, Raymond,
Thanks for the feedback. I modified the figure accordingly.
What do you both think now?
Regards,
Mario
Thanks Mario.
I guess we should work on the various parts of the application:
- the catalog component with a hardcoded list of items
-
The Tuscany maven-wsdl2java and maven-java2wsdl modules depend on
maven-plugin-api 2.0. This is really old. I'm going to change them to
depend on maven-plugin-api 2.0.4.
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL
Now that http://issues.apache.org/jira/browse/TUSCANY-1846 is fixed. Can
we re-enable the build of implementation-bpel and add it back to
modules/pom.xml?
--
Jean-Sebastien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
+1.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, October 22, 2007 4:30 PM
Subject: Upgrading Maven plugin API dependency in maven-wsdl2java and
maven-java2wsdl
The Tuscany maven-wsdl2java and
Hi,
Basically there are two concepts:
1) The introspected implemention code (for example, a java class or a BPEL
file). Usually the metadata contributes to the corresponding component type
which is shared by all components that use the same implementation code.
2) The implementation.xxx
[snip]
Raymond Feng wrote:
We can have something like:
Well... You know what I think about how to model the intent -
operations relationship :) I think that you should experiment a bit with
what you're proposing, I'd like to just bring to your attention that:
- modeling operation and
More comments inline.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, October 22, 2007 6:16 PM
Subject: Re: Model intents and policySets attached under
implementation.xxx elements, was:Re: Transaction
Hi,
You need to add an extension to Tuscany and then you can add interceptors as
follows:
1) Implement the org.apache.tuscany.sca.invocation.Interceptor interface for
your interceptor
2) Implement org.apache.tuscany.sca.runtime.RuntimeWireProcessor interface
public void
Hi,
1) So for intents and policysets attached to implementation.xxx I understand
that you are proposing the addtion of another field in the Component model
to hold this information. i.e.
-ListIntent getRequiredIntents() /* this will capture intents specified
at the component element level
Hi,
How about a Tuscany Native release with all native projects: SCA, SDO and
DAS?
The 3 projects have an Apache Ant build system that is a good point for a
release containing all of them.
SCA next release is being discussed on [1].
DAS is ready for its first release, all necessary operations
I will start pointing what is remaining for DAS:
- Documentation
- User Guide
- Architecture Guide
- Getting Started
What about the other projects?
Regards,
Adriano Crestani
On 10/23/07, Adriano Crestani [EMAIL PROTECTED] wrote:
Hi,
How about a Tuscany Native release with all native
[
https://issues.apache.org/jira/browse/TUSCANY-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar resolved TUSCANY-1845.
--
Resolution: Fixed
SDODataTypeHelper.columnTypeForSDOType() throws RuntimeException
58 matches
Mail list logo
