date:20060807


OK. I've taken a look at this and may have a fix. It also uncovered a couple
of other issues with the SDO Implementation. I will raise separate Jiras for
those for clarity.

Cheers,


On 04/08/06, Geoff Winn (JIRA) tuscany-dev@ws.apache.org wrote:


   [
http://issues.apache.org/jira/browse/TUSCANY-587?page=comments#action_12425755]

Geoff Winn commented on TUSCANY-587:


There is more to this than I first thought. The problem is exhibited by
the following schema

?xml version=1.0 encoding=UTF-8 ?

xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema;
  xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
  targetNamespace=http://schemas.xmlsoap.org/wsdl/;
  elementFormDefault=qualified 

xs:group name=Wrapper
   xs:choice
 xs:element name=import type=xs:string /
 xs:element name=types type=xs:string /
 xs:element name=message type=xs:string /
   /xs:choice
/xs:group

xs:complexType name=tDefinitions 
   xs:complexContent
   xs:sequence
 xs:group ref=wsdl:Wrapper minOccurs=0 maxOccurs=unbounded
/
   /xs:sequence
   xs:attribute name=targetNamespace type=xs:anyURI
use=optional /
   xs:attribute name=name type=xs:NCName use=optional /
   /xs:complexContent
/xs:complexType

/xs:schema

The imprtant line is the group ref. The group consists of a choice of
three elements and the group ref allows unbounded repeats. After reading
this xsd, SDO ought to generate a type containing three properties, import,
types and message, all of which are many valued. In fact they are all single
valued, so SDO has failed to process the attributes on the group ref.

 WSDL XSD is read incorrectly.
 -

 Key: TUSCANY-587
 URL: http://issues.apache.org/jira/browse/TUSCANY-587
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: All platforms
Reporter: Geoff Winn

 When SDO for C++ reads the WSDL XSD (
http://scemas.xmlsoap.org/wsdl/2003-02-11.xsd) some properties that are in
fact many valued are identified in the internal model as single valued.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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





--
Pete

Re: adding an interceptor

2006-08-07 Thread Matthew Sykes


Jim,

I'd be interested in contributing to this but I'm not sure I know 
exactly where to begin.  If you're willing to spend a bit of time on the 
QA necessary to describe the intended flow through the bindings, wires 
invocation handlers, and policy handlers (using some of Jeremy's 
presentation as a starting point), I'm in.


Thanks.

Jim Marino wrote:

Greg,

We don't have this finished yet but it would be a nice project for 
someone to work on, particularly since it would involve figuring out how 
we are going to support SCA policy.  If you or someone else is 
interested in tackling this (or part of it) let me know and I'll help out.


Jim


On Aug 4, 2006, at 11:49 AM, Greg Dritschler wrote:

I am trying to understand how to add an interceptor to an invocation 
chain.

It looks like at one point this was accomplished by a implementing a
TargetPolicyBuilder and registering it with the PolicyBuilderRegistry.
However in the current code base it looks to me like the
PolicyBuilderRegistry is no longer instantiated.  Is this broken or has
this been replaced by some other mechanism?

Greg Dritschler


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




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

[RESULT] Re: Karma for Kelvin

2006-08-07 Thread ant elder


The result of the vote for Kelvin as committer is 9 +1s and no -1s.

+1s from:

Ant Elder
Frank Budinsky
Dan Kulp
Rick Rineholt
Pete Robbins
Jim Marino
Jeremy Boynes
Jean-Sebastien Delfino
Kevin Williams

  ...ant

On 8/5/06, kelvin goodson [EMAIL PROTECTED] wrote:


Thanks Kevin,   ant has volunteered to do this for me.

On 04/08/06, Kevin Williams [EMAIL PROTECTED] wrote:

 Hi Kelvin,
 I see that you already have a CLA on file.  If you send me a preferred
 apache user name and an alternate I will get this started.
 Thanks,
 --Kevin


 kelvin goodson wrote:

  Folks,
many thanks for the votes.   How does it work now?  I have a feeling
 my
  nominator might be expected to initiate a process or 2 to get me up
and
  running as a committer,  but Frank is now on vacation.  If this is the
  case
  could I put myself up for adoption please ;-)
 
  Regards, Kelvin.
 
  On 03/08/06, Kevin Williams [EMAIL PROTECTED] wrote:
 
 
  +1 from me too!
 
  Jim Marino wrote:
 
   +1 from me - Welcome Kelvin.
  
   Jim
  
   On Aug 2, 2006, at 1:53 PM, Frank Budinsky wrote:
  
   I'd like to propose that we make Kelvin a committer. Kelvin
 has  made
   many
   contributions to the SDO project:
  
   - helped design -noEMF generator patterns and contributed tests
for
   those
   patterns
   - provided SDO design and M1 user documentation on the WIKI
   - tested M1 release candidates
   - provided input to interop testing scenarios
   - discovered an EMF issue affecting SDO open content using global
   properties from xsds
   - designed and provided a patch for ChangeSummary on
  DataObject  support
   - regularly participates in IRC and mailing list discussions
   - worked on the sdo part of the new Tuscany website
   - reviewed sample SDO code for M2 drop
   - almost completed a paper for JDJ on What is SDO?
   - ran a BOF at OSCon for SDO and Tuscany
  
   Here's my +1 for making Kelvin a committer.
  
   Frank.
  
  
 -
   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]
  
  
  
  
 
 
 
  -
  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]




--
Best Regards
Kelvin Goodson

[jira] Created: (TUSCANY-601) Update Tuscany Website -Documentation Page to point to the OSOA specs

2006-08-07 Thread Venkatakrishnan (JIRA)

Update Tuscany Website -Documentation Page to point to the OSOA specs
--

 Key: TUSCANY-601
 URL: http://issues.apache.org/jira/browse/TUSCANY-601
 Project: Tuscany
  Issue Type: Improvement
  Components: Website
Reporter: Venkatakrishnan
 Attachments: Tuscany-Website-DocumentationPage-Aug-7.diff

Update the Tuscany website documentation page for sections that talk about SCA 
and SDO specs.  These pointers should point to the OSOA website to avoid 
confusions.  Here is the mail thread where Jeremy has suggested that I do a 
patch for this.

http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05837.html

I am attaching a patch here for these changes to the Documenation Page.  I have 
tried to re-organize the content a bit.  Could somebody please validate and 
apply if everything is ok.  Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: Documentation Page of Tuscany Website

2006-08-07 Thread Venkata Krishnan


Hi Jeremy, I have submitted a patch for this in
http://issues.apache.org/jira/browse/TUSCANY-601.  Please have a look to see
if it is ok.

Thanks

- Venkat

On 8/4/06, haleh mahbod [EMAIL PROTECTED] wrote:


We just need to make it clear that M1 was based on .9 spec.
New comers might get confused with why it is different than the latest
spec.


On 8/4/06, Venkata Krishnan [EMAIL PROTECTED] wrote:

 Sure yes :-)

 - Venkat

 On 8/4/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
 
  Good idea - can you do a patch for this?
  --
  Jeremy
 
  On Aug 4, 2006, at 12:18 AM, Venkata Krishnan wrote:
 
   Hi,
  
   Now that the OSOA site is open to all and it has all specs, could
   we link
   the spec documents posted on the page
   http://incubator.apache.org/tuscany/documentation.html to the
   corresponding
   ones on the OSOA site.  We could probably get rid of some
   duplication and
   confusions as it will be clear that there is this single place that
   has the
   specs against which Tuscany is under development.  Makes sense?
  
   - Venkat
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]

Account request for new Tuscany committer: Kelvin Goodson

2006-08-07 Thread ant elder


Tuscany has voted in Kelvin as a committer, could an account be created for
him please.

Preferred userid: kelvin
Full name: Kelvin James Goodson
Forwarding email: [EMAIL PROTECTED]

Requested Karma for: ws ws-tuscany

ICLA has been submitted and now appears on
http://people.apache.org/~jim/committers.htmlhttp://people.apache.org/%7Ejim/committers.html

Vote result 9 +1 votes and no -1s:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL 
PROTECTED]

Thanks!

  ...ant

[jira] Created: (TUSCANY-602) choice maxOccurs=unbounded does not create correct many-valued properties

choice  maxOccurs=unbounded does not create correct many-valued properties


 Key: TUSCANY-602
 URL: http://issues.apache.org/jira/browse/TUSCANY-602
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Reporter: Pete Robbins


According to the SDO spec maxOccurs on a choice or sequence should result in 
SDO properties for the enclosed elements being many-valued. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (TUSCANY-603) Attributes specified in xml instance doc are not validated against the schema definition

Attributes specified in xml instance doc are not validated against the schema 
definition


 Key: TUSCANY-603
 URL: http://issues.apache.org/jira/browse/TUSCANY-603
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins


When an instance document is loaded attributes on a type are set as attributes 
even if the schema specifies that the property is an element.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[VOTE] Andy Borley for Tuscany Committer


I would like to nominate Andy Borley to become a committer.
He has provided excellent functional patches for C++ such as the Axis2C
EntryPoint Binding. He has also provided much needed documentation patches
and has been a great help in getting the C++ milestone released.

Here's my +1.

Cheers,

--
Pete

[jira] Created: (TUSCANY-604) Exception thrown when sequenced type inherits from non-sequenced type

Exception thrown when sequenced type inherits from non-sequenced type
-

 Key: TUSCANY-604
 URL: http://issues.apache.org/jira/browse/TUSCANY-604
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins


The SDO spec states that the isSequenced should be the same on a base type and 
it's descendents. In the C++ implementation an exception is thrown when e.g. a 
sequenced type extends a non-sequenced type. This prevents schema such as the 
wsdl schema(http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd) being loaded. 

In the current Java implementation isSequenced is inherited from the base type, 
we should do the same in the C++ implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-604) Exception thrown when sequenced type inherits from non-sequenced type

 [ http://issues.apache.org/jira/browse/TUSCANY-604?page=all ]

Pete Robbins reassigned TUSCANY-604:


Assignee: Pete Robbins

 Exception thrown when sequenced type inherits from non-sequenced type
 -

 Key: TUSCANY-604
 URL: http://issues.apache.org/jira/browse/TUSCANY-604
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
 Assigned To: Pete Robbins

 The SDO spec states that the isSequenced should be the same on a base type 
 and it's descendents. In the C++ implementation an exception is thrown when 
 e.g. a sequenced type extends a non-sequenced type. This prevents schema such 
 as the wsdl schema(http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd) being 
 loaded. 
 In the current Java implementation isSequenced is inherited from the base 
 type, we should do the same in the C++ implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-603) Attributes specified in xml instance doc are not validated against the schema definition

 [ http://issues.apache.org/jira/browse/TUSCANY-603?page=all ]

Pete Robbins reassigned TUSCANY-603:


Assignee: Pete Robbins

 Attributes specified in xml instance doc are not validated against the schema 
 definition
 

 Key: TUSCANY-603
 URL: http://issues.apache.org/jira/browse/TUSCANY-603
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
Reporter: Pete Robbins
 Assigned To: Pete Robbins

 When an instance document is loaded attributes on a type are set as 
 attributes even if the schema specifies that the property is an element.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-587) WSDL XSD is read incorrectly.

 [ http://issues.apache.org/jira/browse/TUSCANY-587?page=all ]

Pete Robbins reassigned TUSCANY-587:


Assignee: Pete Robbins

 WSDL XSD is read incorrectly.
 -

 Key: TUSCANY-587
 URL: http://issues.apache.org/jira/browse/TUSCANY-587
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Affects Versions: Cpp-current
 Environment: All platforms
Reporter: Geoff Winn
 Assigned To: Pete Robbins

 When SDO for C++ reads the WSDL XSD 
 (http://scemas.xmlsoap.org/wsdl/2003-02-11.xsd) some properties that are in 
 fact many valued are identified in the internal model as single valued.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Assigned: (TUSCANY-602) choice maxOccurs=unbounded does not create correct many-valued properties

 [ http://issues.apache.org/jira/browse/TUSCANY-602?page=all ]

Pete Robbins reassigned TUSCANY-602:


Assignee: Pete Robbins

 choice  maxOccurs=unbounded does not create correct many-valued properties
 

 Key: TUSCANY-602
 URL: http://issues.apache.org/jira/browse/TUSCANY-602
 Project: Tuscany
  Issue Type: Bug
  Components: C++ SDO
Reporter: Pete Robbins
 Assigned To: Pete Robbins

 According to the SDO spec maxOccurs on a choice or sequence should result in 
 SDO properties for the enclosed elements being many-valued. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [VOTE] Andy Borley for Tuscany Committer


Pete Robbins wrote:

I would like to nominate Andy Borley to become a committer.
He has provided excellent functional patches for C++ such as the Axis2C
EntryPoint Binding. He has also provided much needed documentation 
patches

and has been a great help in getting the C++ milestone released.

Here's my +1.

Cheers,


+1, welcome Andy!

--
Jean-Sebastien


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

Re: [VOTE] Andy Borley for Tuscany Committer

2006-08-07 Thread ant elder


+1

On 8/7/06, Pete Robbins [EMAIL PROTECTED] wrote:


I would like to nominate Andy Borley to become a committer.
He has provided excellent functional patches for C++ such as the Axis2C
EntryPoint Binding. He has also provided much needed documentation patches
and has been a great help in getting the C++ milestone released.

Here's my +1.

Cheers,

--
Pete

Problems about definition of multi-service using annotation and componentType side file

2006-08-07 Thread zhong guangqing


hi,



Spec defines a  component can provide multiple services.So how to
define multiple services and what are the differences between a component
provides single service and a  component provides more.

In tuscany M1, with annotation, i tried many ways to define multiple
services in impl code, but i was failed. Does service annotation supports
multiple service definition, or i have to use annotation in a specific way?

   With componentType file, i changed the supplychain example, and defined
multiple services, but some problems happened. I removed all the annotations
in CustomerComponentImpl and RetailerComponentImpl java file, and defined
services and references in their component type file. In order to verify my
thoughts about multiple service definition, i changed RetailerComponentImpl
and made it implements multiple interfaces which are Retailer and Customer,
and the below is the snippet of RetailerComponentImpl.componentType file:





  service name=CustomerService
   interface.java interface=supplychain.Customer /
   /service



service name=RetailerService
   interface.java interface=supplychain.Retailer /
   /service



reference name=warehouse 
   interface.java interface=supplychain.Warehouse/
   /reference



   After my modification, i ran the SupplyChainClient and it failed. The
error is:



   Exception in thread main
org.apache.tuscany.core.builder.BuilderConfigException: Incompatible source
and target interface types for reference [retailer]
Context stack trace: [tuscany.root
][supplychain][supplychain][CustomerComponent][RetailerComponent][
tuscany.root]
at org.apache.tuscany.core.builder.impl.DefaultWireBuilder.connect(
DefaultWireBuilder.java:64)
at org.apache.tuscany.core.runtime.RuntimeContextImpl.connect(
RuntimeContextImpl.java:178)
at org.apache.tuscany.core.context.impl.AbstractCompositeContext.connect(
AbstractCompositeContext.java:823)
at org.apache.tuscany.core.context.impl.AbstractCompositeContext.wireSource
(AbstractCompositeContext.java:621)
at org.apache.tuscany.core.context.impl.AbstractCompositeContext.start(
AbstractCompositeContext.java:185)
at
org.apache.tuscany.core.context.scope.CompositeScopeContext.registerFactory(
CompositeScopeContext.java:95)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerConfiguration
(AbstractCompositeContext.java:499)
at
org.apache.tuscany.core.context.impl.AbstractCompositeContext.registerModelObject
(AbstractCompositeContext.java:446)
at org.apache.tuscany.core.client.BootstrapHelper.registerModule(
BootstrapHelper.java:133)
at org.apache.tuscany.core.client.TuscanyRuntime.init(TuscanyRuntime.java
:104)
at supplychain.SupplyChainClient.main(SupplyChainClient.java:43)



   If i delete CustomerService definition or move the RetailerService
definition to the first place, the client would run successfully.



   So why that happens?  Thx a lot!




--

guangqingzhong
2006-08-07

[RESULT] Meeraj Kunnumpurath for Tuscany committer

2006-08-07 Thread Jeremy Boynes


Passed with +1's from:
   jboynes
   jmarino
   kwilliams
   robbinspg
   jsdelfino
   rineholt
   kentam

and no -1's.

I would like to welcome Meeraj as a committer and will start the  
process of setting up his account.

--
Jeremy

On Aug 3, 2006, at 12:44 PM, Jeremy Boynes wrote:

I would like to nominate Meeraj to become a committer on Tuscany -  
he has been active in the project for quite a while now,  
contributing the original Groovy container implementation, a work  
manager implementation for use by async invocations and has worked  
to debug several problems including some tricky synchronization  
issues. I think he will continue to be a valuable contributor to  
the project.


Here's my +1.
--
Jeremy


-
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: DAS: Creating an empty graph

2006-08-07 Thread Brent Daniel


Fuhwei,

 In this scenario we will not retrieve any metadata from the
database, so you can remove step number two. The scenario would be:

1) If SDO Types have not been provided, create them using information
from the user-provided config.
2) Create an empty DataGraph using SDOUtil.createDataGraph()
3) Create a root object in that DataGraph using either the provided or
das-created Types.

Brent

On 8/4/06, Fuhwei Lwo [EMAIL PROTECTED] wrote:

Hi Brent,

 Is this your usage scenario?

 1. Create an empty data graph object without database access
 2. Retrieve the metadata from the database
 3. Create service data objects (SDO) based on the metadata
 4. Associate the data object tree with the data graph created in #1

 Fuhwei Lwo

Brent Daniel [EMAIL PROTECTED] wrote:  Well, I'm using DataGraph very 
generally here to refer to providing
a root DataObject with the appropriate set of SDO Types to a user
based on information contained in the DAS. In practice the actual
concept of a graph is hidden from users in the current rdb das
implementation.

Brent

On 8/4/06, Fuhwei Lwo  wrote:
  Current SDO spec working group is discussing to make DataGraph a  DataObject 
with predefined properties, changeSummary and modelType, in  future version. This 
could mean you can treat DataGraph as regular  DataObject if you like. Not sure 
this is what you are looking for.

  Regards,

  Fuhwei Lwo

 Brent Daniel
 wrote:  Hi Kelvin,

  I'm just trying to gain consensus on the programming model for the
 current relational DAS implementation. Now that I think about it, the
 ability to produce an empty graph is probably something that should
 apply to all DAS implementations, and should probably show up in the
 spec.

 We are creating the DataGraph using the SDOUtil function. In the empty
 graph  case, we create the graph, create a root object, turn on
 logging, and then return the root.

 Brent

 On 8/4/06, kelvin goodson  wrote:
  Brent,
I'm not sure I have a full handle on your issue but I will say that I
  think that the creation of an empty data graph seems like a natural
  responsibility of a DAS.  I'm afraid I haven't been following the DAS spec
  efforts as closely as I'd like to, so I'm guessing that when you say the
  DAS interface you mean the relational database DAS interface, yes?  Or do
  you mean a generic DAS interface?  In either case I think a vanilla
  createDataGraph() type operation would be appropriate,  but I'm not sure how
  general the version with the String command would be on a generic interface.
 
  Just a quick check,  are you aware of the SDOUtil.createDataGraph() method
  that we have to fill this gap?
 
  Regards, Kelvin.
 
  On 03/08/06, Brent Daniel
  wrote:
  
   We have a use case for the DAS that involves creating an empty graph
   without a database read. Kevin and I had talked about having a
   GraphHelper that provides this function, but I'm wondering if this
   should live somewhere else, like on the DAS interface.
  
   In the normal flow of operation, we receive all of the information we
   need to create a set of SDO Types from the metadata returned from a
   database query. For us to create an empty graph without a database
   read, we need to either have generated SDO types specified by the
   user, or we need the user to provide a ResultDescriptor (which
   overrides the metadata returned by the database.)
  
   Something like DAS.getEmptyGraph() would work well enough when the
   information is coming to us via a set of Types, but ResultDescriptor
   is scoped to Command. In that case, we would need something like
   DAS.getEmptyGraph(String commandName). Given that the user has to
   define a Command anyway, it might make more sense in this case to
   support some no-op type of Command and have everything go through
   the normal getCommand().execute() path. The case where SDO Types are
   specified could use the same path.
  
   I'm not sure which would be more intuitive, though I lean towards the
   no-op approach to keep the DAS interface cleaner.. any thoughts?
  
   Brent
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
 
  --
  Best Regards
  Kelvin Goodson
 
 

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






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

Re: [VOTE] Andy Borley for Tuscany Committer

2006-08-07 Thread Kevin Williams


+1

Pete Robbins wrote:


I would like to nominate Andy Borley to become a committer.
He has provided excellent functional patches for C++ such as the Axis2C
EntryPoint Binding. He has also provided much needed documentation 
patches

and has been a great help in getting the C++ milestone released.

Here's my +1.

Cheers,





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

Re: [VOTE] Andy Borley for Tuscany Committer

2006-08-07 Thread Daniel Kulp


+1, Welcome aboard!

Dan


On Monday August 07 2006 10:50 am, Pete Robbins wrote:
 I would like to nominate Andy Borley to become a committer.
 He has provided excellent functional patches for C++ such as the Axis2C
 EntryPoint Binding. He has also provided much needed documentation patches
 and has been a great help in getting the C++ milestone released.

 Here's my +1.

 Cheers,

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194   F:781-902-8001
[EMAIL PROTECTED]

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

[jira] Assigned: (TUSCANY-600) Refactor Celtix binding

2006-08-07 Thread Daniel Kulp (JIRA)

 [ http://issues.apache.org/jira/browse/TUSCANY-600?page=all ]

Daniel Kulp reassigned TUSCANY-600:
---

Assignee: Daniel Kulp

 Refactor Celtix binding
 ---

 Key: TUSCANY-600
 URL: http://issues.apache.org/jira/browse/TUSCANY-600
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Celtix Binding
Reporter: Jervis Liu
 Assigned To: Daniel Kulp
 Attachments: JIRA600.patch


 Need to refactor Celtix binding, for example, need to refactor some method 
 signatures, make Celtix binding code looks more consistent with Axis2 
 binding, add more tests etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [C++] How to create an SDO DataObject representing an XSD element


Pete Robbins wrote:

In your example below the complexType is anonymous (does not specify
name=) therefore the SDO Type takes the name of the enclosing element. So
the SDO Type will have Uri=http://www.bigbank.com/AccountService and
Name=getAccountReportResponse

Cheers,


On 05/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Most Web Services describe their inputs and outputs with XSD elements,
so I'm trying to understand how to create an SDO DataObject for such a
Web Service... (I'm using the BigBank scenario to experiment with that).

Here's the XSD defining the output of my Web Service:
xsd:schema
targetNamespace=http://www.bigbank.com/AccountService;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;

xsd:element name=getAccountReportResponse
  xsd:complexType
  xsd:sequence
   xsd:element name=checking type=tns:CheckingAccount
 maxOccurs=unbounded/
   xsd:element name=savings type=tns:SavingsAccount
 maxOccurs=unbounded/
   xsd:element name=stocks type=tns:StockAccount
 maxOccurs=unbounded/
  /xsd:sequence
  /xsd:complexType
/xsd:element

/xsd:schema

How can I create a DataObject representing the getAccountReportResponse
element using the SDO C++ API? Can DataFactory take an element name?
Is there a method on XSDHelper or another helper that will give me the
name of the type of the getAccountReportResponse element?

Thanks,

--
Jean-Sebastien


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







OK, that works, as per the SDO spec. What does the SDO runtime do if you 
have a complex type with the same name as an element containing an 
anonymous complex type?


--
Jean-Sebastien


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

[C++] Debugging and printing SDO data structures

I'm finding SDO DataObjects a little difficult to inspect with the GDB 
debugger. Is there anything that could be done to help debuggers display 
the contents of SDO DataObjects, properties and types?


Just an idea... but would it make sense to add to SDO DataObject a 
string member containing its serialized contents, only when compiled 
with the debug option maybe... Would that help?


Any thoughts?

--
Jean-Sebastien


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

Re: DAS: Creating an empty graph

2006-08-07 Thread Fuhwei Lwo

Brent,
   
  I am sorry I still don't understand what your SDO requirement is. You pretty 
much can accomplish your Step #1 and #3 by using the exising SDO APIs. The only 
SDO API we are missing here I can think of is to associate a data graph object 
with a root data object.
   
  Fuhwei

Brent Daniel [EMAIL PROTECTED] wrote:
  Fuhwei,

In this scenario we will not retrieve any metadata from the
database, so you can remove step number two. The scenario would be:

1) If SDO Types have not been provided, create them using information
from the user-provided config.
2) Create an empty DataGraph using SDOUtil.createDataGraph()
3) Create a root object in that DataGraph using either the provided or
das-created Types.

Brent

On 8/4/06, Fuhwei Lwo wrote:
 Hi Brent,

 Is this your usage scenario?

 1. Create an empty data graph object without database access
 2. Retrieve the metadata from the database
 3. Create service data objects (SDO) based on the metadata
 4. Associate the data object tree with the data graph created in #1

 Fuhwei Lwo

 Brent Daniel 
wrote: Well, I'm using DataGraph very generally here to refer to providing
 a root DataObject with the appropriate set of SDO Types to a user
 based on information contained in the DAS. In practice the actual
 concept of a graph is hidden from users in the current rdb das
 implementation.

 Brent

 On 8/4/06, Fuhwei Lwo wrote:
  Current SDO spec working group is discussing to make DataGraph a DataObject 
  with predefined properties, changeSummary and modelType, in future version. 
  This could mean you can treat DataGraph as regular DataObject if you like. 
  Not sure this is what you are looking for.
 
  Regards,
 
  Fuhwei Lwo
 
  Brent Daniel
 wrote: Hi Kelvin,
 
  I'm just trying to gain consensus on the programming model for the
  current relational DAS implementation. Now that I think about it, the
  ability to produce an empty graph is probably something that should
  apply to all DAS implementations, and should probably show up in the
  spec.
 
  We are creating the DataGraph using the SDOUtil function. In the empty
  graph case, we create the graph, create a root object, turn on
  logging, and then return the root.
 
  Brent
 
  On 8/4/06, kelvin goodson wrote:
   Brent,
   I'm not sure I have a full handle on your issue but I will say that I
   think that the creation of an empty data graph seems like a natural
   responsibility of a DAS. I'm afraid I haven't been following the DAS spec
   efforts as closely as I'd like to, so I'm guessing that when you say the
   DAS interface you mean the relational database DAS interface, yes? Or do
   you mean a generic DAS interface? In either case I think a vanilla
   createDataGraph() type operation would be appropriate, but I'm not sure 
   how
   general the version with the String command would be on a generic 
   interface.
  
   Just a quick check, are you aware of the SDOUtil.createDataGraph() method
   that we have to fill this gap?
  
   Regards, Kelvin.
  
   On 03/08/06, Brent Daniel
  wrote:
   
We have a use case for the DAS that involves creating an empty graph
without a database read. Kevin and I had talked about having a
GraphHelper that provides this function, but I'm wondering if this
should live somewhere else, like on the DAS interface.
   
In the normal flow of operation, we receive all of the information we
need to create a set of SDO Types from the metadata returned from a
database query. For us to create an empty graph without a database
read, we need to either have generated SDO types specified by the
user, or we need the user to provide a ResultDescriptor (which
overrides the metadata returned by the database.)
   
Something like DAS.getEmptyGraph() would work well enough when the
information is coming to us via a set of Types, but ResultDescriptor
is scoped to Command. In that case, we would need something like
DAS.getEmptyGraph(String commandName). Given that the user has to
define a Command anyway, it might make more sense in this case to
support some no-op type of Command and have everything go through
the normal getCommand().execute() path. The case where SDO Types are
specified could use the same path.
   
I'm not sure which would be more intuitive, though I lean towards the
no-op approach to keep the DAS interface cleaner.. any thoughts?
   
Brent
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
   --
   Best Regards
   Kelvin Goodson
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 

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

Re: [C++] Debugging and printing SDO data structures

2006-08-07 Thread Simon Laws


I think that would be a splendid idea. When I was playing with big bank
(which I hope to get back to shortly) I ended up using the
SDOUtils:printDataObject() method at strategic points in the code. As you
say it's very difficult to tell what's going on in GDB.

Regards

Simon

On 8/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I'm finding SDO DataObjects a little difficult to inspect with the GDB
debugger. Is there anything that could be done to help debuggers display
the contents of SDO DataObjects, properties and types?

Just an idea... but would it make sense to add to SDO DataObject a
string member containing its serialized contents, only when compiled
with the debug option maybe... Would that help?

Any thoughts?

--
Jean-Sebastien


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

Re: Account request for new Tuscany committer: Kelvin Goodson

2006-08-07 Thread Eran Chinthaka

Hi Ant,

Its better to cc this email to the new committer as well. The format for
this email can be found here
(http://www.apache.org/dev/pmc.html#newcommitter)

-- Chinthaka

ant elder wrote:
  Tuscany has voted in Kelvin as a committer, could an account be created
 for him please.
 
 Preferred userid: kelvin
 Full name: Kelvin James Goodson
 Forwarding email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 
 Requested Karma for: ws ws-tuscany
 
 ICLA has been submitted and now appears on
 http://people.apache.org/~jim/committers.html
 http://people.apache.org/%7Ejim/committers.html
 
 Vote result 9 +1 votes and no -1s:
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL 
 PROTECTED]
 http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/[EMAIL 
 PROTECTED]
 
 Thanks!
 
...ant




signature.asc
Description: OpenPGP digital signature

[C++] BigBank scenario working end to end


The BigBank scenario is now working end to end (on Linux at least).

To build it, just do make and make install in the sca and the samples 
directories. BigBank is now part of the build of the samples.


To run the local BigBank client, from 
$TUSCANY_SCAPP/samples/BigBank/deploy/bin, run ./runclient.sh. The 
client will call the local BigBank Account service, which will retrieve 
information on the customer's portfolio, including getting a stock quote 
from a live Web service (you need connection to the internet to run the 
sample).


To install and start the BigBank Web service, create a BigBank directory 
under your Axis2 services directory, copy 
samples/BigBank/Accounts/services.xml and 
lib/libtuscany_sca_ws_service.so to it.
Edit services.xml and set TuscanySystemRoot to 
$TUSCANY_SCAPP/samples/BigBank/deploy.

From the Axis2 bin directory, run ./axis2_http_server.

To run the BigBank Web service client, from 
$TUSCANY_SCAPP/samples/BigBank/deploy/bin, run ./runwsclient.sh.


Could somebody try the equivalent steps on Windows and let us know if 
there's any problems? or better, if it works as well :) Thanks.


--
Jean-Sebastien


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

[jira] Resolved: (TUSCANY-600) Refactor Celtix binding

2006-08-07 Thread Daniel Kulp (JIRA)

 [ http://issues.apache.org/jira/browse/TUSCANY-600?page=all ]

Daniel Kulp resolved TUSCANY-600.
-

Resolution: Fixed


Patch applied.  Thanks Jervis!

 Refactor Celtix binding
 ---

 Key: TUSCANY-600
 URL: http://issues.apache.org/jira/browse/TUSCANY-600
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Celtix Binding
Reporter: Jervis Liu
 Assigned To: Daniel Kulp
 Attachments: JIRA600.patch


 Need to refactor Celtix binding, for example, need to refactor some method 
 signatures, make Celtix binding code looks more consistent with Axis2 
 binding, add more tests etc

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: DAS: Creating an empty graph

2006-08-07 Thread Brent Daniel


Fuhwei,

 I don't think we have any requirements on SDO here. This function is
implemented today -- we're just trying to find a natural place for it
to live.

On 8/7/06, Fuhwei Lwo [EMAIL PROTECTED] wrote:

Brent,

 I am sorry I still don't understand what your SDO requirement is. You pretty 
much can accomplish your Step #1 and #3 by using the exising SDO APIs. The only 
SDO API we are missing here I can think of is to associate a data graph object 
with a root data object.

 Fuhwei

Brent Daniel [EMAIL PROTECTED] wrote:
 Fuhwei,

In this scenario we will not retrieve any metadata from the
database, so you can remove step number two. The scenario would be:

1) If SDO Types have not been provided, create them using information
from the user-provided config.
2) Create an empty DataGraph using SDOUtil.createDataGraph()
3) Create a root object in that DataGraph using either the provided or
das-created Types.

Brent

On 8/4/06, Fuhwei Lwo wrote:
 Hi Brent,

 Is this your usage scenario?

 1. Create an empty data graph object without database access
 2. Retrieve the metadata from the database
 3. Create service data objects (SDO) based on the metadata
 4. Associate the data object tree with the data graph created in #1

 Fuhwei Lwo

 Brent Daniel
wrote: Well, I'm using DataGraph very generally here to refer to providing
 a root DataObject with the appropriate set of SDO Types to a user
 based on information contained in the DAS. In practice the actual
 concept of a graph is hidden from users in the current rdb das
 implementation.

 Brent

 On 8/4/06, Fuhwei Lwo wrote:
  Current SDO spec working group is discussing to make DataGraph a DataObject 
with predefined properties, changeSummary and modelType, in future version. This 
could mean you can treat DataGraph as regular DataObject if you like. Not sure this 
is what you are looking for.
 
  Regards,
 
  Fuhwei Lwo
 
  Brent Daniel
 wrote: Hi Kelvin,
 
  I'm just trying to gain consensus on the programming model for the
  current relational DAS implementation. Now that I think about it, the
  ability to produce an empty graph is probably something that should
  apply to all DAS implementations, and should probably show up in the
  spec.
 
  We are creating the DataGraph using the SDOUtil function. In the empty
  graph case, we create the graph, create a root object, turn on
  logging, and then return the root.
 
  Brent
 
  On 8/4/06, kelvin goodson wrote:
   Brent,
   I'm not sure I have a full handle on your issue but I will say that I
   think that the creation of an empty data graph seems like a natural
   responsibility of a DAS. I'm afraid I haven't been following the DAS spec
   efforts as closely as I'd like to, so I'm guessing that when you say the
   DAS interface you mean the relational database DAS interface, yes? Or do
   you mean a generic DAS interface? In either case I think a vanilla
   createDataGraph() type operation would be appropriate, but I'm not sure 
how
   general the version with the String command would be on a generic 
interface.
  
   Just a quick check, are you aware of the SDOUtil.createDataGraph() method
   that we have to fill this gap?
  
   Regards, Kelvin.
  
   On 03/08/06, Brent Daniel
  wrote:
   
We have a use case for the DAS that involves creating an empty graph
without a database read. Kevin and I had talked about having a
GraphHelper that provides this function, but I'm wondering if this
should live somewhere else, like on the DAS interface.
   
In the normal flow of operation, we receive all of the information we
need to create a set of SDO Types from the metadata returned from a
database query. For us to create an empty graph without a database
read, we need to either have generated SDO types specified by the
user, or we need the user to provide a ResultDescriptor (which
overrides the metadata returned by the database.)
   
Something like DAS.getEmptyGraph() would work well enough when the
information is coming to us via a set of Types, but ResultDescriptor
is scoped to Command. In that case, we would need something like
DAS.getEmptyGraph(String commandName). Given that the user has to
define a Command anyway, it might make more sense in this case to
support some no-op type of Command and have everything go through
the normal getCommand().execute() path. The case where SDO Types are
specified could use the same path.
   
I'm not sure which would be more intuitive, though I lean towards the
no-op approach to keep the DAS interface cleaner.. any thoughts?
   
Brent
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
  
   --
   Best Regards
   Kelvin Goodson
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional

Re: DAS: Creating an empty graph

2006-08-07 Thread Kevin Williams

Brent,
I think it would help if you could describe the scenario from the user's
perspective. What are they trying to accomplish?

--Kevin

Fuhwei Lwo wrote:

Brent,

I am sorry I still don't understand what your SDO requirement is. You pretty much can accomplish your Step #1 and #3 by using the exising SDO APIs. The only SDO API we are missing here I can think of is to associate a data graph object with a root data object.

Fuhwei

Brent Daniel [EMAIL PROTECTED] wrote:
Fuhwei,

In this scenario we will not retrieve any metadata from the
database, so you can remove step number two. The scenario would be:

1) If SDO Types have not been provided, create them using information
from the user-provided config.
2) Create an empty DataGraph using SDOUtil.createDataGraph()
3) Create a root object in that DataGraph using either the provided or
das-created Types.

Brent

On 8/4/06, Fuhwei Lwo wrote:

Hi Brent,

Is this your usage scenario?

1. Create an empty data graph object without database access
2. Retrieve the metadata from the database
3. Create service data objects (SDO) based on the metadata
4. Associate the data object tree with the data graph created in #1

Fuhwei Lwo

Brent Daniel

wrote: Well, I'm using DataGraph very generally here to refer to providing

a root DataObject with the appropriate set of SDO Types to a user
based on information contained in the DAS. In practice the actual
concept of a graph is hidden from users in the current rdb das
implementation.

Brent

On 8/4/06, Fuhwei Lwo wrote:

Current SDO spec working group is discussing to make DataGraph a DataObject
with predefined properties, changeSummary and modelType, in future version.
This could mean you can treat DataGraph as regular DataObject if you like. Not
sure this is what you are looking for.

Regards,

Fuhwei Lwo

Brent Daniel

wrote: Hi Kelvin,

I'm just trying to gain consensus on the programming model for the
current relational DAS implementation. Now that I think about it, the
ability to produce an empty graph is probably something that should
apply to all DAS implementations, and should probably show up in the
spec.

We are creating the DataGraph using the SDOUtil function. In the empty
graph case, we create the graph, create a root object, turn on
logging, and then return the root.

Brent

On 8/4/06, kelvin goodson wrote:

Brent,
I'm not sure I have a full handle on your issue but I will say that I
think that the creation of an empty data graph seems like a natural
responsibility of a DAS. I'm afraid I haven't been following the DAS spec
efforts as closely as I'd like to, so I'm guessing that when you say the
DAS interface you mean the relational database DAS interface, yes? Or do
you mean a generic DAS interface? In either case I think a vanilla
createDataGraph() type operation would be appropriate, but I'm not sure how
general the version with the String command would be on a generic interface.

Just a quick check, are you aware of the SDOUtil.createDataGraph() method
that we have to fill this gap?

Regards, Kelvin.

On 03/08/06, Brent Daniel

wrote:

We have a use case for the DAS that involves creating an empty graph
without a database read. Kevin and I had talked about having a
GraphHelper that provides this function, but I'm wondering if this
should live somewhere else, like on the DAS interface.

In the normal flow of operation, we receive all of the information we
need to create a set of SDO Types from the metadata returned from a
database query. For us to create an empty graph without a database
read, we need to either have generated SDO types specified by the
user, or we need the user to provide a ResultDescriptor (which
overrides the metadata returned by the database.)

Something like DAS.getEmptyGraph() would work well enough when the
information is coming to us via a set of Types, but ResultDescriptor
is scoped to Command. In that case, we would need something like
DAS.getEmptyGraph(String commandName). Given that the user has to
define a Command anyway, it might make more sense in this case to
support some no-op type of Command and have everything go through
the normal getCommand().execute() path. The case where SDO Types are
specified could use the same path.

I'm not sure which would be more intuitive, though I lean towards the
no-op approach to keep the DAS interface cleaner.. any thoughts?

Brent

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

--
Best Regards
Kelvin Goodson

-
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

[C++] Do we need SDO annotations in the SCDL XSDs?

I noticed some SDO annotations in the SCDL XSDs used by the C++ runtime. 
I'm working on the new SCDL XSDs representing the recursive composition 
model from the SCA 0.95 spec and wondering if we really need to add 
annotations to the XSDs again. Given that we are not generating code 
from these XSDs do we really need these SDO annotations?


--
Jean-Sebastien


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

[jira] Resolved: (TUSCANY-601) Update Tuscany Website -Documentation Page to point to the OSOA specs

2006-08-07 Thread Rick Rineholt (JIRA)

 [ http://issues.apache.org/jira/browse/TUSCANY-601?page=all ]

Rick Rineholt resolved TUSCANY-601.
---

Resolution: Fixed

Applied patches

 Update Tuscany Website -Documentation Page to point to the OSOA specs
 --

 Key: TUSCANY-601
 URL: http://issues.apache.org/jira/browse/TUSCANY-601
 Project: Tuscany
  Issue Type: Improvement
  Components: Website
Reporter: Venkatakrishnan
 Attachments: Tuscany-Website-DocumentationPage-Aug-7.diff


 Update the Tuscany website documentation page for sections that talk about 
 SCA and SDO specs.  These pointers should point to the OSOA website to avoid 
 confusions.  Here is the mail thread where Jeremy has suggested that I do a 
 patch for this.
 http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05837.html
 I am attaching a patch here for these changes to the Documenation Page.  I 
 have tried to re-organize the content a bit.  Could somebody please validate 
 and apply if everything is ok.  Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Re: [C++] How to create an SDO DataObject representing an XSD element


I'll need to check but it will either be a) exception when adding the 2nd
type of the same name... or b) 2nd Definition replaces first... or c)
properties of 2nd definition are added to that of the first.

Or... none of the above! What do you think the correct behaviour should be?
What would Java do?

Cheers,


On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Pete Robbins wrote:
 In your example below the complexType is anonymous (does not specify
 name=) therefore the SDO Type takes the name of the enclosing element.
So
 the SDO Type will have Uri=http://www.bigbank.com/AccountService and
 Name=getAccountReportResponse

 Cheers,


 On 05/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 Most Web Services describe their inputs and outputs with XSD elements,
 so I'm trying to understand how to create an SDO DataObject for such a
 Web Service... (I'm using the BigBank scenario to experiment with
that).

 Here's the XSD defining the output of my Web Service:
 xsd:schema
 targetNamespace=http://www.bigbank.com/AccountService;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;

 xsd:element name=getAccountReportResponse
   xsd:complexType
   xsd:sequence
xsd:element name=checking type=tns:CheckingAccount
  maxOccurs=unbounded/
xsd:element name=savings type=tns:SavingsAccount
  maxOccurs=unbounded/
xsd:element name=stocks type=tns:StockAccount
  maxOccurs=unbounded/
   /xsd:sequence
   /xsd:complexType
 /xsd:element

 /xsd:schema

 How can I create a DataObject representing the getAccountReportResponse
 element using the SDO C++ API? Can DataFactory take an element name?
 Is there a method on XSDHelper or another helper that will give me the
 name of the type of the getAccountReportResponse element?

 Thanks,

 --
 Jean-Sebastien


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





OK, that works, as per the SDO spec. What does the SDO runtime do if you
have a complex type with the same name as an element containing an
anonymous complex type?

--
Jean-Sebastien


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





--
Pete

Re: [C++] Debugging and printing SDO data structures


I think the SDOUtils method is the way to go. Maintaining  a serialized form
in the DO would killl performance as it would have to be re-serialized on
every change. I have a printDataObject and printTypes methods in SCA which I
think are better than the ones in SDOUtil ;-) Maybe we should add the extra
function into SDOUtils.

Cheers,


On 07/08/06, Simon Laws [EMAIL PROTECTED] wrote:


I think that would be a splendid idea. When I was playing with big bank
(which I hope to get back to shortly) I ended up using the
SDOUtils:printDataObject() method at strategic points in the code. As you
say it's very difficult to tell what's going on in GDB.

Regards

Simon

On 8/7/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:

 I'm finding SDO DataObjects a little difficult to inspect with the GDB
 debugger. Is there anything that could be done to help debuggers display
 the contents of SDO DataObjects, properties and types?

 Just an idea... but would it make sense to add to SDO DataObject a
 string member containing its serialized contents, only when compiled
 with the debug option maybe... Would that help?

 Any thoughts?

 --
 Jean-Sebastien


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







--
Pete

Re: [C++] Do we need SDO annotations in the SCDL XSDs?


The annotations are there to cope with the cases where, according to the SDO
spec, we would create properties or types with .s in. For example

 element name=interface.cpp type=sca:CPPInterface
substitutionGroup=sca:interface
 sdo:name=interfaceCpp/

Without sdo:name= we would generate a property called interface.cpp. I
believe this causes problem when using XPath expressions.

cheers,


On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I noticed some SDO annotations in the SCDL XSDs used by the C++ runtime.
I'm working on the new SCDL XSDs representing the recursive composition
model from the SCA 0.95 spec and wondering if we really need to add
annotations to the XSDs again. Given that we are not generating code
from these XSDs do we really need these SDO annotations?

--
Jean-Sebastien


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





--
Pete

Re: [C++] Do we need SDO annotations in the SCDL XSDs?


Pete Robbins wrote:
The annotations are there to cope with the cases where, according to 
the SDO

spec, we would create properties or types with .s in. For example

 element name=interface.cpp type=sca:CPPInterface
substitutionGroup=sca:interface
 sdo:name=interfaceCpp/

Without sdo:name= we would generate a property called interface.cpp. I
believe this causes problem when using XPath expressions.

cheers,


On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I noticed some SDO annotations in the SCDL XSDs used by the C++ runtime.
I'm working on the new SCDL XSDs representing the recursive composition
model from the SCA 0.95 spec and wondering if we really need to add
annotations to the XSDs again. Given that we are not generating code
from these XSDs do we really need these SDO annotations?

--
Jean-Sebastien


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







Ok, I guess we're not going to use XPath on SCDL right away :) so I'm 
not going to worry about the annotations now then. I'm still curious 
though, it is valid in XSD to have a dot in an element name, and I would 
expect XPath to be able to deal with that... Isn't there a way to escape 
these dots in an XPath expression?


--
Jean-Sebastien


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

Re: [C++] Do we need SDO annotations in the SCDL XSDs?





Ok, I guess we're not going to use XPath on SCDL right away :) so I'm
not going to worry about the annotations now then. I'm still curious
though, it is valid in XSD to have a dot in an element name, and I would
expect XPath to be able to deal with that... Isn't there a way to escape
these dots in an XPath expression?




You could try but there may be a limitation in SDO (or at least the C++
implementation) which does not allow dots in the names.

Cheers,

--
Pete

Re: [C++] Do we need SDO annotations in the SCDL XSDs?


Pete Robbins wrote:




Ok, I guess we're not going to use XPath on SCDL right away :) so I'm
not going to worry about the annotations now then. I'm still curious
though, it is valid in XSD to have a dot in an element name, and I would
expect XPath to be able to deal with that... Isn't there a way to escape
these dots in an XPath expression?




You could try but there may be a limitation in SDO (or at least the C++
implementation) which does not allow dots in the names.

Cheers,



I scanned the SDO spec and could not find anything saying that dots are 
not allowed in names.


Page 104 of the SDO 2.01 spec says: The XSD names are preserved in the 
Type and Property. Use the sdo:name override to modify names as an 
option to remove duplicate names, blank names, or names with

special characters.

I would expect the SDO property name to be the same as the XSD element 
name, with the dot.


Could one of our Java or C++ SDO experts help shed some light on this?
Are dots allowed in SDO names? Did I miss anything in the spec?
Do we need to make a fix to the C++ SDO implementation? Any pointer to 
where to start to fix this?


Thanks,

--
Jean-Sebastien


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

Re: [VOTE] Andy Borley for Tuscany Committer

2006-08-07 Thread Jim Marino


+1 from me

Jim

On Aug 7, 2006, at 7:50 AM, Pete Robbins wrote:


I would like to nominate Andy Borley to become a committer.
He has provided excellent functional patches for C++ such as the  
Axis2C
EntryPoint Binding. He has also provided much needed documentation  
patches

and has been a great help in getting the C++ milestone released.

Here's my +1.

Cheers,

--
Pete



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

Account request for new committer: Raymond Feng

2006-08-07 Thread Jim Marino

Could an account please be created for Raymond, as he has been voted  
a committer?


9 +1s
No -1s

http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200608.mbox/% 
[EMAIL PROTECTED]


Preferred userid: 1) rfeng 2) raymondfeng
Full name: Zhaohui Feng (Raymond)
Forwarding email address: [EMAIL PROTECTED]

Requested Karma for: ws ws-tuscany


Thanks,
Jim


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

[C++] Switching C++ runtime to new composite model

I've started to work on switching the C++ SCDL model to the new 
composite assembly model.


If there's no objections, I'm planning to check in the code changes to 
support the new model some time tomorrow. This will include:

- new SCDL XSDs (already in SVN under cpp/sca/xsd/new for now)
- changes to the model classes to support composites, as per the SCA 
0.95 spec

- changes to the SCDL loader

This will just be a first pass implementation with limitations, no 
support for the new includes, or the new syntax for properties for example.


I will check in at the same time an updated version of the Calculator 
sample and the SCA test subsystem using the new model.


If you're working on some scenarios or samples that use old SCDL modules 
you will need to change your SCDL files to use composites. Please let me 
know if you need help porting to the new SCDL, or if you need me to 
delay or coordinate the check-in with you. Thanks.


--
Jean-Sebastien


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

Re: [C++] Do we need SDO annotations in the SCDL XSDs?


special characters?

On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Pete Robbins wrote:



 Ok, I guess we're not going to use XPath on SCDL right away :) so I'm
 not going to worry about the annotations now then. I'm still curious
 though, it is valid in XSD to have a dot in an element name, and I
would
 expect XPath to be able to deal with that... Isn't there a way to
escape
 these dots in an XPath expression?



 You could try but there may be a limitation in SDO (or at least the C++
 implementation) which does not allow dots in the names.

 Cheers,


I scanned the SDO spec and could not find anything saying that dots are
not allowed in names.

Page 104 of the SDO 2.01 spec says: The XSD names are preserved in the
Type and Property. Use the sdo:name override to modify names as an
option to remove duplicate names, blank names, or names with
special characters.

I would expect the SDO property name to be the same as the XSD element
name, with the dot.

Could one of our Java or C++ SDO experts help shed some light on this?
Are dots allowed in SDO names? Did I miss anything in the spec?
Do we need to make a fix to the C++ SDO implementation? Any pointer to
where to start to fix this?

Thanks,

--
Jean-Sebastien


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





--
Pete

Re: [C++] Switching C++ runtime to new composite model


So are you changing the loader to load the schema from xsd/new instead of
xsd? Personally I would just go for it and check in the new xsds as we
need to get this working anyway.

Cheers,


On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I've started to work on switching the C++ SCDL model to the new
composite assembly model.

If there's no objections, I'm planning to check in the code changes to
support the new model some time tomorrow. This will include:
- new SCDL XSDs (already in SVN under cpp/sca/xsd/new for now)
- changes to the model classes to support composites, as per the SCA
0.95 spec
- changes to the SCDL loader

This will just be a first pass implementation with limitations, no
support for the new includes, or the new syntax for properties for
example.

I will check in at the same time an updated version of the Calculator
sample and the SCA test subsystem using the new model.

If you're working on some scenarios or samples that use old SCDL modules
you will need to change your SCDL files to use composites. Please let me
know if you need help porting to the new SCDL, or if you need me to
delay or coordinate the check-in with you. Thanks.

--
Jean-Sebastien


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





--
Pete

[jira] Created: (TUSCANY-605) ImportSDOLoader ignoring schemaLocation parameter

2006-08-07 Thread Kapil Katyal (JIRA)

ImportSDOLoader ignoring schemaLocation parameter
-

 Key: TUSCANY-605
 URL: http://issues.apache.org/jira/browse/TUSCANY-605
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Kapil Katyal
Priority: Minor


According to the javadoc, when using the XSDHelper.define(inputstream, 
schemaLocation) method on a wsdl, the schemaLocation must be specified in order 
to resolve relative paths used in the xsd:imports or xsd:includes.  

In the ImportSDOLoader class, null is always passed in as the schemaLocation 
argument, which I believe makes it impossible to use import.sdo on a wsdl that 
contains relative paths for the xsd:import or xsd:includes tags.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Web services infrastructure

2006-08-07 Thread Ken Tam


Hey folks,

So it looks like there are a bunch of us looking at various issues
involved with WS infrastructure (Ant wrt interface.wsdl  the
WSDLDefinitionRegistry, and Rick with getting the Axis2 binding
working with the new core, and myself looking at how to integrate the
JAX-WS RI).

What do you guys think about pulling up the basic support for
binding.ws (ie, WebServiceBinding.java and
WebServiceBindingLoader.java) into someplace common to the specific
implementations (Axis2, Celtix, etc)?  From what I've seen, it seems
like there shouldn't be any implementation-specific information
necessary in that functionality.

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

Re: Web services infrastructure

2006-08-07 Thread Raymond Feng


Hi,

I think it makes a lot of senses to extract the common layer. 
Axis2/Celtix/JAX-WS can be treated as three dialects to the WS binding.


Thanks,
Raymond

- Original Message - 
From: Ken Tam [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Monday, August 07, 2006 3:25 PM
Subject: Web services infrastructure



Hey folks,

So it looks like there are a bunch of us looking at various issues
involved with WS infrastructure (Ant wrt interface.wsdl  the
WSDLDefinitionRegistry, and Rick with getting the Axis2 binding
working with the new core, and myself looking at how to integrate the
JAX-WS RI).

What do you guys think about pulling up the basic support for
binding.ws (ie, WebServiceBinding.java and
WebServiceBindingLoader.java) into someplace common to the specific
implementations (Axis2, Celtix, etc)?  From what I've seen, it seems
like there shouldn't be any implementation-specific information
necessary in that functionality.

-
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: Using TeamCity for continuous integration

2006-08-07 Thread Raymond Feng


Hi,

I have Continuum up and running with some issues observed. With one of my 
friends' recommendation, I also tried luntbuild before I went on vacation. 
We can evaluate the three options and decide. I can provide a list of 
cons/pros for Continuum and Luntbuild.


Thanks,
Raymond

- Original Message - 
From: Jim Marino [EMAIL PROTECTED]

To: tuscany-dev@ws.apache.org
Sent: Sunday, August 06, 2006 8:10 AM
Subject: Re: Using TeamCity for continuous integration


It didn't seem apparent from the thread if this is in place or not. 
Anyway, I think we should take a look at both, if possible, and pick  the 
one that best suits what we need to do. Also, we could have two  or more 
builds for testing things on different platforms. Let's see  if Raymond is 
looking into this further.



Jim

On Aug 6, 2006, at 3:03 AM, ant elder wrote:


Wouldn't it be better to use Continuum if possible as thats an Apache
project along with the Apache infrastructure instead of a BEA server?
There's been several mentions of doing this on incubator-general 
recently,

eg [2], so it sounds like it is possible to do now.

Also, Raymond already started some work on setting up a Continuum  build,
[1], he's on holiday right now so could this wait till he's back  and we 
hear

where he has got to?

  ...ant

[1] http://marc.theaimsgroup.com/?t=11507459634r=1w=2
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200604.mbox/ 
[EMAIL PROTECTED]


On 8/6/06, Jim Marino [EMAIL PROTECTED] wrote:


If there are no objections, I'm going to look into TeamCity (probably
not right away but soon) for continuous integration. Details are at:
http://www.jetbrains.com/teamcity/ .

The OpenJPA project is using TeamCity and Patrick Linksey gave it a
good review when I talked to him about their experiences with it.
Fortunately, we will likely be able to piggy-back off the machines
they are currently using (in a DMZ at BEA).

If anyone is interested in helping with this, please let me know.

Jim


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




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

Re: [C++] Do we need SDO annotations in the SCDL XSDs?


Pete Robbins wrote:

special characters?

On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


Pete Robbins wrote:



 Ok, I guess we're not going to use XPath on SCDL right away :) so I'm
 not going to worry about the annotations now then. I'm still curious
 though, it is valid in XSD to have a dot in an element name, and I
would
 expect XPath to be able to deal with that... Isn't there a way to
escape
 these dots in an XPath expression?



 You could try but there may be a limitation in SDO (or at least the 
C++

 implementation) which does not allow dots in the names.

 Cheers,


I scanned the SDO spec and could not find anything saying that dots are
not allowed in names.

Page 104 of the SDO 2.01 spec says: The XSD names are preserved in the
Type and Property. Use the sdo:name override to modify names as an
option to remove duplicate names, blank names, or names with
special characters.

I would expect the SDO property name to be the same as the XSD element
name, with the dot.

Could one of our Java or C++ SDO experts help shed some light on this?
Are dots allowed in SDO names? Did I miss anything in the spec?
Do we need to make a fix to the C++ SDO implementation? Any pointer to
where to start to fix this?

Thanks,

--
Jean-Sebastien


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






Pete,

The SDO spec is not specific about what special characters are. This 
could very well include dots, but I am interpreting the ...use sdo:name 
override as option to... as a nice convenience (as they say an 
option), not something that you absolutely have to do to make things 
work. If this is actually the case, and special characters are not 
allowed in SDO names, then it should be clearly stated in the spec.


In a spec which main goal is to handle types, I was expecting an 
unambiguous type definition for SDO names... I have scanned the whole 
doc three times now, but maybe I missed it :)


--
Jean-Sebastien


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

Re: [C++] Switching C++ runtime to new composite model


Pete Robbins wrote:

So are you changing the loader to load the schema from xsd/new instead of
xsd? Personally I would just go for it and check in the new xsds as we
need to get this working anyway.

Cheers,


On 07/08/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:


I've started to work on switching the C++ SCDL model to the new
composite assembly model.

If there's no objections, I'm planning to check in the code changes to
support the new model some time tomorrow. This will include:
- new SCDL XSDs (already in SVN under cpp/sca/xsd/new for now)
- changes to the model classes to support composites, as per the SCA
0.95 spec
- changes to the SCDL loader

This will just be a first pass implementation with limitations, no
support for the new includes, or the new syntax for properties for
example.

I will check in at the same time an updated version of the Calculator
sample and the SCA test subsystem using the new model.

If you're working on some scenarios or samples that use old SCDL modules
you will need to change your SCDL files to use composites. Please let me
know if you need help porting to the new SCDL, or if you need me to
delay or coordinate the check-in with you. Thanks.

--
Jean-Sebastien


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





Yes, agreed! I just had put them under xsd/new to give people a chance 
to see them first without breaking the whole runtime until I check in 
the C++ code that understands them. So if all goes well tomorrow, I'll 
check in the changes to the C++ loader, and at the same time will move 
the XSDs from xsd/new/ to xsd/.


--
Jean-Sebastien


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

Re: [C++] How to create an SDO DataObject representing an XSD element