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, wsd
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. Attachments
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 wrote
[
http://issues.apache.org/jira/browse/TUSCANY-127?page=comments#action_12371510
]
Jeremy Boynes commented on TUSCANY-127:
---
Never mind, I'm being dumb - we're already pre-reqing 1.5 due to all the
annotations.
> Fix for "spec" eclipse warnings
> ---
[
http://issues.apache.org/jira/browse/TUSCANY-127?page=comments#action_12371509
]
Jeremy Boynes commented on TUSCANY-127:
---
I'm going to request a vote on this on the list as it impacts the JDK version
for the spec jars.
> Fix for "spec" eclipse war
[ 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: http://iss
Jean-Sebastien Delfino wrote:
>
> The logical model is actually pretty close to the model generated from
> the XMLSchema. If you take the model generated from the schema and add a
> few derived /calculated relationships and derived attributes you get a
> reasonable logical model for the runtime co
[ 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://issue
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 all
[ 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: http://issues.apache.o
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 f
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 transf
> > Also, do I just create JIRA issues for the patches?
>
> Yes, please, that is the easiest way for us to track them and to make
> sure the IP is licensed.
OK. Will do. That said, the builds are now COMPLETELY broken which
makes it hard to make sure I didn't break anything else. Probably
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=387996&view=rev
> Log:
> apply patch for TUSCANY-106 from Raymong Feng for invalid
[ http://issues.apache.org/jira/browse/TUSCANY-106?page=all ]
Jeremy Boynes closed TUSCANY-106:
-
Resolution: Fixed
Patch applied - thanks
> web.xml is illegal (doesn't confirm to J2EE spec) in the tomcat testcase
> -
[ http://issues.apache.org/jira/browse/TUSCANY-106?page=all ]
Jeremy Boynes reassigned TUSCANY-106:
-
Assign To: Jeremy Boynes
> web.xml is illegal (doesn't confirm to J2EE spec) in the tomcat testcase
> ---
Ant,
Do you want to outline some things you think are important too? I
didn't list anything specific b/c I don't have any firm opinions.
Jim
On Mar 22, 2006, at 3:31 PM, ant elder wrote:
Are there any _specific_ items people could suggest to improve the WS
support for this upcoming releas
cc'ing the list as I replied to the wrong address
Original Message
Subject: Re: Eclipse warnings
Date: Wed, 22 Mar 2006 17:24:51 -0800
From: Jeremy Boynes <[EMAIL PROTECTED]>
To: Daniel Kulp <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTE
Raymond Feng wrote:
> 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 diagram).
>
> a. Each databindin
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
Jeremy,
> I agree that we should not mix "cosmetic" stuff with real code changes
> - that just makes things more complex and by its nature "cosmetic"
> stuff should not be urgent.
Ok, what about patches to "properly" use generics, especially for the
collections.I started looking at the warni
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:
Sent: Wednesday, March 22, 2006 3:54 PM
Subject: Re: Eclipse warnings
Patches to fix warnings
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 transformed into a diffe
Daniel Kulp wrote:
> Question 1:
> Would people be willing to accept patches that just fix warnings that show
> up in eclipse?
>
> Right now, using the same settings I use for Celtix, there are 622
> warnings in the spec, sdo, and sca projects.I hate seeing warnings,
> so I have two options
Patches to fix warnings are fine and appreciated. Send them in and I'll
apply them.
...ant
On 3/22/06, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
>
> Question 1:
> Would people be willing to accept patches that just fix warnings that show
> up in eclipse?
>
> Right now, using the same settings I
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? he
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 s
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 wi
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 cla
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,
> > pa
Question 1:
Would people be willing to accept patches that just fix warnings that show
up in eclipse?
Right now, using the same settings I use for Celtix, there are 622
warnings in the spec, sdo, and sca projects.I hate seeing warnings,
so I have two options:
1) Turn off most of the eclip
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 nature.
I read over the white paper for RDB DAS and noticed the clients must provide
certain data such as Primary Key either pragmatically or through a config
file for queries such as update/delete. Is it possible automatically look
this information up using JDBC to alleviate the need to provide this
infor
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,
par
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 roa
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 lo
Yes, you've got it right Jim. One thing that we did overlook, in terms of
priority, was that generated classes can't use any EMF features, even in
their impls. We initially put together a generator that generates EMF-less
interfaces, but had EMF things in the implementation classes. That solves
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 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 "c
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:
Sent: Wednesday, March 15, 2006 3:37 PM
Subject: Data flow on a wire
A couple
<>
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 diagram).a. Each databinding is mapped to a
vertex.b. If da
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...
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 diagram).
a. Each databinding is mapped to a vertex.
b. If dat
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 th
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
suggestion
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 troubl
I created a DAS JIRA (http://issues.apache.org/jira/browse/Tuscany-122)
a couple of days ago and assigned it to myself. Now it seems to have
disappeared from the main view
(http://issues.apache.org/jira/browse/TUSCANY). That is, is does not
show up in either the "by assignee -> Kevin Williams
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 t
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
2. Local invokes - i.e. where se
[ 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: http://issues.apa
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 C&I spec such
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 also
On 22/03/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
>
> 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 t
Right now its done very inefficiently, in effect converting between SDO an
AXIOM means serializing to a byte array. Have a look at the on going thread
"Data flow on a wire", and also
http://issues.apache.org/jira/browse/TUSCANY-118
...ant
On 3/22/06, Edward Slattery <[EMAIL PROTECTED]> wrote:
This thead has gone very quiet, can we resurrect it.
One of the reasons for looking at this is I'd like to make WS interactions
really fast. For example, making a WS gateway by wiring up an entryPoint
with a WS binding to an externalService with a WS binding, perhaps with
different QOS attributes
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 SDOXMLWrite
+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...
...ant
On 3/22/
On 3/21/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
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 dependency c
58 matches
Mail list logo
