On 2/22/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Great to see a *test* case for cycles, but my question was: Do you
have a *use* case for cycles and partial packages right now or can
it be fixed later?
Rajini Sivaram wrote:
No, I dont have an
Hi Rajini
just back in from vacation and catching up. I've put some comments in line
but the text seems to be circling around a few hot issues:
- How closely class loading should be related to model resolution, i.e.
options 1 and 2 from previously in this thread
- Support for split
On Mon, Feb 25, 2008 at 1:12 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:
Hi,
I have been working on modifying the existing bigbank demo to include
security (things that have been tried and working in the securie-bigbank
demo).
All seemed fine, until I tried the modified bigbank demo from
I would like to add a few iTests for Conversation Lifetime items that
don't seem to have explicit tests, In particular, I am looking at:
1) The ability to continue a conversation by loading a reference
that had been written to persistent storage
2) Implicit end of a conversation by a
On Mon, Feb 25, 2008 at 1:08 PM, Kevin Williams [EMAIL PROTECTED]
wrote:
I would like to add a few iTests for Conversation Lifetime items that
don't seem to have explicit tests, In particular, I am looking at:
1) The ability to continue a conversation by loading a reference
that had been
[
https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572090#action_12572090
]
Catalin Boloaja commented on TUSCANY-1997:
--
Could you provide a patched jar for
Simon,
A few comments inline.
On 2/25/08, Simon Laws [EMAIL PROTECTED] wrote:
Hi Rajini
just back in from vacation and catching up. I've put some comments in line
but the text seems to be circling around a few hot issues:
- How closely class loading should be related to model resolution,
Hi Simon,
Thanks for responding. Please see my comments inline.
- Venkat
On Mon, Feb 25, 2008 at 6:36 PM, Simon Laws [EMAIL PROTECTED]
wrote:
On Mon, Feb 25, 2008 at 1:12 AM, Venkata Krishnan [EMAIL PROTECTED]
wrote:
Hi,
I have been working on modifying the existing bigbank demo to
[
https://issues.apache.org/jira/browse/TUSCANY-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572113#action_12572113
]
Simon Laws commented on TUSCANY-1863:
-
I had a brief exchange with Giorgio on the ML
Jean-Sebastien Delfino wrote:
Looks good to me, building on your initial list I added a few more items
and tried to organize them in three categories:
A) Contribution workspace (containing installed contributions):
- Contribution model representing a contribution
- Reader for the contribution
+1. The more itests, the better :-).
Thanks,
Raymond
- Original Message -
From: Kevin Williams [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 25, 2008 5:08 AM
Subject: [TEST] Conversation Lifetime
I would like to add a few iTests for Conversation Lifetime
Raymond Feng wrote:
Hi,
I don't want to intercept the discussion but I'm wondering if we should
define the pluggability of the classloading scheme for SCA contributions.
Typically we have the following information for a ready-to-deploy unit:
* The URL of the deploment composite (deployable
Please see my comments inline.
Thanks,
Raymond
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 25, 2008 8:36 AM
Subject: PassByValueInterceptor always copying data now?
With the latest trunk code,
This is a side effect of a workaround that was added in the
databinding based on the following discussion thread [1], and I'm also
seeing issues as described in [2]. Maybe Raymond could give us other
choices here.
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28222.html
[2]
Raymond Feng wrote:
Please see my comments inline.
Thanks,
Raymond
- Original Message - From: Jean-Sebastien Delfino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 25, 2008 8:36 AM
Subject: PassByValueInterceptor always copying data now?
With the latest
I checked in a few fixes under r630942 and r630935 to get you going now.
For the JAXBContext issue, can you open a JIRA to track it? The current
introspection-based databinding might have some flaws in some cases as you
see. We need to have a separate discussion.
Thanks,
Raymond
-
Raymond Feng wrote:
Why don't we use META-INF/definitions.xml? META-INF/services folder is
for the java service provider pattern.
...
We don't even need the META-INF/ part, IMO definitions.xml is a
development artifact like .java, .composite, .wsdl, .xsd and doesn't
need to be in META-INF.
I was trying to follow the META-INF/sca-contribution.xml pattern as the file
name is defined by the spec and we only have at most one definitions.xml in
the same contribution. For .java, .compostem .wsdl, and .xsd artifacts, they
could have different artifact names, such as A.java and B.java.
- Original Message -
From: Jean-Sebastien Delfino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Monday, February 25, 2008 8:23 AM
Subject: Re: Contribution classloading pluggability: was: Re: Classloading
code in core contribution processing
Raymond Feng wrote:
Hi,
I
So, just to be clear again...
Hi Venkat
Can I just clarify that you are saying that you are having problems
because
of the way that the shader plugin is aggregating the definitions.xmlfiles
that now appear in various extension modules, e.g. binding-ws-axis2,
poilcy-logging et.
Hi Rajini
I'm covering old ground here but trying to make sure I'm looking at this in
the right way.
A - How closely class loading should be related to model resolution, i.e.
options 1 and 2 from previously in this thread
A1 (classloader uses model resolver) - standardizes the artifact
Hi,
I think Simon's proposal should work as follows instead of passing the
properties to the createInvoker() call.
public interface Invoker {
InvokerProperties getProperties(); // Contribute properties
}
public class InvokerProperties {
public void setAllowsPassByReference(boolean
See inline.
Simon
kelvin goodson wrote:
There's been a discussion thread going for a while [1] in the Tuscany
community with regards to shifting the Apache home for SDO Java work to a
new project. This has been going on in parallel to the discussion on the
incubator general list on
Raymond Feng wrote:
I was trying to follow the META-INF/sca-contribution.xml pattern as the
file name is defined by the spec and we only have at most one
definitions.xml in the same contribution. For .java, .compostem .wsdl,
and .xsd artifacts, they could have different artifact names, such as
I'm fine with the proposal. In Tuscany SCA Java, we support many
databindings such as JAXB, SDO, XmlBeans and AXIOM. IMHO, SDO is one of the
technology choices to represent data in the SOA environment. Removing SDO
from the sentence will give us more flexibility. I agree that it doesn't
stop
Simon Laws wrote:
...
For example, could you use something like
policy-logging\src\main\resources\org\apache\tuscany\policy\logging\definitions.xml
What you're proposing makes sense to me: let's put definitions.xml file
in logically named folders.
I'm not sure that we even need a naming
Raymond Feng wrote:
I think Simon's proposal should work as follows instead of passing the
properties to the createInvoker() call.
public interface Invoker {
InvokerProperties getProperties(); // Contribute properties
}
public class InvokerProperties {
public void
kelvin goodson wrote:
There's been a discussion thread going for a while [1] in the Tuscany
community with regards to shifting the Apache home for SDO Java work to a
new project. This has been going on in parallel to the discussion on the
incubator general list on establishing a new project,
28 matches
Mail list logo