On 3/21/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
snip/
We have been working to remove the dependencies on EMF
Is a goal to have an EMF free SDO impl? One of the reasons I liked this STaX
based approach is it makes the Tuscany core look more lightweight, but
removing the EMF
I have done some preliminary work on SDO integration with axis2C, and have
talked to some of the axis2c people about the work. There are two areas I
see that we could be worked on.
The first is a conversion from an SDO data graph to a tree of AXIOM objects.
This could be done by taking
Below is the note I posted a few weeks ago about what the JSON-RPC binding
does, which is to support entryPoints which enabled web pages in a browser
to make RPC style calls into SCA components on the server. (The code has
moved from the sandbox now so those links below are wrong)
I'd like to
This seems interesting but I have a few questions, which are not
really important but arise from curiosity:
I'm curious if you thought about making this look more like SCA
Client Implementation specs? For example, it may be convenient to
have the APIs look more like the Java CI spec such
[ http://issues.apache.org/jira/browse/TUSCANY-75?page=all ]
Rick Rineholt closed TUSCANY-75:
Resolution: Fixed
This is now working.
Hellowordwsclient fails
---
Key: TUSCANY-75
URL:
DAS CommandGroup needs to provide a dispose API
-
Key: TUSCANY-125
URL: http://issues.apache.org/jira/browse/TUSCANY-125
Project: Tuscany
Type: Bug
Components: Java DAS RDB
Reporter: Kevin Williams
Assigned
Jim Marino wrote:
A couple of us have started to discuss this as well in relation to
Celtix...My main concerns, which there appears to be agreement, are:
1. We are not instituting a canonical form model similar to JBI in the
runtime. I think Jeremy stated this is not the case
Having trouble
Thought about it a little bit, and in some offline discussion a while ago
Jeremy was also interested in that. I think there does need to be a balance
so as to not lose the simplicity of the client environment and to utilize
its dynamic nature. I'm definately interested in any feedback or
On Mar 22, 2006, at 9:32 AM, Jeremy Boynes wrote:
Jim Marino wrote:
A couple of us have started to discuss this as well in relation to
Celtix...My main concerns, which there appears to be agreement, are:
1. We are not instituting a canonical form model similar to JBI
in the runtime. I
ant elder wrote:
+1 to having a release from me. Having to build Tuscany themselves does put
people off trying it - first installing maven and svn and downloading all
the dependencies etc - having a binary download would help a lot. Not so
much time to May 15th though, we need a release plan...
Re-posted since the previous one is
missing the diagram
Hi,I think I have an interesting picture for this topic.1)
The data transformation capabilities for various databindings can be nicely
modeled as a weighted, directed graph with the following rules. (Illustrated
in the attached
Sorry, the attachment cannot go through. I added it to the wiki page @
http://wiki.apache.org/ws/Tuscany/DataMediation.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, March 15, 2006 3:37 PM
Subject: Data flow
On Mar 22, 2006, at 10:10 AM, Jim Marino wrote:
On Mar 22, 2006, at 9:32 AM, Jeremy Boynes wrote:
Jim Marino wrote:
A couple of us have started to discuss this as well in relation
to Celtix...My main concerns, which there appears to be
agreement, are:
1. We are not instituting a
My recollection - Frank let me know if this is incorrect - was that
the SDO impl would not necessarily be EMF-free but that it would
hide implementation details. For the Java runtime, the goal was to be
EMF-free from the perspective that the runtime would not contain
direct dependencies on
On Mar 22, 2006, at 10:27 AM, Jean-Sebastien Delfino wrote:
ant elder wrote:
+1 to having a release from me. Having to build Tuscany themselves
does put
people off trying it - first installing maven and svn and
downloading all
the dependencies etc - having a binary download would help a
Jim,
4. Additional bindings to Axis through integration with Celtix,
particularly ws and JMS
- Basic integration (p1)
- Ability to retarget (p2)
- Dan, would Celtix get us Indigo interop?
Good question regarding the Indigo stuff. We do have Indigo interop on
the
I think having multiple bindings is a good thing for JavaOne and
perhaps we will get lucky and be able to show some interop. Let's
see how things go next week.
Jim
On Mar 22, 2006, at 1:22 PM, Daniel Kulp wrote:
Jim,
4. Additional bindings to Axis through integration with Celtix,
On Mar 22, 2006, at 9:53 AM, ant elder wrote:
Thought about it a little bit, and in some offline discussion a
while ago
Jeremy was also interested in that. I think there does need to be a
balance
so as to not lose the simplicity of the client environment and to
utilize
its dynamic
Jim,
Axis2+Sandesha has already been thru WS-Addressing Interop and WS-RM
Interop using both SOAP 1.1 and SOAP 1.2 (specifically with
Indigo/WCF).
thanks,
dims
On 3/22/06, Daniel Kulp [EMAIL PROTECTED] wrote:
Jim,
4. Additional bindings to Axis through integration with Celtix,
Compilation error in DAS companyweb sample
--
Key: TUSCANY-126
URL: http://issues.apache.org/jira/browse/TUSCANY-126
Project: Tuscany
Type: Bug
Components: Java DAS RDB
Reporter: Rashmi Hunt
Package declaration in
That's great. Perhaps we could look at that as part of the Axis
cleanup work which needs to be done?
Jim
On Mar 22, 2006, at 1:59 PM, Davanum Srinivas wrote:
Jim,
Axis2+Sandesha has already been thru WS-Addressing Interop and WS-RM
Interop using both SOAP 1.1 and SOAP 1.2 (specifically
I just committed a change to the SDO XSDHelper.define() method which
changes the behavior significantly. It used to mangle names (using EMF's
mangling algorithm) and it didn't map simple types (like xsd:int) to the
proper SDO Types as specified in the SDO 2 spec.
With this change, many of the
Are there any _specific_ items people could suggest to improve the WS
support for this upcoming release? The next steps thread from a while back
was pretty quiet.
Axis2 already supports most things and interop's well so its 'just' a mater
of integration with Tuscany. Attachments? raw doc style?
Hi, Ant.
Can you apply the patch I submitted under JIRA 106 as well? It was to fix
the illegal web.xml.
Thanks,
Raymond
- Original Message -
From: ant elder [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, March 22, 2006 3:54 PM
Subject: Re: Eclipse warnings
Raymond Feng wrote:
Sorry, the attachment cannot go through. I added it to the wiki page @
http://wiki.apache.org/ws/Tuscany/DataMediation.
The mailing lists eat most attachements, I assume for a combination of
anti-virus, anti-spam, keep-it-open, keep-traffic-controlled reasons.
Attching
Raymond, please accept my apologies for the typo in your name.
--
Jeremy
[EMAIL PROTECTED] wrote:
Author: jboynes
Date: Wed Mar 22 17:44:06 2006
New Revision: 387996
URL: http://svn.apache.org/viewcvs?rev=387996view=rev
Log:
apply patch for TUSCANY-106 from Raymong Feng for invalid
Jeremy Boynes wrote:
Frank Budinsky wrote:
Now back to the issue of whether or not to use SDO for the SCDL model.
Personally, I think that the main issue Jeremy is bringing up is that the
way SDO is currently being used for a Java binding of the physical model,
which then needs to be
Fix for spec eclipse warnings
---
Key: TUSCANY-127
URL: http://issues.apache.org/jira/browse/TUSCANY-127
Project: Tuscany
Type: Improvement
Components: Java Spec APIs
Reporter: Daniel Kulp
Priority: Minor
Minor changes to
[ http://issues.apache.org/jira/browse/TUSCANY-127?page=all ]
Daniel Kulp updated TUSCANY-127:
Attachment: spec.patch
Fix for spec eclipse warnings
---
Key: TUSCANY-127
URL:
Fix eclipse warnings for sca/common
---
Key: TUSCANY-128
URL: http://issues.apache.org/jira/browse/TUSCANY-128
Project: Tuscany
Type: Improvement
Components: Java SCA Common
Reporter: Daniel Kulp
Priority: Minor
Fixes
[ http://issues.apache.org/jira/browse/TUSCANY-128?page=all ]
Daniel Kulp updated TUSCANY-128:
Attachment: common.patch
Fix eclipse warnings for sca/common
---
Key: TUSCANY-128
URL:
[ http://issues.apache.org/jira/browse/TUSCANY-127?page=all ]
Jeremy Boynes reassigned TUSCANY-127:
-
Assign To: Jeremy Boynes
Fix for spec eclipse warnings
---
Key: TUSCANY-127
URL:
Frank,
This commit seams to have REALLY broken the sca builds. The
container.java tests are failing pretty badly. Are you (or someone
else) working on fixing them?
For now, I'm going to revert my SDO dir to -r 387955.
Thanks!
Dan
On Wednesday 22 March 2006 17:55, Frank Budinsky
ant elder wrote:
Are there any _specific_ items people could suggest to improve the WS
support for this upcoming release? The next steps thread from a while back
was pretty quiet.
Axis2 already supports most things and interop's well so its 'just' a mater
of integration with Tuscany.
Sure ok, but I think I have a slightly different and less main stream
perspective on whats important/interesting to do :-) So for this release I'd
rather fit in with what others want which is why i'm asking for specific
suggestions.
A lot of the WS suggestions so far - pure doc vs doc-wrapped,
35 matches
Mail list logo
