Re: SCDL extensions to define data types for parameters and return value

[Jim Marino]

Also to answer Jeremy's question raise before: "I believe Celtix  
uses WSDL extensions for this i.e. annotations added
to the WSDL or possibly the underlying XMLSchema to indicate the  
data binding to use. ". This is not true. Celtix1.0 only supports  
jaxb,


Hi Jervis,

I thought Celtix supported multiple databindings through NodeReader/ 
NodeWriter? Is that wrong?


Jim



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

Fwd: svn commit: r438000

[Jim Marino]

Hi Raymond,

Could you please make sure you format this code: mvn -Psourcecheck?  
It breaks Checkstyle.


Thanks,
Jim

Begin forwarded message:


From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/core/ 
src: main/java/org/apache/tuscany/core/loader/ComponentLoader.java  
test/java/org/apache/tuscany/core/loader/ComponentLoaderTestCase.java

Reply-To: tuscany-dev@ws.apache.org

Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000

URL: http://svn.apache.org/viewvc?rev=438000&view=rev
Log:
Make sure the StAX loading only ends upon 

Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java


Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/main/java/org/apache/tuscany/core/loader/ComponentLoader.java? 
rev=438000&r1=437999&r2=438000&view=diff
== 

--- incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006

@@ -113,7 +113,8 @@
 reader.next();
 break;
 case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
 }
 }
 } catch (LoaderException e) {

Modified: incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/test/java/org/apache/tuscany/core/loader/ 
ComponentLoaderTestCase.java?rev=438000&r1=437999&r2=438000&view=diff
== 

--- incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29  
01:00:16 2006

@@ -57,7 +57,7 @@
 private ComponentLoader loader;

 public void testEmptyComponent() throws LoaderException,  
XMLStreamException {
-mockReader.expects(once()).method("getName").will 
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will 
(returnValue(COMPONENT));

 mockReader.expects(atLeastOnce()).method("getAttributeValue")
 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME), returnValue 
(null)));

@@ -71,7 +71,7 @@
 }

 public void testInitValue20() throws LoaderException,  
XMLStreamException {
-mockReader.expects(once()).method("getName").will 
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will 
(returnValue(COMPONENT));

 mockReader.expects(atLeastOnce()).method("getAttributeValue")
 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME), returnValue 
("20")));




-
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++] Build instructions on Web site

[Andrew Borley]

I think these would be a good addition to our docs. Probably best under a
"Development - Getting Started" page rather than "How to build", as they're
about more than just building Tuscany C++.

Andy


On 8/28/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Would it make sense to publish this:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05276.html
and this:
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05379.html
on a "How to build" page on the Tuscany C++ Web site?

Thoughts?

--
Jean-Sebastien


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

Re: [C++] Build instructions on Web site

[Geoffrey Winn]

Yes, definitely.

Would it be worth adding them to the Wiki rather than the web page? That
type of setup information tends to change and having it on the Wiki makes it
wasier to keep up to date. Alternatively, add it to the website with a
pointer to the Wiki for recent changes (or some such).

Geoff.

On 29/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


I think these would be a good addition to our docs. Probably best under a
"Development - Getting Started" page rather than "How to build", as
they're
about more than just building Tuscany C++.

Andy


On 8/28/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Would it make sense to publish this:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05276.html
> and this:
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05379.html
> on a "How to build" page on the Tuscany C++ Web site?
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

RE: Tuscany war plugin

[Meeraj Kunnumpurath]

I can help out, if no one else has volunteered yet. 

-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED] 
Sent: 28 August 2006 22:23
To: tuscany-dev@ws.apache.org
Subject: Re: Tuscany war plugin

Hopefully it won't be a beast ;-)

On Aug 28, 2006, at 1:40 PM, Jeremy Boynes wrote:

> Jim had said that as a prereq to a release then we should have a maven

> plugin that will set up the webapp runtime in a war. I think that 
> having such a beast would make building the samples easier and so 
> would suggest we get to work on it - is anyone interested in helping?
>
> --
> 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]


This message has been checked for all email viruses by MessageLabs.




*

You can find us at www.voca.com

*
This communication is confidential and intended for 
the exclusive use of the addressee only. You should 
not disclose its contents to any other person.
If you are not the intended recipient please notify 
the sender named above immediately.

Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX


This message has been checked for all email viruses by MessageLabs.

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

Re: SCDL extensions to define data types for parameters and return value

[Venkata Krishnan]

Hi Raymond,


How about defining databidings separately instead of embedded them as
extensions to the interface.wsdl. Right now I take the case of a WSDL to
express what I mean to say. In a WSDL...
- the message are defined
- then we have wsdl:porttype element and its children defined around these
messages
- we then have wsdl:binding that defines bindings around this portype
- then the service definitions around the bindings
- why not have something like  that defines the databiding.   If
this defn. is there then it is taken up and used otherwise the defaults
apply.

Is there something similar that we can do for what we define in SCDLs. ?
This way the interfaces definitions and the databidings are kept apart.  If
there is a databiding defn. it will have info about which interface (by
name) it should be applied to.

Makes sense?

Thanks

- Venkat


On 8/29/06, Jim Marino <[EMAIL PROTECTED]> wrote:


> Also to answer Jeremy's question raise before: "I believe Celtix
> uses WSDL extensions for this i.e. annotations added
> to the WSDL or possibly the underlying XMLSchema to indicate the
> data binding to use. ". This is not true. Celtix1.0 only supports
> jaxb,

Hi Jervis,

I thought Celtix supported multiple databindings through NodeReader/
NodeWriter? Is that wrong?

Jim



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

Re: Avoiding extension and application scdl collisions

[ant elder]

I don't think its promoting SCA as the "successor" to WSIF. Although
different there is functional overlap and this is just using that to get
some new people to notice Tuscany.

  ...ant

On 8/26/06, Jim Marino <[EMAIL PROTECTED]> wrote:



On Aug 26, 2006, at 3:33 AM, ant elder wrote:

> On 8/25/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> 
>
>>> More importantly, if we are trying to make the use case of a
>> >> single reference used by a J2SE client easier, I'd would say don't
>> >> use SCA  for that. Just use Axis (or some other transport)
>> >> directly. Where SCA  is valuable is in assembly of multiple
>> services.
>> >>
>> >
>> > I'm not sure :-) I think it should also be possible for these guys
>> > to take advantage of SCA (I assume SCA can simplify programming).
>> >
>> SCA doesn't simplify all programming. Sometimes it's just easier to
>> avoid the unnecessary overhead of "frameworks".
>
>
> Could this be an interesting scenario to support which may appeal
> to people
> like those using the old WSIF framework? Advertising this and
> documenting a
> migration path from WSIF to the SCA programming model could get us
> a bunch
> of new users who may not otherwise be looking at SCA.
>
At the risk of starting a flame war IMO we need to be careful not to
portray SCA as a "successor" to WSIF, as they address quite different
things (I have seen this brought up at several public events). For
example, SCA is a model for describing service assemblies and
components, not "services", and it intentionally does not provide
location transparency.  One of the other significant differences I
see is that WSIF is very WSDL-centric, while in SCA not all services
must be expressible in WSDL (only remotable) and hopefully the
application developer never need see one. The one similarity I do see
is the ability to switch bindings, although in SCA this does not have
to involve changing any WSDL. I'm not sure, though, how far I would
take this similarity as I suspect SCA's concept of expressing remote
services through "business interfaces" has important differences.

As a migration path, I would recommend the following. If there is a
simple J2SE client that invokes some services and it works, just
leave it and it can invoke into an SCA system. If someone wants to
rewrite the client, I assume it is either because they are re-
architecting or find that the framework currently being used doesn't
meet their needs. For both cases, I would say if the client is not
participating in a service assembly and only invokes a few services,
all over a common transport, just use the transport API. If things
such as the transport changes frequently (not something I have seen
too often) or IT wants to introduce capabilities such as policy,
tracing or monitoring, then the client application should probably be
placed in a service assembly and it would be run in an SCA container.
If someone wants a client that uses a boat-load of transports or
policies and it will not benefit from being part of an assembly, then
they could use the SCA J2SE host and the classpath isolation it
provides seems like a simpler solution than cramming everything onto
one classpath.

Jim






>   ...ant


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

[C++] Extension mechanism for implementations and bindings

[Jean-Sebastien Delfino]

Pete,

I replicated your nice implementation extension mechanism to support 
binding extensions as well. All the WS binding support is now packaged 
in two separate ws_reference and ws_service extensions.


I am able to run our Web Service end to end scenarios with this new 
packaging.


I think that we now have a good structure in place for people to be able 
to add new bindings and implementations in Dlls / shared libaries 
without requiring any changes in the core runtime.


--
Jean-Sebastien


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

[jira] Assigned: (TUSCANY-668) Move RMIHost to Host-API project & improve exception abstractions

[ant elder (JIRA)]

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

ant elder reassigned TUSCANY-668:
-

Assignee: ant elder

> Move RMIHost to Host-API project & improve exception abstractions
> -
>
> Key: TUSCANY-668
> URL: http://issues.apache.org/jira/browse/TUSCANY-668
> Project: Tuscany
>  Issue Type: Improvement
>Affects Versions: Java-M2
>Reporter: Venkatakrishnan
> Assigned To: ant elder
> Attachments: Tuscany-host-api-Aug-28.diff, 
> Tuscany-rmi-binding-Aug-28.diff, Tuscany-sca-spi-Aug-28.diff
>
>
> Hi
>  
> These are patche related to RMI Binding that addresses the following: -
> - Decision on moving RMIHost related classes to host-api project.  See 
> disccusion  in  
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg07077.html
> - Removing these classes from the sca-spi project
> - Abstraction of Exception classes as inheriting from Tuscany Exception 
> classes
> - Repackage of RMIHostImpl within the RMIBinding extension implementation
> - Fixing of bug in RMIService.
> Could somebody please review and apply.  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++] Extension mechanism for implementations and bindings

[Pete Robbins]

ah.. you got me! I will have to merge this with my changes that I am making.
I'd hoped to get these in before you started coding again... but you never
sleep!

I've moved all the osoa/sca code into the cpp extension and just about have
it working. I'll re-factor your binding extension changes in before checking
this in.

Cheers,


On 29/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Pete,

I replicated your nice implementation extension mechanism to support
binding extensions as well. All the WS binding support is now packaged
in two separate ws_reference and ws_service extensions.

I am able to run our Web Service end to end scenarios with this new
packaging.

I think that we now have a good structure in place for people to be able
to add new bindings and implementations in Dlls / shared libaries
without requiring any changes in the core runtime.

--
Jean-Sebastien


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





--
Pete

[jira] Closed: (TUSCANY-668) Move RMIHost to Host-API project & improve exception abstractions

[ant elder (JIRA)]

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

ant elder closed TUSCANY-668.
-

Resolution: Fixed

Applied, thanks for the patches Venkat.

> Move RMIHost to Host-API project & improve exception abstractions
> -
>
> Key: TUSCANY-668
> URL: http://issues.apache.org/jira/browse/TUSCANY-668
> Project: Tuscany
>  Issue Type: Improvement
>Affects Versions: Java-M2
>Reporter: Venkatakrishnan
> Assigned To: ant elder
> Attachments: Tuscany-host-api-Aug-28.diff, 
> Tuscany-rmi-binding-Aug-28.diff, Tuscany-sca-spi-Aug-28.diff
>
>
> Hi
>  
> These are patche related to RMI Binding that addresses the following: -
> - Decision on moving RMIHost related classes to host-api project.  See 
> disccusion  in  
> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg07077.html
> - Removing these classes from the sca-spi project
> - Abstraction of Exception classes as inheriting from Tuscany Exception 
> classes
> - Repackage of RMIHostImpl within the RMIBinding extension implementation
> - Fixing of bug in RMIService.
> Could somebody please review and apply.  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]

Jetty based standalone distribution (was: Re: Sample framework)

[ant elder]

Ok Jim, I'd like start work on getting this Jetty based standalone
distribution going. Eventually I'd like a distribution which includes things
like Jetty, Axis2/WS, rmi, json, groovy, javascript and spring. I'd also
like some pre-installed samples, maybe  in addition to the  bin, boot, and
extensions directories in the existing standalone distribution also have an
applications directory to contain the samples and other applications. And I
guess some bat/shell scripts to do startup etc.

Anyone else interested in helping with this?

  ...ant

On 8/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:


I think it should basically work although we need to tidy up a few
things. One thing is configuration. I'd like to be able to configure
ports, ssl, etc. and the best way to probably do this is through
SCA's use of include and XPath evaluation of external properties
files. Basically, we would have a separate config file for standalone
and in the Jetty SCDL do an include and have an XPath to the relevant
Jetty data.

If you want, since you are working on the ServletHost stuff, I can
help trying to get standalone working with Jetty and Axis. Let me know.

Jim

On Aug 19, 2006, at 5:24 AM, ant elder wrote:

> One of the good things about making it easy to create different
> distributions is we can have distributions with or without pre-
> installed
> samples. There's obviously people who've found it useful to have them
> pre-installed.
>
> I'd also really like a standalone distribution using Jetty, for one we
> really need Jetty support to get references working well with the ajax
> binding.  Whats the status of the Jetty code in SVN?
>
>   ...ant
>
> On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>
>> I think there are a couple issues here which would benefit by
>> stepping through what we expect users to actually be doing. From a
>> user standpoint, I imagine most people will have the following goals:
>>
>> 1. Figure out how to write an SCA application
>> 2. Figure out how to deploy the application
>> 3. Run the application
>>
>> Starting with 3 in a server environment does not really do anything.
>> For example, I start something up and hit a web page, but can't
>> really debug or step through without setting a project up in my IDE.
>> What I think most users want is a quick way (i.e 5 minutes) to do the
>> following:
>>
>> 1. Download a sample that has an automated way to create a dev
>> project
>> 2. Build the sample and deploy it to whatever host environment I
>> typically do my development with. For example, for web app
>> development, I prefer Jetty since it is light, fast, and easily
>> embedded. Others may prefer Resin, Websphere, WebLogic, etc. As I
>> mention below, however, I don't think most Tuscany development will
>> be done inside a web app.
>> 3. Run the sample and debug it (either remotely or in my IDE) so I
>> can see what is happening
>> 4. Make changes to the sample and goto step 2
>>
>> The most time-consuming parts I have found in using new technologies
>> is getting my dev environment setup properly. For example, with a
>> binary distro, here is what I would have to go through:
>>
>> 1. Download the binary distro, including a pile of dependencies
>> probably totaling over 200MB
>> 2. Unzip the distro, follow the readme instructions to start the
>> thing
>> 3. Use a browser to hit a web page that prints something out
>>
>> At this point, I still can't really see what is going on much less do
>> things like changing bindings, adding policy, swapping implementation
>> types, etc. If I want to use really understand how SCA and Tuscany
>> work, I would have to:
>>
>> 4. Download the source sample, maybe it is included in 1 but maybe
>> not
>> 5. Setup my dev environment with a sample project
>> 6. Build the sample and package it
>> 7. Figure out whether I want to deal with Tomcat the version of
>> Tomcat my Tuscany download just came with. Probably not, since I
>> already have a Tomcat install or use something else.
>> 8. Make any necessary changes to my dev environment so I can debug
>> the sample as it is run
>> 9. Deploy the sample to the host I do my development with
>>
>> IMO what would be much simpler for end users would be to:
>>
>> 1. Download a sample distro
>> 2. Build it with maven, which can generate the IDE project for me as
>> well as deployment artifacts for whatever host type I choose, e.g. a
>> WAR file
>> 3. Set my IDE to use the source from the sample I just downloaded
>> 4. Decide where I want to deploy it to. If it is a WAR, I just drop
>> it in and either run it from within my IDE and debug or attach to a
>> remote process
>>
>> I think it would be useful to look at projects that have been highly
>> successful (i.e. one of the most widely used Java projects) and see
>> how they do things, Spring and Hibernate. Both do not ship a pre-
>> configured host environment.
>>
>> As a further thing to think about, I expect most SCA users will *not*
>> be developing with or deploying 

Re: Jetty based standalone distribution (was: Re: Sample framework)

[Venkata Krishnan]

Ant, I am actually clueless about what this would involve but am interested
in helping out with some guidance from you and others.

- Venkat

On 8/29/06, ant elder <[EMAIL PROTECTED]> wrote:


Ok Jim, I'd like start work on getting this Jetty based standalone
distribution going. Eventually I'd like a distribution which includes
things
like Jetty, Axis2/WS, rmi, json, groovy, javascript and spring. I'd also
like some pre-installed samples, maybe  in addition to the  bin, boot, and
extensions directories in the existing standalone distribution also have
an
applications directory to contain the samples and other applications. And
I
guess some bat/shell scripts to do startup etc.

Anyone else interested in helping with this?

   ...ant

On 8/19/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>
> I think it should basically work although we need to tidy up a few
> things. One thing is configuration. I'd like to be able to configure
> ports, ssl, etc. and the best way to probably do this is through
> SCA's use of include and XPath evaluation of external properties
> files. Basically, we would have a separate config file for standalone
> and in the Jetty SCDL do an include and have an XPath to the relevant
> Jetty data.
>
> If you want, since you are working on the ServletHost stuff, I can
> help trying to get standalone working with Jetty and Axis. Let me know.
>
> Jim
>
> On Aug 19, 2006, at 5:24 AM, ant elder wrote:
>
> > One of the good things about making it easy to create different
> > distributions is we can have distributions with or without pre-
> > installed
> > samples. There's obviously people who've found it useful to have them
> > pre-installed.
> >
> > I'd also really like a standalone distribution using Jetty, for one we
> > really need Jetty support to get references working well with the ajax
> > binding.  Whats the status of the Jetty code in SVN?
> >
> >   ...ant
> >
> > On 8/18/06, Jim Marino <[EMAIL PROTECTED]> wrote:
> >>
> >> I think there are a couple issues here which would benefit by
> >> stepping through what we expect users to actually be doing. From a
> >> user standpoint, I imagine most people will have the following goals:
> >>
> >> 1. Figure out how to write an SCA application
> >> 2. Figure out how to deploy the application
> >> 3. Run the application
> >>
> >> Starting with 3 in a server environment does not really do anything.
> >> For example, I start something up and hit a web page, but can't
> >> really debug or step through without setting a project up in my IDE.
> >> What I think most users want is a quick way (i.e 5 minutes) to do the
> >> following:
> >>
> >> 1. Download a sample that has an automated way to create a dev
> >> project
> >> 2. Build the sample and deploy it to whatever host environment I
> >> typically do my development with. For example, for web app
> >> development, I prefer Jetty since it is light, fast, and easily
> >> embedded. Others may prefer Resin, Websphere, WebLogic, etc. As I
> >> mention below, however, I don't think most Tuscany development will
> >> be done inside a web app.
> >> 3. Run the sample and debug it (either remotely or in my IDE) so I
> >> can see what is happening
> >> 4. Make changes to the sample and goto step 2
> >>
> >> The most time-consuming parts I have found in using new technologies
> >> is getting my dev environment setup properly. For example, with a
> >> binary distro, here is what I would have to go through:
> >>
> >> 1. Download the binary distro, including a pile of dependencies
> >> probably totaling over 200MB
> >> 2. Unzip the distro, follow the readme instructions to start the
> >> thing
> >> 3. Use a browser to hit a web page that prints something out
> >>
> >> At this point, I still can't really see what is going on much less do
> >> things like changing bindings, adding policy, swapping implementation
> >> types, etc. If I want to use really understand how SCA and Tuscany
> >> work, I would have to:
> >>
> >> 4. Download the source sample, maybe it is included in 1 but maybe
> >> not
> >> 5. Setup my dev environment with a sample project
> >> 6. Build the sample and package it
> >> 7. Figure out whether I want to deal with Tomcat the version of
> >> Tomcat my Tuscany download just came with. Probably not, since I
> >> already have a Tomcat install or use something else.
> >> 8. Make any necessary changes to my dev environment so I can debug
> >> the sample as it is run
> >> 9. Deploy the sample to the host I do my development with
> >>
> >> IMO what would be much simpler for end users would be to:
> >>
> >> 1. Download a sample distro
> >> 2. Build it with maven, which can generate the IDE project for me as
> >> well as deployment artifacts for whatever host type I choose, e.g. a
> >> WAR file
> >> 3. Set my IDE to use the source from the sample I just downloaded
> >> 4. Decide where I want to deploy it to. If it is a WAR, I just drop
> >> it in and either run it from within my IDE and debug or attach to a
> >> r

Re: [C++] Requirements for a pluggable C++ Tuscany implementation

[Oisin Hurley]

Simon - apologies I've been away from this for the last week...

[deletia]

...and this is why :)  There are number of responsibilities of an
extension - which you accurately describe - and there are a number
of responsibilities of a plugin, related to configuration and  
lifecycle

and I think it would be a Good Thing to keep them as separate
development
efforts. What do you think?


Do you mean that a plugin may have responsibilities that are a sub- 
set or

super-set of those of a particular extension?


Actually I see that the plugins responsibilities are a disjoint set -
meaning that the plugins are unconscious of the value of their content
and are used only as a way to bang a bunch of libraries together in
a predictable manner and correctly initialize/deinitialize them.

We could probably have the same conversation re. deploying  
components and
composites into the C++ SCA infrastructure as opposed to deploying  
parts of

the C++ SCA infrastructure.


+1

Maybe we need to be a bit more explicit about what we anticipate  
being in a

plugin. For examle,

0..n Component type container implementations
0..n Binding implementations
0..n Host adapters
[0..n Components
0..n Composite(s) should these be included as well? Seems unlikely  
that you
want to deply at the same time but you will want to deploy at some  
time.]


So there's two roads - one where one must be explicit about the content
of the plugin in terms of architectural artifacts, this is the manifest
style approach, and the other, where the plugin initialization code does
the necessary registrations of architectural artifacts. These are not
necessarily incompatible approaches either.

Can we use exsiting technology for some of this, for example, there  
has been
much discussion of OSGi on the java list, is OSGi wider that just  
Java now?


AFAIK OSGi is still Java only and a Google search didn't turn up much  
that

was useful. In terms of existing technology, I'm not familiar with any
technologies along this line that are open. That being said, a C++  
version

of OSGi would be a beautiful thing :)

My gut feeling is that plugin/extension should be decoupled, but the  
only
strong point I can see for it in the current architecture is the fact  
that
databindings are not explicit as an extension - there is scope for  
say an

interface.mumble that has databindings of say XMLBeans or JiBX. If the
databinding can be an extension in its own right, then maybe the  
simplifying
assumption of plugin == extension may be the way to go. From the  
point of
view of deployment, there may be a greater need for a non-extension  
plugin

to package application code to be 'deployed'. Maybe we should have that
conversation about deployment now?

 cheers
  --oh

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

[jira] Created: (TUSCANY-671) Port JSON-RPC binding from M1

[Bert Lamb (JIRA)]

Port JSON-RPC binding from M1
-

 Key: TUSCANY-671
 URL: http://issues.apache.org/jira/browse/TUSCANY-671
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA JsonRpc Binding
Affects Versions: Java-M2
Reporter: Bert Lamb
Priority: Minor


Port the JSON-RPC binding from M1 into the new binding format.  I've been 
working on this, so I should be able to post a patch soon.

-- 
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-672) Unable to override systemScdl in a webapp

[Bert Lamb (JIRA)]

Unable to override systemScdl in a webapp
-

 Key: TUSCANY-672
 URL: http://issues.apache.org/jira/browse/TUSCANY-672
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Common
Affects Versions: Java-M2
 Environment: WinXP with Tomcat 5.5.17
Reporter: Bert Lamb


Ok, so the good news is that I got the binding and the sample working
when modifying the webapp.system.scdl in webapp-host.jar.

I decided it would be cleaner though to create my own copy of
webapp.system.scdl (and call it jsonrpc.system.scdl) to put in my
hello world webapp.  I tried this and modified the web.xml to have


systemScdlPath
/META-INF/sca/jsonrpc.system.scdl


However, this gives me a "Null system SCDL URL" Exception thrown.  I
looked at ServletLauncherListener.java and it looks like the
systemScdlPath URL is being loaded with a different classloader than
the applicationScdlPath which may be leading to the exception.

-- 
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: Tuscany war plugin

[Bert Lamb]

Is there more information on what specifically this plugin would need to do?

-Bert

On 8/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

Jim had said that as a prereq to a release then we should have a
maven plugin that will set up the webapp runtime in a war. I think
that having such a beast would make building the samples easier and
so would suggest we get to work on it - is anyone interested in helping?

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

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

[Frank Budinsky (JIRA)]

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

Frank Budinsky updated TUSCANY-605:
---

Component/s: Java SCA Core
 (was: Java SDO Implementation)

Changing component to SCA. Using "SCA Core", because there doesn't seem to be a 
more specific component for the SDO databinding.

> ImportSDOLoader ignoring schemaLocation parameter
> -
>
> Key: TUSCANY-605
> URL: http://issues.apache.org/jira/browse/TUSCANY-605
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>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]

Re: Jetty based standalone distribution (was: Re: Sample framework)

[Jim Marino]

On Aug 29, 2006, at 4:45 AM, ant elder wrote:


Ok Jim, I'd like start work on getting this Jetty based standalone
distribution going. Eventually I'd like a distribution which  
includes things

like Jetty,

So what needs to be done is:

1. Add  an XPath engine into core to evaluate inclusion of a separate  
configuration file to handle setup of things like port (this would  
implement the property inclusion mechanism from the SCA spec)
2. Add an HTTPS connector to Jetty (involves getting it to work with  
a keystore)

3. Cleanup Jetty thread pool integration with the core WorkScheduler
4. A lot more unit tests
5. Integration testing


Axis2/WS, rmi, json, groovy, javascript and spring. I'd also
like some pre-installed samples, maybe  in addition to the  bin,  
boot, and
extensions directories in the existing standalone distribution also  
have an
applications directory to contain the samples and other  
applications. And I

guess some bat/shell scripts to do startup etc.

Anyone else interested in helping with this?

  ...ant





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

Re: [C++] Build instructions on Web site

[Oisin Hurley]

On 28 Aug 2006, at 22:56, Jean-Sebastien Delfino wrote:

Would it make sense to publish this: http://www.mail-archive.com/ 
tuscany-dev%40ws.apache.org/msg05276.html
and this: http://www.mail-archive.com/tuscany-dev%40ws.apache.org/ 
msg05379.html

on a "How to build" page on the Tuscany C++ Web site?

Thoughts?


Please do :)

BTW - has anyone done a port to MacOS X 10.4.7 ppc? If not I will get
a start on it - not vital for the roadmap, but it is my machine of
choice and I'll get nothing done if it doesn't work there ;)

 cheers
  --oh

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

Re: Tuscany war plugin

[Jeremy Boynes]

Basically set up jars for the runtime rather than using war  
dependencies to put them in WEB-INF/lib. This would include:

* Copy the webapp host jars to WEB-INF/lib
* Copy the core runtime to e.g. WEB-INF/tuscany/boot
* Take a set of extensions (as artifact references) and add them to  
e.g. WEB-INF/tuscany/extension
* Copy extension dependencies to somewhere an ArtifactRepository can  
find them


It could also check web.xml for the presence of the Tuscany listeners  
etc. and potentially add them.

--
Jeremy

On Aug 29, 2006, at 7:20 AM, Bert Lamb wrote:

Is there more information on what specifically this plugin would  
need to do?


-Bert

On 8/28/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:

Jim had said that as a prereq to a release then we should have a
maven plugin that will set up the webapp runtime in a war. I think
that having such a beast would make building the samples easier and
so would suggest we get to work on it - is anyone interested in  
helping?


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




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

Call for Eclipse tools work items

[Oisin Hurley]

Hi all,
Over at STP we are putting together work items for our next milestone  
and
beyond. Obviously Tuscany and STP have (should have!) close links -  
so what
do you Tuscany developers think we should provide in terms of tooling  
support

for developing Tuscany-based services and assemblies?

 cheers
  --oh

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

Fwd: PHP support on incubator.apache.org

[David Wheeler]

Well, it looks like we can't use PHP on the new site, so I will have to
re-write the generation script to create static HTML pages.

-David

-- Forwarded message --
From: Joshua Slive <[EMAIL PROTECTED]>
Date: Aug 28, 2006 4:43 PM
Subject: Re: PHP support on incubator.apache.org
To: David Wheeler <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]

On 8/28/06, David Wheeler <[EMAIL PROTECTED]> wrote:

Hi,

I'm developing  a new site for the Apache Tuscany to be published at
http://incubator.apache.org/tuscany/

The new site is bsaed around an xml parsing script written in PHP. Would
there be any problems in posting this to the server?


Yes.  We don't run any dynamic content (with the exception of our
download cgi scripts and certain legacy exceptions) on the main
websites.  This allows us to easily mirror/backup/recreate the sites
on other servers.

You can, however, use php to generate your static html that you use
for the site, if you wish.  If you specifically need dynamic content
(to show off your technology, for example), there is a "zones" server
designed for that.  But in this case, I think you would be better off
just choosing a different way to generate your site.  There are plenty
of ways to get static html from xml.

Joshua.

Re: Fwd: PHP support on incubator.apache.org

[Rick]

Dave,
Can you give some consideration to using the Anikia processor for what your 
doing.  I'm not saying I'm big fan of it, but since other projects are also 
using it maybe they too could benefit from your work?  Maybe there is something 
you could contribute back.  Just a thought.


http://jakarta.apache.org/velocity/docs/anakia.html

David Wheeler wrote:

Well, it looks like we can't use PHP on the new site, so I will have to
re-write the generation script to create static HTML pages.

-David

-- Forwarded message --
From: Joshua Slive <[EMAIL PROTECTED]>
Date: Aug 28, 2006 4:43 PM
Subject: Re: PHP support on incubator.apache.org
To: David Wheeler <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]

On 8/28/06, David Wheeler <[EMAIL PROTECTED]> wrote:

Hi,

I'm developing  a new site for the Apache Tuscany to be published at
http://incubator.apache.org/tuscany/

The new site is bsaed around an xml parsing script written in PHP. Would
there be any problems in posting this to the server?


Yes.  We don't run any dynamic content (with the exception of our
download cgi scripts and certain legacy exceptions) on the main
websites.  This allows us to easily mirror/backup/recreate the sites
on other servers.

You can, however, use php to generate your static html that you use
for the site, if you wish.  If you specifically need dynamic content
(to show off your technology, for example), there is a "zones" server
designed for that.  But in this case, I think you would be better off
just choosing a different way to generate your site.  There are plenty
of ways to get static html from xml.

Joshua.



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

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

In your latest drop you have moved the sca-binding-webservice.xsd from the
core xsd folder to 2 separate places! I believe this schema is defined by
the Assembly spec so should it not be in the core?

Cheers,

On 29/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


 ah.. you got me! I will have to merge this with my changes that I am
making. I'd hoped to get these in before you started coding again... but you
never sleep!

I've moved all the osoa/sca code into the cpp extension and just about
have it working. I'll re-factor your binding extension changes in before
checking this in.

Cheers,


 On 29/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Pete,
>
> I replicated your nice implementation extension mechanism to support
> binding extensions as well. All the WS binding support is now packaged
> in two separate ws_reference and ws_service extensions.
>
> I am able to run our Web Service end to end scenarios with this new
> packaging.
>
> I think that we now have a good structure in place for people to be able
>
> to add new bindings and implementations in Dlls / shared libaries
> without requiring any changes in the core runtime.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--

Pete





--
Pete

Re: [C++] Build instructions on Web site

[Jean-Sebastien Delfino]

Oisin Hurley wrote:


On 28 Aug 2006, at 22:56, Jean-Sebastien Delfino wrote:

Would it make sense to publish this: 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05276.html
and this: 
http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg05379.html

on a "How to build" page on the Tuscany C++ Web site?

Thoughts?


Please do :)

BTW - has anyone done a port to MacOS X 10.4.7 ppc? If not I will get
a start on it - not vital for the roadmap, but it is my machine of
choice and I'll get nothing done if it doesn't work there ;)

 cheers
  --oh

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




Great! I don't think that anybody has tried MacOS X yet. It will be 
really great if you can port the Linux build... and then we can all get 
iBooks :)


--
Jean-Sebastien


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

Re: Fwd: PHP support on incubator.apache.org

[David Wheeler]

I'm going to take another look at it, but I'm not sure I will be able to get
it to do things that were suggested in IRC (like have the menu/tabs change
contextually) and it would take to long to try and familiarize myself with
thier code and add support for something like that.

On 8/29/06, Rick <[EMAIL PROTECTED]> wrote:


Dave,
Can you give some consideration to using the Anikia processor for what
your
doing.  I'm not saying I'm big fan of it, but since other projects are
also
using it maybe they too could benefit from your work?  Maybe there is
something
you could contribute back.  Just a thought.

http://jakarta.apache.org/velocity/docs/anakia.html

David Wheeler wrote:
> Well, it looks like we can't use PHP on the new site, so I will have to
> re-write the generation script to create static HTML pages.
>
> -David
>
> -- Forwarded message --
> From: Joshua Slive <[EMAIL PROTECTED]>
> Date: Aug 28, 2006 4:43 PM
> Subject: Re: PHP support on incubator.apache.org
> To: David Wheeler <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
>
> On 8/28/06, David Wheeler <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I'm developing  a new site for the Apache Tuscany to be published at
>> http://incubator.apache.org/tuscany/
>>
>> The new site is bsaed around an xml parsing script written in PHP.
Would
>> there be any problems in posting this to the server?
>
> Yes.  We don't run any dynamic content (with the exception of our
> download cgi scripts and certain legacy exceptions) on the main
> websites.  This allows us to easily mirror/backup/recreate the sites
> on other servers.
>
> You can, however, use php to generate your static html that you use
> for the site, if you wish.  If you specifically need dynamic content
> (to show off your technology, for example), there is a "zones" server
> designed for that.  But in this case, I think you would be better off
> just choosing a different way to generate your site.  There are plenty
> of ways to get static html from xml.
>
> Joshua.
>

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

RE: SCDL extensions to define data types for parameters and return value

[Liu, Jervis]

Yes, multiple databindings can be supported by different reader and writer. 
What I said is that the Celtix 1.0 release only includes the support for JAXB.  
More is being added. 

Jervis

> -Original Message-
> From: Jim Marino [mailto:[EMAIL PROTECTED]
> Sent: 2006?8?29? 15:03
> To: tuscany-dev@ws.apache.org
> Subject: Re: SCDL extensions to define data types for 
> parameters and return value
> 
> 
> > Also to answer Jeremy's question raise before: "I believe Celtix  
> > uses WSDL extensions for this i.e. annotations added
> > to the WSDL or possibly the underlying XMLSchema to indicate the  
> > data binding to use. ". This is not true. Celtix1.0 only supports  
> > jaxb,
> 
> Hi Jervis,
> 
> I thought Celtix supported multiple databindings through NodeReader/ 
> NodeWriter? Is that wrong?
> 
> 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]

Re: [C++] Extension mechanism for implementations and bindings

[Jean-Sebastien Delfino]

Pete Robbins wrote:
In your latest drop you have moved the sca-binding-webservice.xsd from 
the

core xsd folder to 2 separate places! I believe this schema is defined by
the Assembly spec so should it not be in the core?

Cheers,


Pete,

Good question: I'm not sure what to do about it... The 0.96 assembly 
spec document still contains the webservice binding XSD but the OSOA web 
site now shows a completely different section for bindings, so I was 
assuming that the web service binding was going to be in a separate spec 
document (on this page 
http://www.osoa.org/display/Main/SCA+WebService+Bindings).


The other issue is what to do if multiple extensions share a common XSD. 
The ws_reference and ws_service extensions can be installed separately 
and they both need that XSD... I couldn't think of a good solution to 
package a single copy of the XSD shared by both, but not part of the core.


If that helps in the short term we can keep that webservice binding XSD 
in /xsd like it was before. Do you want me to move it back?


--
Jean-Sebastien


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

Re: PHP support on incubator.apache.org

[Jeremy Boynes]

On Aug 29, 2006, at 9:18 AM, David Wheeler wrote:

I'm going to take another look at it, but I'm not sure I will be  
able to get
it to do things that were suggested in IRC (like have the menu/tabs  
change
contextually) and it would take to long to try and familiarize  
myself with

thier code and add support for something like that.


You can do the context menu stuff - you can either use a separate  
style sheet per section, or have a single style sheet that includes a  
menu based on a property in the XML.

--
Jeremy


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

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

Could the ws binding extension be packaged as:

extensions/
   ws/
reference
service
xsd

?

It's not a major issue for now. I'd like to drop in a load of changes that
move the osoa/sca to the cpp extension. I'm having trouble with windows
running the Calculator sample :-( It's a problem with passing std::map
across dll boundaries I think. I'm tempted to drop the code in and get it
running on linux as windows is "broken" at the moment anyway.

Cheers

On 29/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Pete Robbins wrote:
> In your latest drop you have moved the sca-binding-webservice.xsd from
> the
> core xsd folder to 2 separate places! I believe this schema is defined
by
> the Assembly spec so should it not be in the core?
>
> Cheers,
>
Pete,

Good question: I'm not sure what to do about it... The 0.96 assembly
spec document still contains the webservice binding XSD but the OSOA web
site now shows a completely different section for bindings, so I was
assuming that the web service binding was going to be in a separate spec
document (on this page
http://www.osoa.org/display/Main/SCA+WebService+Bindings).

The other issue is what to do if multiple extensions share a common XSD.
The ws_reference and ws_service extensions can be installed separately
and they both need that XSD... I couldn't think of a good solution to
package a single copy of the XSD shared by both, but not part of the core.

If that helps in the short term we can keep that webservice binding XSD
in /xsd like it was before. Do you want me to move it back?

--
Jean-Sebastien


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





--
Pete

Re: [C++] Extension mechanism for implementations and bindings

[Jean-Sebastien Delfino]

Pete Robbins wrote:
[snip]

Could the ws binding extension be packaged as:

extensions/
   ws/
reference
service
xsd

?



Yes, looks good to me.

--
Jean-Sebastien


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

Re: SCDL extensions to define data types for parameters and return value

[Jim Marino]

Ah o.k that clarifies things.

Jim

On Aug 29, 2006, at 9:17 AM, Liu, Jervis wrote:

Yes, multiple databindings can be supported by different reader and  
writer. What I said is that the Celtix 1.0 release only includes  
the support for JAXB.  More is being added.


Jervis


-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 2006?8?29? 15:03
To: tuscany-dev@ws.apache.org
Subject: Re: SCDL extensions to define data types for
parameters and return value



Also to answer Jeremy's question raise before: "I believe Celtix
uses WSDL extensions for this i.e. annotations added
to the WSDL or possibly the underlying XMLSchema to indicate the
data binding to use. ". This is not true. Celtix1.0 only supports
jaxb,


Hi Jervis,

I thought Celtix supported multiple databindings through NodeReader/
NodeWriter? Is that wrong?

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++] Extension mechanism for implementations and bindings

[Pete Robbins]

ok. I have windows nearly working now! The problem was a bug in MS STL map
implemenation. I had to change the way we pass the services/references maps
back to be a reference then iterate over using size() rather than
.end().

As an aside I can't get the linux code to build at the moment. It fails
building the scatest stuff. I think this test is in the wrong place now and
I will disable building it for now.

Cheers,


On 29/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Pete Robbins wrote:
[snip]
> Could the ws binding extension be packaged as:
>
> extensions/
>ws/
> reference
> service
> xsd
>
> ?
>

Yes, looks good to me.

--
Jean-Sebastien


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





--
Pete

Re: SCDL extensions to define data types for parameters and return value

[Raymond Feng]

Hi,

Sometimes it would be difficult to annotate the WSDL to add "databinding" 
extensions because the WSDL could be from external web services. I think 
your idea is similar to java annotations. Usually, the metadata in SCDL 
should override those from java/wsdl annotations.


Thanks,
Raymond

- Original Message - 
From: "Venkata Krishnan" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, August 29, 2006 1:53 AM
Subject: Re: SCDL extensions to define data types for parameters and return 
value




Hi Raymond,


How about defining databidings separately instead of embedded them as
extensions to the interface.wsdl. Right now I take the case of a WSDL to
express what I mean to say. In a WSDL...
- the message are defined
- then we have wsdl:porttype element and its children defined around these
messages
- we then have wsdl:binding that defines bindings around this portype
- then the service definitions around the bindings
- why not have something like  that defines the databiding. 
If

this defn. is there then it is taken up and used otherwise the defaults
apply.

Is there something similar that we can do for what we define in SCDLs. ?
This way the interfaces definitions and the databidings are kept apart. 
If

there is a databiding defn. it will have info about which interface (by
name) it should be applied to.

Makes sense?

Thanks

- Venkat


On 8/29/06, Jim Marino <[EMAIL PROTECTED]> wrote:


> Also to answer Jeremy's question raise before: "I believe Celtix
> uses WSDL extensions for this i.e. annotations added
> to the WSDL or possibly the underlying XMLSchema to indicate the
> data binding to use. ". This is not true. Celtix1.0 only supports
> jaxb,

Hi Jervis,

I thought Celtix supported multiple databindings through NodeReader/
NodeWriter? Is that wrong?

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]

LoaderUtil missing resource exception, was Re: Can't load implementation.composite

[Ignacio Silva-Lepe]

Ok, I am being hit by this problem again, despite the temporary hack that 
tries the old class loader in LoaderUtil if the current class loader does 
not work. Furthermore, the missing resource is not an app resource any more. 
I am not really familiar with how class loaders are being handled. Trying to 
chase this down is probably going to take me more time than whoever may be 
more familiar with class loader set up. I am trying to verify my latest 
inner.composite sample, which was running previous to doing an update (which 
in turn I did to be able to post the patch including this latest 
inner.composite sample) and this is getting in the way.


Here's the actual exception I am getting:

---
T E S T S
---
Running innercomposite.InnerCompositeTestCase
Trying old class loader
Still not found
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.551 sec 
<<< FA

ILURE!
test(innercomposite.InnerCompositeTestCase)  Time elapsed: 0.521 sec  <<< 
ERROR!


org.apache.tuscany.spi.loader.MissingResourceException: 
org.apache.tuscany.core.

idl.java.InterfaceJavaIntrospectorImpl
Context stack trace: [tuscany.system][interfaceJava.introspector]
   at 
org.apache.tuscany.spi.loader.LoaderUtil.loadClass(LoaderUtil.java:75

)
   at 
org.apache.tuscany.core.implementation.system.loader.SystemImplementa

tionLoader.load(SystemImplementationLoader.java:58)
   at 
org.apache.tuscany.core.implementation.system.loader.SystemImplementa

tionLoader.load(SystemImplementationLoader.java:41)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:92)
   at 
org.apache.tuscany.core.loader.ComponentLoader.loadImplementation(Com

ponentLoader.java:131)
   at 
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j

ava:84)
   at 
org.apache.tuscany.core.loader.ComponentLoader.load(ComponentLoader.j

ava:57)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:92)
   at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load

(CompositeLoader.java:77)
   at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load

(CompositeLoader.java:52)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:92)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:109)
   at 
org.apache.tuscany.core.loader.IncludeLoader.loadFromSidefile(Include

Loader.java:92)
   at 
org.apache.tuscany.core.loader.IncludeLoader.load(IncludeLoader.java:

80)
   at 
org.apache.tuscany.core.loader.IncludeLoader.load(IncludeLoader.java:

47)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:92)
   at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load

(CompositeLoader.java:77)
   at 
org.apache.tuscany.core.implementation.composite.CompositeLoader.load

(CompositeLoader.java:52)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:92)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.load(LoaderRegistry

Impl.java:109)
   at 
org.apache.tuscany.core.implementation.system.loader.SystemCompositeC

omponentTypeLoader.loadFromSidefile(SystemCompositeComponentTypeLoader.java:68)
   at 
org.apache.tuscany.core.implementation.system.loader.SystemCompositeC

omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:59)
   at 
org.apache.tuscany.core.implementation.system.loader.SystemCompositeC

omponentTypeLoader.load(SystemCompositeComponentTypeLoader.java:38)
   at 
org.apache.tuscany.core.loader.LoaderRegistryImpl.loadComponentType(L

oaderRegistryImpl.java:159)
   at 
org.apache.tuscany.core.deployer.DeployerImpl.load(DeployerImpl.java:

118)
   at 
org.apache.tuscany.core.deployer.DeployerImpl.deploy(DeployerImpl.jav

a:93)
   at 
org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime(LauncherImp

l.java:100)
   at 
org.apache.tuscany.core.launcher.LauncherImpl.bootRuntime(LauncherImp

l.java:157)
   at org.apache.tuscany.test.SCATestCase.setUp(SCATestCase.java:54)
   at 
innercomposite.InnerCompositeTestCase.setUp(InnerCompositeTestCase.ja

va:30)

And here's the contents of LoaderUtil.loadClass that includes the hack that 
allowed me to make progress earlier:


   public static Class loadClass(String name, ClassLoader cl) throws 
MissingResourceException {

   final Thread thread = Thread.currentThread();
   final ClassLoader oldCL = thread.getContextClassLoader();
   try {
   thread.setContextClassLoader(cl);
   return Class.forName(name, true, cl);
   } catch (ClassNotFoundException e) {
   try { System.out.println("Trying old class loader");return 
Class.forName(name, true, oldCL); }
   catch(ClassNotFou

[jira] Created: (TUSCANY-673) support scdlLocation attribute on

[Jeremy Boynes (JIRA)]

support scdlLocation attribute on 


 Key: TUSCANY-673
 URL: http://issues.apache.org/jira/browse/TUSCANY-673
 Project: Tuscany
  Issue Type: Improvement
  Components: Java SCA Core
Reporter: Jeremy Boynes
 Assigned To: Ignacio Silva-Lepe


When using a composite as an implementation, we should provide a way for the 
user to specify the location of the SCDL for the composite


...

The location should be resolved relative to the location of the outer composite.

-- 
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: Tuscany war plugin

[Chris Wall]

Darn good idea.  Meeraj et al., let me know if you need help.  I can help
out w/ development or simply being a guniea pig.

-Chris

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

[Raymond Feng (JIRA)]

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

Raymond Feng reassigned TUSCANY-605:


Assignee: Raymond Feng

> ImportSDOLoader ignoring schemaLocation parameter
> -
>
> Key: TUSCANY-605
> URL: http://issues.apache.org/jira/browse/TUSCANY-605
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Reporter: Kapil Katyal
> Assigned To: Raymond Feng
>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]

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

[Raymond Feng (JIRA)]

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

Raymond Feng resolved TUSCANY-605.
--

Resolution: Fixed

Fixed by http://svn.apache.org/viewvc?view=rev&revision=438155

> ImportSDOLoader ignoring schemaLocation parameter
> -
>
> Key: TUSCANY-605
> URL: http://issues.apache.org/jira/browse/TUSCANY-605
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Core
>Reporter: Kapil Katyal
> Assigned To: Raymond Feng
>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]

[jira] Created: (TUSCANY-674) DAS: Modify test framework to facilitate support for new vendors

[Brent Daniel (JIRA)]

DAS: Modify test framework to facilitate support for new vendors


 Key: TUSCANY-674
 URL: http://issues.apache.org/jira/browse/TUSCANY-674
 Project: Tuscany
  Issue Type: Improvement
  Components: Java DAS RDB
Reporter: Brent Daniel
 Assigned To: Brent Daniel


Currently, to add support for a new database vendor in the DAS test framework, 
you have to write a large number of SQL queries to override the defaults. It 
would be easier to add support for new vendors if subclasses of DatabaseSetup 
only had to define what is different (eg, type names and such) rather than 
writing an entire query. 

-- 
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] Updated: (TUSCANY-673) support scdlLocation attribute on

[Ignacio Silva-Lepe (JIRA)]

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

Ignacio Silva-Lepe updated TUSCANY-673:
---

Attachment: ImplementationCompositeLoader.patch

> support scdlLocation attribute on 
> 
>
> Key: TUSCANY-673
> URL: http://issues.apache.org/jira/browse/TUSCANY-673
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core
>Reporter: Jeremy Boynes
> Assigned To: Ignacio Silva-Lepe
> Attachments: ImplementationCompositeLoader.patch
>
>
> When using a composite as an implementation, we should provide a way for the 
> user to specify the location of the SCDL for the composite
> 
> 
> ...
> The location should be resolved relative to the location of the outer 
> composite.

-- 
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] Updated: (TUSCANY-673) support scdlLocation attribute on

[Ignacio Silva-Lepe (JIRA)]

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

Ignacio Silva-Lepe updated TUSCANY-673:
---

Attachment: ImplementationCompositeLoaderAndTest.patch

> support scdlLocation attribute on 
> 
>
> Key: TUSCANY-673
> URL: http://issues.apache.org/jira/browse/TUSCANY-673
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core
>Reporter: Jeremy Boynes
> Assigned To: Ignacio Silva-Lepe
> Attachments: ImplementationCompositeLoader.patch, 
> ImplementationCompositeLoaderAndTest.patch
>
>
> When using a composite as an implementation, we should provide a way for the 
> user to specify the location of the SCDL for the composite
> 
> 
> ...
> The location should be resolved relative to the location of the outer 
> composite.

-- 
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] Closed: (TUSCANY-673) support scdlLocation attribute on

[Jeremy Boynes (JIRA)]

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

Jeremy Boynes closed TUSCANY-673.
-

Resolution: Fixed

Patch applied - thanks

> support scdlLocation attribute on 
> 
>
> Key: TUSCANY-673
> URL: http://issues.apache.org/jira/browse/TUSCANY-673
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Core
>Reporter: Jeremy Boynes
> Assigned To: Ignacio Silva-Lepe
> Attachments: ImplementationCompositeLoader.patch, 
> ImplementationCompositeLoaderAndTest.patch
>
>
> When using a composite as an implementation, we should provide a way for the 
> user to specify the location of the SCDL for the composite
> 
> 
> ...
> The location should be resolved relative to the location of the outer 
> composite.

-- 
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: svn commit: r438171 - in /incubator/tuscany/java/sca/core/src: main/java/org/apache/tuscany/core/implementation/composite/ test/java/org/apache/tuscany/core/implementation/composite/

[Jeremy Boynes]

Ignacio

I committed this but have a couple comments on the patch if you can  
address them:
* rather than catch Exception can you explicitly catch  
MalformedURLException
* rather than throw LoaderException, can you throw an  
InvalidValueException (with the identifier set to the name)

* you probably should check for a null (missing) attribute value

I would also be good to test for these things in the test case - at  
least check that scdlLocation is set in the returned impl.


Thanks
--
Jeremy

On Aug 29, 2006, at 12:26 PM, [EMAIL PROTECTED] wrote:


Author: jboynes
Date: Tue Aug 29 12:26:05 2006
New Revision: 438171

URL: http://svn.apache.org/viewvc?rev=438171&view=rev
Log:
apply patch from Ignacio Silva-Lupe for TUSCANY-673

Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoaderTestCase.java


Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/main/java/org/apache/tuscany/core/implementation/composite/ 
ImplementationCompositeLoader.java? 
rev=438171&r1=438170&r2=438171&view=diff
== 

--- incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoader.java Tue Aug 29 12:26:05 2006

@@ -18,21 +18,22 @@
  */
 package org.apache.tuscany.core.implementation.composite;

+import java.net.URL;
 import javax.xml.namespace.QName;
-import javax.xml.stream.XMLStreamReader;
 import javax.xml.stream.XMLStreamException;
+import javax.xml.stream.XMLStreamReader;

 import org.osoa.sca.Version;
 import org.osoa.sca.annotations.Constructor;

-import org.apache.tuscany.spi.extension.LoaderExtension;
-import org.apache.tuscany.spi.model.CompositeImplementation;
+import org.apache.tuscany.spi.annotation.Autowire;
 import org.apache.tuscany.spi.component.CompositeComponent;
 import org.apache.tuscany.spi.deployer.DeploymentContext;
+import org.apache.tuscany.spi.extension.LoaderExtension;
 import org.apache.tuscany.spi.loader.LoaderException;
-import org.apache.tuscany.spi.loader.LoaderUtil;
 import org.apache.tuscany.spi.loader.LoaderRegistry;
-import org.apache.tuscany.spi.annotation.Autowire;
+import org.apache.tuscany.spi.loader.LoaderUtil;
+import org.apache.tuscany.spi.model.CompositeImplementation;

 /**
  * Loader that handles an  element.
@@ -41,7 +42,7 @@
  */
 public class ImplementationCompositeLoader extends  
LoaderExtension {

 private static final QName IMPLEMENTATION_COMPOSITE =
-new QName(Version.XML_NAMESPACE_1_0,  
"implementation.composite");
+new QName(Version.XML_NAMESPACE_1_0,  
"implementation.composite");


 @Constructor({"registry"})
 public ImplementationCompositeLoader(@Autowire LoaderRegistry  
registry) {

@@ -59,8 +60,17 @@

 assert IMPLEMENTATION_COMPOSITE.equals(reader.getName());
 String name = reader.getAttributeValue(null, "name");
+String scdlLocation = reader.getAttributeValue(null,  
"scdlLocation");

 CompositeImplementation impl = new CompositeImplementation();
 impl.setName(name);
+URL scdlLocationURL;
+try {
+scdlLocationURL = new URL 
(deploymentContext.getScdlLocation(), scdlLocation);

+} catch (Exception e) {
+throw new LoaderException(e);
+}
+impl.setScdlLocation(scdlLocationURL);
+impl.setClassLoader(deploymentContext.getClassLoader());
 LoaderUtil.skipToEndElement(reader);
 return impl;
 }

Modified: incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/test/java/org/apache/tuscany/core/implementation/composite/ 
ImplementationCompositeLoaderTestCase.java? 
rev=438171&r1=438170&r2=438171&view=diff
== 

--- incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/implementation/composite/ 
ImplementationCompositeLoaderTestCase.java Tue Aug 29 12:26:05 2006

@@ -18,6 +18,9 @@
  */
 package org.apache.tuscany.core.implementation.composite;

+import java.net.MalformedURLException;
+import java.net.URL;
+
 import javax.x

Re: [C++] Extension mechanism for implementations and bindings

[Andrew Borley]

On 8/29/06, Pete Robbins <[EMAIL PROTECTED]> wrote:


ok. I have windows nearly working now! The problem was a bug in MS STL map
implemenation. I had to change the way we pass the services/references
maps
back to be a reference then iterate over using size() rather than
.end().



Another reason to look at moving to stdcxx?

As an aside I can't get the linux code to build at the moment. It fails

building the scatest stuff. I think this test is in the wrong place now
and
I will disable building it for now.



All this stuff looks good - I've got a few chunks of code that can run
Python scripts and classes. When you think things have settled enough I'll
sort out a Python extension based on the C++ one we now have.

Cheers
Andy




On 29/08/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Pete Robbins wrote:
> [snip]
> > Could the ws binding extension be packaged as:
> >
> > extensions/
> >ws/
> > reference
> > service
> > xsd
> >
> > ?
> >
>
> Yes, looks good to me.
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Pete

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

On 29/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:


On 8/29/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
>
> ok. I have windows nearly working now! The problem was a bug in MS STL
map
> implemenation. I had to change the way we pass the services/references
> maps
> back to be a reference then iterate over using size() rather than
> .end().


Another reason to look at moving to stdcxx?




Yes!! It wasted at lesat 3 hours of my time.


As an aside I can't get the linux code to build at the moment. It fails

> building the scatest stuff. I think this test is in the wrong place now
> and
> I will disable building it for now.


All this stuff looks good - I've got a few chunks of code that can run
Python scripts and classes. When you think things have settled enough I'll
sort out a Python extension based on the C++ one we now have.



Hopefully tomorrow it will be fairly stable. In the next few hours it will
be highly unstable as I check in today's refactor.

Cheers,

--
Pete

[jira] Updated: (TUSCANY-674) DAS: Modify test framework to facilitate support for new vendors

[Brent Daniel (JIRA)]

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

Brent Daniel updated TUSCANY-674:
-

Attachment: tuscany674.txt

I think there are further improvements to make here (such as tracking whether a 
database supports ResultSetMetadata), but this patch will help a lot. 

> DAS: Modify test framework to facilitate support for new vendors
> 
>
> Key: TUSCANY-674
> URL: http://issues.apache.org/jira/browse/TUSCANY-674
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java DAS RDB
>Reporter: Brent Daniel
> Assigned To: Brent Daniel
> Attachments: tuscany674.txt
>
>
> Currently, to add support for a new database vendor in the DAS test 
> framework, you have to write a large number of SQL queries to override the 
> defaults. It would be easier to add support for new vendors if subclasses of 
> DatabaseSetup only had to define what is different (eg, type names and such) 
> rather than writing an entire query. 

-- 
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] Updated: (TUSCANY-671) Port JSON-RPC binding from M1

[Bert Lamb (JIRA)]

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

Bert Lamb updated TUSCANY-671:
--

Attachment: json-rpc-binding.zip

After a lot of time wrestling with creating a patch file I was unsuccessful and 
so I am attaching this zip instead.  It includes the port of the JSON-RPC 
binding and the sample helloworldjsonrpc web app.

> Port JSON-RPC binding from M1
> -
>
> Key: TUSCANY-671
> URL: http://issues.apache.org/jira/browse/TUSCANY-671
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA JsonRpc Binding
>Affects Versions: Java-M2
>Reporter: Bert Lamb
>Priority: Minor
> Attachments: json-rpc-binding.zip
>
>
> Port the JSON-RPC binding from M1 into the new binding format.  I've been 
> working on this, so I should be able to post a patch soon.

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

Build failure

[J T Hsiao]

Hey,

I was trying to build Tuscany project from java\sca directory but got the
following errors.  Not sure why it needs the plexus SNAPSHOT.  BTW, this
directory does not exist on apache m2 repo.  Can someone shed some lights on
this?

Regards,
Eric

--

Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
pom
[WARNING] Unable to get resource from repository apache-snapshot-repository
(htt
p://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
pom
[WARNING] Unable to get resource from repository apache.snapshots (
http://people
.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
jar
[WARNING] Unable to get resource from repository apache-snapshot-repository
(htt
p://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
jar
[WARNING] Unable to get resource from repository apache.snapshots (
http://people
.apache.org/repo/m2-snapshot-repository)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=org.codehaus.plexus-DartifactId=plexus
-archiver \
 -Dversion=1.0-alpha-7-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1)
org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.1-20060826.1
62339-6
   2) org.apache.maven:maven-archiver:jar:2.2-SNAPSHOT
   3) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT

Re: Build failure

[Jeremy Boynes]

IIRC plexus-archiver is hosted at codehaus so you need to add

codehaus-snapshot
Codehaus Snapshot Repository
http://snapshots.repository.codehaus.org

true



to the  section of the pom.

I thought this was only used by the assembly plugin but I guess not -  
can you say which pom was building when it broke?

Thanks
--
Jeremy

On Aug 29, 2006, at 1:22 PM, J T Hsiao wrote:


Hey,

I was trying to build Tuscany project from java\sca directory but  
got the
following errors.  Not sure why it needs the plexus SNAPSHOT.  BTW,  
this
directory does not exist on apache m2 repo.  Can someone shed some  
lights on

this?

Regards,
Eric

-- 
-- 
-- 



Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
pom
[WARNING] Unable to get resource from repository apache-snapshot- 
repository

(htt
p://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
pom
[WARNING] Unable to get resource from repository apache.snapshots (
http://people
.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
jar
[WARNING] Unable to get resource from repository apache-snapshot- 
repository

(htt
p://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-
archiver-1.0-alpha-7-SNAPSHOT.
jar
[WARNING] Unable to get resource from repository apache.snapshots (
http://people
.apache.org/repo/m2-snapshot-repository)
[INFO]
-- 
--

[ERROR] BUILD ERROR
[INFO]
-- 
--

[INFO] Failed to resolve artifact.

Missing:
--
1) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=org.codehaus.plexus- 
DartifactId=plexus

-archiver \
 -Dversion=1.0-alpha-7-SNAPSHOT -Dpackaging=jar
-Dfile=/path/to/file

 Path to dependency:
   1)
org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.1-20060826.1
62339-6
   2) org.apache.maven:maven-archiver:jar:2.2-SNAPSHOT
   3) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT



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

Re: SCDL extensions to define data types for parameters and return value

[Raymond Feng]

Hi,

I agree with you that only one databinding will be used for the same 
interface for most cases.


I have a case that we need at least operation-level databinding. For SCA 
reference/service with JCA bindings, we need databindings to deal with the 
native EIS data format (for example, CCI record) at "Interaction" level 
which usually maps to an operation in the ServiceContract. For your 
reference, there's EMD spec from IBM & BEA @ 
ftp://www6.software.ibm.com/software/developer/library/j-emd/EnterpriseMetadataDiscoverySpecification.pdf 
nad it talks about DataBinding for SDO<-->EIS transformations.


Jeremy, do you have some use cases that we need to go to the 
parameter/return value level?


Thanks,
Raymond

- Original Message - 
From: "Liu, Jervis" <[EMAIL PROTECTED]>

To: 
Sent: Monday, August 28, 2006 11:57 PM
Subject: RE: SCDL extensions to define data types for parameters and return 
value



Hi Raymond,

I doubt there is a need to mix different data bindings for a same interface. 
Can someone name a valid use case, for example, different operations are 
using different data bindings? If we can safely assume one interface is 
always implemented by one specific data binding, things can be simplified 
greatly. For example, we wont end of with a very complex scdl as you 
mentioned before:



   ...
   http://tuscany.apache.org/xmlns/1.0-SNAPSHOT"; dataType="sdo">


   
   
 
   http://customer}Customer"/>

 
.

A simple configuration e.g. a property to specify which data binding 
(jaxb/sdo/xmlbeans etc) is used should be enough.


Also to answer Jeremy's question raise before: "I believe Celtix uses WSDL 
extensions for this i.e. annotations added
to the WSDL or possibly the underlying XMLSchema to indicate the data 
binding to use. ". This is not true. Celtix1.0 only supports jaxb, 
CeltixFire( the apache project that is a merge between Celtix and XFire) 
will support multiple data bindings, but I don't think there will be any 
thing related to data bindings being added into wsdl or xmlschema. It is 
configured by a configuration somewhere. This follows the same principle 
used by SCA: as long as the two interface types are equivalent, they can 
talk to each other without knowing what the underlying data binding is, 
which means the interface definition should not be polluted by data 
bindings.


Cheers,
Jervis




-Original Message-
From: Raymond Feng [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 29, 2006 12:25 AM
To: tuscany-dev@ws.apache.org
Subject: Re: SCDL extensions to define data types for parameters and
return value


Hi,

When we use WSDL as an IDL in a java runtime, we probably
have assumed some
data mapping rules because WSDL usually uses XML schema to
define the data
types. To provide/consume data in java for a WSDL operation,
we have to use
an XML info model such as DOM, AXIOM, SDO, and JAXB.

The SCA spec defines some rules for the java<-->WSDL mapping
as quoted
below:

"1.3.4.4 Mapping of Java Interfaces to & from WSDL Interfaces

A Wire can connect between interfaces defined by different
languages ie.
Java interfaces and
WSDL portTypes/WSDL interfaces in either direction, as long as the
operations defined by the
two interface types are equivalent. They are equivalent if
the operation(s),
parameter(s), return
value(s) and faults/exceptions map to each other.

SCA maps Java interfaces to and from WSDL interfaces using
the mapping
defined by the JAXWS
specification [4], with the following differences:
. Complex parameters and return values in WSDL operations
may be mapped
as SDOs, using the mapping defined in the SDO 2.0 specification [2]
. Holder classes are not supported"

Based on this, I think we should at least support JAXB and
SDO databindings
for the WSDL. It's not very clear in the spec which
databinding is the
default. Maybe we can introspect the value to figure out
which one is in
use.

For the granularity,  it seems to me that we use the same
databinding for
the whole interface in most cases. But we can support operation and
parameter levels if required. I guess we need to modify the
ServiceContract/Operation model to capture the default
databinding at its
own level.

Thanks,
Raymond

- Original Message - 
From: "ant elder" <[EMAIL PROTECTED]>

To: 
Sent: Friday, August 25, 2006 2:44 AM
Subject: Re: SCDL extensions to define data types for
parameters and return
value


> What I'm trying to see is the minimum needed to get
assemblies going with
> different data bindings. One difference with using WSDL
portTypes is that
> you can't use introspection or annotations so all the
config needs to be
> done in the SCDL. I'm also wondering about the config for
the source and
> target ends of the wires which is why the example i asked
about earlier
> had
> a service wired to a component wired to a reference. Could
you use that
> example an

Introspect WSDL to create WSDLServiceContract

[Raymond Feng]

Hi,

Do we have the requirement to introspect a WSDL port type to create the 
corresponding WSDLServiceContract? If so, we'll probably need to add an 
"InterfaceWSDLIntrospector" as we do for java.

Or do we assume we always perform WSDL2Java (statically with code-generation or 
dynamically with ASM during runtime) to create a java interface which can be 
introspected to get the JavaServiceContract?

Thanks,
Raymond 

How to invoke a web service with complex types? Java object / SDO conversion?

[Chris Wall]

What are the steps to invoke a web service that requests a complex type?

My client uses Java domain objects that represent web service complex types
throughout the application.  Does the client need to generate SDO types from
the WSDL, and then convert local objects to their SDO representation prior
to web service invocation?

What is the function of ImportSDOLoader ()?  Does it
register schema types from a WSDL with SDO?  How are the types used later?

Thanks.

-Chris

Re: Introspect WSDL to create WSDLServiceContract

[Jeremy Boynes]

On Aug 29, 2006, at 2:01 PM, Raymond Feng wrote:


Hi,

Do we have the requirement to introspect a WSDL port type to create  
the corresponding WSDLServiceContract? If so, we'll probably need  
to add an "InterfaceWSDLIntrospector" as we do for java.


Yes.

Or do we assume we always perform WSDL2Java (statically with code- 
generation or dynamically with ASM during runtime) to create a java  
interface which can be introspected to get the JavaServiceContract?


The builders should work off the Operations defined in the  
ServiceContract (perhaps with certain optimizations if they know the  
IDL) so ultimately there should be no need to convert to  
JavaServiceContract - I think Jim is working on that (e.g. r438003).


--
Jeremy


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

[jira] Created: (TUSCANY-675) XPATH doesnt support dots in names (treats them as indices) in Java Implementation

[Hasan Muhammad (JIRA)]

XPATH doesnt support dots in names (treats them as indices) in Java 
Implementation
--

 Key: TUSCANY-675
 URL: http://issues.apache.org/jira/browse/TUSCANY-675
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-M2
 Environment: All
Reporter: Hasan Muhammad


When you try to do the following:

DataObject impJava = scaObj.getDataObject("component[1]/implementation.java");

It results in the following exception:

java.lang.NumberFormatException: For input string: "java"
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:63)
at java.lang.Integer.parseInt(Integer.java:481)
at java.lang.Integer.parseInt(Integer.java:531)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.process(DataObjectUtil.java:2097)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.init(DataObjectUtil.java:1918)
at 
org.apache.tuscany.sdo.util.DataObjectUtil$Accessor.create(DataObjectUtil.java:1838)
at 
org.apache.tuscany.sdo.util.DataObjectUtil.get(DataObjectUtil.java:738)
at 
org.apache.tuscany.sdo.impl.DataObjectImpl.get(DataObjectImpl.java:213)
at 
org.apache.tuscany.sdo.impl.DataObjectImpl.getDataObject(DataObjectImpl.java:323)
at 
com.ibm.ws.sca2.module.loader.test.SDOLoaderTest.main(SDOLoaderTest.java:60)

It is clear that it is trying to treat the string after "." as an index..

-- 
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: Build failure

[J T Hsiao]

Hi, Jeremy,Thanks, that fixed the problem.  The pom that was building when the error occurred is java\sca\pom.xml.  After this I was getting some test failures while building core; see attached.  Not sure if the tests need to be changed or...  
Eric   On 8/29/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
IIRC plexus-archiver is hosted at codehaus so you need to add  codehaus-snapshot Codehaus Snapshot Repository
 http://snapshots.repository.codehaus.org  true
  to the  section of the pom.I thought this was only used by the assembly plugin but I guess not -can you say which pom was building when it broke?
Thanks--JeremyOn Aug 29, 2006, at 1:22 PM, J T Hsiao wrote:> Hey,>> I was trying to build Tuscany project from java\sca directory but> got the> following errors.  Not sure why it needs the plexus SNAPSHOT.  BTW,
> this> directory does not exist on apache m2 repo.  Can someone shed some> lights on> this?>> Regards,> Eric>> --
> --> --> >> Downloading:> 
http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p> lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-> archiver-1.0-alpha-7-SNAPSHOT.> pom> [WARNING] Unable to get resource from repository apache-snapshot-
> repository> (htt> p://people.apache.org/repo/m2-snapshot-repository)> Downloading:> http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
> lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-> archiver-1.0-alpha-7-SNAPSHOT.> pom> [WARNING] Unable to get resource from repository apache.snapshots (> 
http://people> .apache.org/repo/m2-snapshot-repository)> Downloading:> http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
> lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-> archiver-1.0-alpha-7-SNAPSHOT.> jar> [WARNING] Unable to get resource from repository apache-snapshot-> repository> (htt
> p://people.apache.org/repo/m2-snapshot-repository)> Downloading:> http://people.apache.org/repo/m2-snapshot-repository/org/codehaus/p
> lexus/plexus-archiver/1.0-alpha-7-SNAPSHOT/plexus-> archiver-1.0-alpha-7-SNAPSHOT.> jar> [WARNING] Unable to get resource from repository apache.snapshots (> 
http://people> .apache.org/repo/m2-snapshot-repository)> [INFO]> --> --> [ERROR] BUILD ERROR> [INFO]> --
> --> [INFO] Failed to resolve artifact.>> Missing:> --> 1) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT>>  Try downloading the file manually from the project website.
>>  Then, install it using the command:>  mvn install:install-file -DgroupId=org.codehaus.plexus-> DartifactId=plexus> -archiver \>  -Dversion=1.0-alpha-7-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file>>  Path to dependency:>1)> org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.1-20060826.1> 62339-6>2) org.apache.maven:maven-archiver:jar:2.2-SNAPSHOT
>3) org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7-SNAPSHOT-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: How to invoke a web service with complex types? Java object / SDO conversion?

[Raymond Feng]

Hi,

I think it should be choice of the application to decide which databinding 
will be used for the client. SDO and JAXB can be two options. Can you 
clarify the term "Java domain objects"? Do you mean a bunch of java 
interfaces/classes generated by some Java/XML binding frameworks such as 
SDO, JAXB and XMLBeans?


FYI: We're working on a pluggable databinding framework for Tuscany so that 
data can be transformed across databindings on the wire. For example, if you 
use SDO on the client to invoke a reference with Axis2 web service binding, 
the SDO will be transformed to AXIOM which is the databinding supported by 
Axis2.


Thanks,
Raymond

- Original Message - 
From: "Chris Wall" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, August 29, 2006 2:05 PM
Subject: How to invoke a web service with complex types? Java object / SDO 
conversion?




What are the steps to invoke a web service that requests a complex type?

My client uses Java domain objects that represent web service complex 
types
throughout the application.  Does the client need to generate SDO types 
from

the WSDL, and then convert local objects to their SDO representation prior
to web service invocation?

What is the function of ImportSDOLoader ()?  Does it
register schema types from a WSDL with SDO?  How are the types used later?

Thanks.

-Chris




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

Re: Text for main page of Tuscany website

[haleh mahbod]

Here is the final text for the website main page (including Sebastien's
comments).
Can someone please post it on the website while we are waiting for David to
complete the prototype?

Welcome to the Apache Tuscany free open source project that is licensed
under version 2 of the Apache
License. This project is
currently in incubation within the Apache incubator.

The aim of the Apache Tuscany project is to create, as a community, a robust
infrastructure that simplifies the development of SOA-based systems.

Apache Tuscany is based on independent technologies that together provide
one complete infrastructure which caters to this goal. This includes the
following:

· Service Component Architecture (SCA) enables composition of
service networks through assembly of existing and new services. As an
example, a service can be a webservice.

Tuscany SCA allows services to be implemented in variety of languages such
as Java, JavaScript and C++. Tuscany SCA runtime is implemented in Java and
C++ and can easily be extended to support any communication transport,
qualities of service or programming model and can be used in conjunction
with other technologies such as Spring, Axis and Celtix.

· Service Data Object (SDO) provides a uniform interface for
handling different forms of data, including XML documents, that can exist in
a network of services and provides the mechanism for tracking changes in
data. Apache Tuscany provides Java and C++ implementations for SDO.

·  Data Access Service (DAS) provides a simple SDO interface to
relational databases. Apache Tuscany provides a Java implementation for DAS.

SCA and SDO technologies can be used independent of one another. The
specifications for these technologies are located at www.osoa.org .  Apache
Tuscany project provides input to the specifications.

Please join us to develop this innovative infrastructure and/or provide
feedback based on real use case scenarios which will help Apache Tuscany
become a first class solution for simplifying the development of SOA-based
systems.


On 8/28/06, Jim Marino <[EMAIL PROTECTED]> wrote:


Sorry for taking so long to answer...I got tied up in some things and
then spaced out on this. I like it and agree with Sebastien's comments.

Thanks, this sounds really good.

Jim
On Aug 28, 2006, at 4:53 PM, Jean-Sebastien Delfino wrote:

> haleh mahbod wrote:
>> Hello Tuscany community,
>>
>> Please review the following  text as a proposed text for our main
>> web page.
>>
>> Jim,
>> Thanks for your feedback. I tried to capture your comments in the new
>> writeup.
>> Please feel free to re-write this if you think it  needs
>> improvement :)
>>
>> Haleh
>> --- Start of text
>> -
>> --
>>
>> Welcome to the Apache Tuscany free open source project that is
>> licensed
>> under version 2 of the Apache
>> License. This project is
>> currently in incubation within the Apache incubator.
>>
>> The aim of the Apache Tuscany project is to create, as a
>> community, a robust
>> infrastructure that simplifies the development of SOA-based systems.
>>
>> Apache Tuscany is based on independent technologies that together
>> provide
>> one complete infrastructure which caters to this goal. This
>> includes the
>> following:
>>
>> · Service Component Architecture (SCA) enables composition of
>> service networks through assembly of existing and new services.
>>
>> Apache Tuscany implements SCA in Java and C++.  Tuscany SCA
>> runtime can
>> easily be extended to support any communication transport,
>> qualities of
>> service or programming model and can be used in conjunction with
>> other
>> technologies such as Spring, Axis and Celtix.
>>
>> · Service Data Object (SDO) provides a uniform interface for
>> handling different forms of data that can exist in a network of
>> services and
>> provides the mechanism for tracking changes in data.  Apache Tuscany
>> provides Java and C++ implementations for SDO.
>>
>> · Service Data Access (DAS) provides a uniform interface for
>> interacting with persistent data when using SDO. Apache Tuscany
>> provides a
>> Java implementation for DAS.
>>
>> SCA and SDO technologies can be used independent of one another. The
>> specifications for these technologies are located at
>> www.osoa.org .  Apache
>> Tuscany project provides input to the specifications.
>>
>> Please join us to develop this innovative infrastructure and/or
>> provide
>> feedback based on real use case scenarios which will help Apache
>> Tuscany
>> become a first class solution for simplifying the development of
>> SOA-based
>> systems.
>> < General Tuscany diagram would go here>
>>
>> On 8/17/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>>>
>>> Thanks Haleh for taking the time to write this up again..

Re: How to invoke a web service with complex types? Java object / SDO conversion?

[Chris Wall]

Hi Raymond.

In our case, the client is privy to the domain objects - Java objects
(interfaces/classes) - used by the web service.  For example, locally the
client uses org.client.Patient throughout the application.  Before invoking
a web service the client converts org.client.Patient to
org.service.Patient(provided by service provider), and then invokes
the web service passing
org.service.Patient.

Migrating this code to Tuscany we're finding that SDO handles the outbound
by converting the Patient object to a String (I think).  The inbound doesn't
convert at all, but instead sends back null.

It would be cool if the binding layer was able to dynamically convert a Java
object to a schema type matching the package name and class name in the
WSDL.  This is the ultimate non-invasive approach.

It sounds as if the WS binding layer for both Axis2 and Celtix support only
SDO as of today.  If this is true, what are the steps to communicate with a
complex type web service?  My guess is:

1.) Generate SDO objects from WSDL using tuscany-sdo-plugin.

2.) Create a service component (@Service) that matches the web service's
method signatures.

3.) In the application scdl, import the WSDL into SDO
().  Although, I'm not sure exactly what
this does.

4.) In the application scdl, configure the service component with the
binding.ws.

5.) Within the client application, convert local Java objects to SDO object
using the Factory created in #1.

6.) Within the client application, locate the service via Tuscany context
and invoke web service proxy method passing in the SDO object.

How does that sound?

-Chris

[jira] Created: (TUSCANY-676) ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap causes NPE (surfaced as IllegalArgumentException)

[Chris Wall (JIRA)]

ImportSDOLoader: DataTypeImpl not found in XSDEcoreBuilder.typeToTypeObjectMap 
causes NPE (surfaced as IllegalArgumentException)


 Key: TUSCANY-676
 URL: http://issues.apache.org/jira/browse/TUSCANY-676
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Reporter: Chris Wall
 Attachments: medrec.zip, xsdecorebuilder_npe.zip

During SDO import of WSDL, elements of the following complex type are not found 
when validated against available SDO datatypes within the XSD layer 
(XSDEcoreBuilder).  Downstream this causes an NPE.  It could be that the 
comparison between the type and the key is not properly implemented.  See the 
attached zip containing debug screenshots.

http://www.w3.org/2001/XMLSchema";>
  

  
  
  
  
  
  
  
  

  


-- 
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: How to invoke a web service with complex types? Java object / SDO conversion?

[Raymond Feng]

Hi, Chris.

Please see my comments in line.

Thanks,
Raymond

- Original Message - 
From: "Chris Wall" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, August 29, 2006 3:00 PM
Subject: Re: How to invoke a web service with complex types? Java object / 
SDO conversion?




Hi Raymond.

In our case, the client is privy to the domain objects - Java objects
(interfaces/classes) - used by the web service.  For example, locally the
client uses org.client.Patient throughout the application.  Before 
invoking

a web service the client converts org.client.Patient to
org.service.Patient(provided by service provider), and then invokes
the web service passing
org.service.Patient.


I assume either the org.service.Patient is generated from WSDL2Java or a 
custom serializer/deserializer is provided to deal with the XML 
marshaling/unmarshaling.




Migrating this code to Tuscany we're finding that SDO handles the outbound
by converting the Patient object to a String (I think).  The inbound 
doesn't

convert at all, but instead sends back null.


I think we only support Java primitive types and SDO types at this moment.



It would be cool if the binding layer was able to dynamically convert a 
Java

object to a schema type matching the package name and class name in the
WSDL.  This is the ultimate non-invasive approach.


We're doing that today for SDO types (matching by the QName of the XSD 
types). Really, the java/xml binding frameworks provide such capabilties. As 
I mentioned before, we're working on a solution to support pluggable 
databindings and transformers can be contributed to Tuscany to deal with 
data transformations on demand.




It sounds as if the WS binding layer for both Axis2 and Celtix support 
only

SDO as of today.


That was a staging hack before the full-blown databinding story is in place.

If this is true, what are the steps to communicate with a

complex type web service?  My guess is:

1.) Generate SDO objects from WSDL using tuscany-sdo-plugin.


You can choose to use statically pre-generated SDO classes or dynamic 
DataObject reflection APIs.




2.) Create a service component (@Service) that matches the web service's
method signatures.

3.) In the application scdl, import the WSDL into SDO
().  Although, I'm not sure exactly what
this does.



It asks the SDO model to be loaded for WSDL/XSD or pre-generated SDO 
classes. With the metadata, we can resolve the XML/Java type mapping by XML 
QNames.



4.) In the application scdl, configure the service component with the
binding.ws.

5.) Within the client application, convert local Java objects to SDO 
object

using the Factory created in #1.


Again, ideally, you can plugin a new databinding for your private java 
objects and contribute transformers to convert it to AXIOM (or going through 
intermediate databindings) and vice versa.




6.) Within the client application, locate the service via Tuscany context
and invoke web service proxy method passing in the SDO object.

How does that sound?

-Chris




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

Re: [C++] Extension mechanism for implementations and bindings

[Pete Robbins]

Linux build looks fine now and Calculator and BigBank work (though BigBank
failed the first time I ran it).

Windows build is lacking the ws_reference/ws_service library builds. I'll
add these tomorrow. Exceptions need some rework to catch the
TuscanyRuntimeExceptions in the cpp extension code and rethrow as
osoa::sca::ServiceRuntimeExceptions.


Cheers,


On 29/08/06, Pete Robbins <[EMAIL PROTECTED]> wrote:




 On 29/08/06, Andrew Borley <[EMAIL PROTECTED]> wrote:
>
> On 8/29/06, Pete Robbins <[EMAIL PROTECTED]> wrote:
> >
> > ok. I have windows nearly working now! The problem was a bug in MS STL
> map
> > implemenation. I had to change the way we pass the services/references
> > maps
> > back to be a reference then iterate over using size() rather than
> > .end().
>
>
> Another reason to look at moving to stdcxx?



 Yes!! It wasted at lesat 3 hours of my time.


As an aside I can't get the linux code to build at the moment. It fails
> > building the scatest stuff. I think this test is in the wrong place
> now
> > and
> > I will disable building it for now.
>
>
> All this stuff looks good - I've got a few chunks of code that can run
> Python scripts and classes. When you think things have settled enough
> I'll
> sort out a Python extension based on the C++ one we now have.


 Hopefully tomorrow it will be fairly stable. In the next few hours it
will be highly unstable as I check in today's refactor.

Cheers,

--
Pete





--
Pete

Re: svn commit: r438000

[Raymond Feng]

Hi,

The rules from checkstlye are quite different than the IDE code formatter 
templates we were recommending. For example, the template for Eclipse sets 
the maximum characters per line to 150 while the checkstyle complains at 
120.


Which one should we follow? If it's the checkstyle, then we should update 
the IDE templates so that we are not confused.


Thanks,
Raymond

- Original Message - 
From: "Jim Marino" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, August 29, 2006 1:12 AM
Subject: Fwd: svn commit: r438000



Hi Raymond,

Could you please make sure you format this code: mvn -Psourcecheck?  It 
breaks Checkstyle.


Thanks,
Jim

Begin forwarded message:


From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/core/ src: 
main/java/org/apache/tuscany/core/loader/ComponentLoader.java 
test/java/org/apache/tuscany/core/loader/ComponentLoaderTestCase.java

Reply-To: tuscany-dev@ws.apache.org

Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000

URL: http://svn.apache.org/viewvc?rev=438000&view=rev
Log:
Make sure the StAX loading only ends upon 

Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java


Modified: incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/main/java/org/apache/tuscany/core/loader/ComponentLoader.java? 
rev=438000&r1=437999&r2=438000&view=diff
== 

--- incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/ 
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006

@@ -113,7 +113,8 @@
 reader.next();
 break;
 case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
 }
 }
 } catch (LoaderException e) {

Modified: incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/core/ 
src/test/java/org/apache/tuscany/core/loader/ 
ComponentLoaderTestCase.java?rev=438000&r1=437999&r2=438000&view=diff
== 

--- incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/ 
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29  01:00:16 
2006

@@ -57,7 +57,7 @@
 private ComponentLoader loader;

 public void testEmptyComponent() throws LoaderException, 
XMLStreamException {
-mockReader.expects(once()).method("getName").will 
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will 
(returnValue(COMPONENT));

 mockReader.expects(atLeastOnce()).method("getAttributeValue")
 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME), returnValue 
(null)));

@@ -71,7 +71,7 @@
 }

 public void testInitValue20() throws LoaderException, 
XMLStreamException {
-mockReader.expects(once()).method("getName").will 
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will 
(returnValue(COMPONENT));

 mockReader.expects(atLeastOnce()).method("getAttributeValue")
 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME), returnValue 
("20")));




-
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: Proposed Final Site

[David Wheeler]

Hi,

I went ahead and re-made the site around Anakia, so that it can be built and
published without php. Running build.bat will produce the files in
site-publish for you.
The zip is attached to JIRA issue here:
http://issues.apache.org/jira/browse/TUSCANY-667

-David W

On 8/25/06, David Wheeler <[EMAIL PROTECTED]> wrote:


You don't "build" the website
Simple changing the XML files changes the website. Deploying the website
is simply putting all the files in the "site" folder into the root of the
site on incubator.apache.org/tuscany
I will try and clarify that in the readme. as well as post it under the
development section.

.svg files are Scalable Vector Graphics files (http://www.w3.org/Graphics/SVG/).
Inkscape uses svg as its native file format.

-David



On 8/25/06, haleh mahbod < [EMAIL PROTECTED]> wrote:
>
> David,
>
> Thank you for your effort on this. Site prototype is much more user
> friendly
> and easier to follow.
>
> I looked through the readme. It is not clear to me how to deploy/build
> the
> site changes.
> Can you please add those steps to the read me?
>
> We used to have a link on the website that explained how to modify the
> website. It would be good to have that information under development
> box.
>
> What are the .svg files?
>
> Haleh
>
>
> On 8/25/06, David Wheeler <[EMAIL PROTECTED] > wrote:
> >
> > I think the new site is ready to go live. There are still a few pages
> tbd,
> > but all the content that is on the current site is in the new one.
> >
> > I have created a JIRA issue with the site source attached.
> > http://issues.apache.org/jira/browse/TUSCANY-667
> > The Zip also contains a readme with instuctions on how to modify the
> site
> > and craete new pages.
> >
> > -David Wheeler
> >
> >
>
>

[jira] Updated: (TUSCANY-667) New website ready to publish

[David Wheeler (JIRA)]

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

David Wheeler updated TUSCANY-667:
--

Attachment: site(8-29-06).zip

I changed to the site to use Anakia. It can no be built by running 
build.bat/build.sh and html files will be generated in the site-publish folder. 

> New website ready to publish
> 
>
> Key: TUSCANY-667
> URL: http://issues.apache.org/jira/browse/TUSCANY-667
> Project: Tuscany
>  Issue Type: New Feature
>  Components: Website
>Reporter: David Wheeler
> Attachments: site(8-29-06).zip, Tuscany Site.zip
>
>
> The new website is ready to go live. There are still a few pages TBD, but all 
> the content that is currently up is included in the new site.

-- 
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: build breaks (and how to fix them)

[Jeremy Boynes]

Sounds good to me. I will start to publish unstable builds to the  
apache snapshot repo to help stabilize things.

--
Jeremy

On Aug 25, 2006, at 5:20 PM, Jim Marino wrote:

Many of us have experienced build breaks over the past several  
weeks, particularly in the Java SCA project. I believe the root of  
the problem to be not having the correct level of modularity. I  
would like to start with a general approach on how to fix this and  
once we gain consensus, move to creating a proposal for changing  
the current build structure.


1. The source tree should be independently built from individual   
projects under /java, sca, sdo, and das. Currently it is not since  
buildtools is required. I would like to get to the point where  
people can check out individual sub projects only and build from  
there.


2. For SCA Java, as Ant proposed, the samples dealing with  
extensions would move to their appropriate extension projects.  
Samples that used multiple extensions (e.g. BigBank with Celtix and  
Axis) would stay under samples/sca


3. API, SPI, core, hostutil, host-api would be built independently  
under a subdirectory of /sca


4. Runtime host projects would be build independently under a  
subdirectory of /sca


5. Extensions would move into into a subdirectory of /sca (they  
could still be organized according to type) and be built  
individually against a particular version of the core "jars". This  
would mean that extensions are not built together and are not built  
with the core. This would shield the entire build process from  
breaking when an extension breaks (e.g. Axis and Axiom not being in  
sync). It would also mean changes to the core could be vetted and  
not impact work being done on extensions.


Thoughts?

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]

Re: svn commit: r438000

[Jim Marino]

I think it should be the checkstyle. The widest we ever went was 140  
and we had a discussion on several occasions where some wanted it  
smaller (e.g. 80), some larger, and some didn't care. 120 seems to be  
a reasonable length. Do you want to update the Eclipse one?


Jim

On Aug 29, 2006, at 5:03 PM, Raymond Feng wrote:


Hi,

The rules from checkstlye are quite different than the IDE code  
formatter templates we were recommending. For example, the template  
for Eclipse sets the maximum characters per line to 150 while the  
checkstyle complains at 120.


Which one should we follow? If it's the checkstyle, then we should  
update the IDE templates so that we are not confused.


Thanks,
Raymond

- Original Message - From: "Jim Marino"  
<[EMAIL PROTECTED]>

To: 
Sent: Tuesday, August 29, 2006 1:12 AM
Subject: Fwd: svn commit: r438000



Hi Raymond,

Could you please make sure you format this code: mvn - 
Psourcecheck?  It breaks Checkstyle.


Thanks,
Jim

Begin forwarded message:


From: [EMAIL PROTECTED]
Date: August 29, 2006 1:00:16 AM PDT
To: tuscany-commits@ws.apache.org
Subject: svn commit: r438000 - in /incubator/tuscany/java/sca/ 
core/ src: main/java/org/apache/tuscany/core/loader/ 
ComponentLoader.java test/java/org/apache/tuscany/core/loader/ 
ComponentLoaderTestCase.java

Reply-To: tuscany-dev@ws.apache.org

Author: rfeng
Date: Tue Aug 29 01:00:16 2006
New Revision: 438000

URL: http://svn.apache.org/viewvc?rev=438000&view=rev
Log:
Make sure the StAX loading only ends upon 

Modified:
incubator/tuscany/java/sca/core/src/main/java/org/apache/  
tuscany/core/loader/ComponentLoader.java
incubator/tuscany/java/sca/core/src/test/java/org/apache/  
tuscany/core/loader/ComponentLoaderTestCase.java


Modified: incubator/tuscany/java/sca/core/src/main/java/org/ 
apache/ tuscany/core/loader/ComponentLoader.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/ 
core/ src/main/java/org/apache/tuscany/core/loader/ 
ComponentLoader.java? rev=438000&r1=437999&r2=438000&view=diff
 
== 
--- incubator/tuscany/java/sca/core/src/main/java/org/apache/  
tuscany/core/loader/ComponentLoader.java (original)
+++ incubator/tuscany/java/sca/core/src/main/java/org/apache/  
tuscany/core/loader/ComponentLoader.java Tue Aug 29 01:00:16 2006

@@ -113,7 +113,8 @@
 reader.next();
 break;
 case END_ELEMENT:
-return componentDefinition;
+if(reader.getName().equals(COMPONENT))
+return componentDefinition;
 }
 }
 } catch (LoaderException e) {

Modified: incubator/tuscany/java/sca/core/src/test/java/org/ 
apache/ tuscany/core/loader/ComponentLoaderTestCase.java
URL: http://svn.apache.org/viewvc/incubator/tuscany/java/sca/ 
core/ src/test/java/org/apache/tuscany/core/loader/  
ComponentLoaderTestCase.java? 
rev=438000&r1=437999&r2=438000&view=diff
 
== 
--- incubator/tuscany/java/sca/core/src/test/java/org/apache/  
tuscany/core/loader/ComponentLoaderTestCase.java (original)
+++ incubator/tuscany/java/sca/core/src/test/java/org/apache/  
tuscany/core/loader/ComponentLoaderTestCase.java Tue Aug 29   
01:00:16 2006

@@ -57,7 +57,7 @@
 private ComponentLoader loader;

 public void testEmptyComponent() throws LoaderException,  
XMLStreamException {
-mockReader.expects(once()).method("getName").will  
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will  
(returnValue(COMPONENT));
 mockReader.expects(atLeastOnce()).method 
("getAttributeValue")

 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME),  
returnValue (null)));

@@ -71,7 +71,7 @@
 }

 public void testInitValue20() throws LoaderException,  
XMLStreamException {
-mockReader.expects(once()).method("getName").will  
(returnValue(COMPONENT));
+mockReader.expects(atLeastOnce()).method("getName").will  
(returnValue(COMPONENT));
 mockReader.expects(atLeastOnce()).method 
("getAttributeValue")

 .with(ANYTHING, ANYTHING)
 .will(onConsecutiveCalls(returnValue(NAME),  
returnValue ("20")));




 
-

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 unsubscrib

Re: Introspect WSDL to create WSDLServiceContract

[Jim Marino]

I'm in the process of getting rid of the use of Method throughout the  
code base and moving to ServiceContract. This will give us the  
ability to plug in the databinding transformers.  Since this is a  
significant change, please bear with me as I convert over - it may  
take a little while.


Jim

On Aug 29, 2006, at 2:08 PM, Jeremy Boynes wrote:


On Aug 29, 2006, at 2:01 PM, Raymond Feng wrote:


Hi,

Do we have the requirement to introspect a WSDL port type to  
create the corresponding WSDLServiceContract? If so, we'll  
probably need to add an "InterfaceWSDLIntrospector" as we do for  
java.


Yes.

Or do we assume we always perform WSDL2Java (statically with code- 
generation or dynamically with ASM during runtime) to create a  
java interface which can be introspected to get the  
JavaServiceContract?


The builders should work off the Operations defined in the  
ServiceContract (perhaps with certain optimizations if they know  
the IDL) so ultimately there should be no need to convert to  
JavaServiceContract - I think Jim is working on that (e.g. r438003).


--
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: How to invoke a web service with complex types? Java object / SDO conversion?

[Liu, Jervis]

Hi Chris, see comments in-line.

Cheers,
Jervis

> -Original Message-
> From: Chris Wall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 30, 2006 6:01 AM
> To: tuscany-dev@ws.apache.org
> Subject: Re: How to invoke a web service with complex types? 
> Java object
> / SDO conversion?
> 
> 
> Hi Raymond.
> 
> In our case, the client is privy to the domain objects - Java objects
> (interfaces/classes) - used by the web service.  For example, 
> locally the
> client uses org.client.Patient throughout the application.  
> Before invoking
> a web service the client converts org.client.Patient to
> org.service.Patient(provided by service provider), and then invokes
> the web service passing
> org.service.Patient.
> 
> Migrating this code to Tuscany we're finding that SDO handles 
> the outbound
> by converting the Patient object to a String (I think).  The 
> inbound doesn't
> convert at all, but instead sends back null.
> 
I am not sure whether or not you are talking about the Celtix binding. It looks 
like you are referring to the Celtix binding code from last week, I am afraid 
it was not complete at that stage. But the latest version should allow both 
inbound and outbound working, I have tested helloworldwsclient sample, it works 
fine. 

Please note there is a hack currently in Celtix binding 
NodeDataReader/NodeDataWriter code. I have to convert SDO object to stream 
first, then stream to XML Node. This is because Celtix 1.0 does not have a 
direct support to stax. Problem can be fixed once we move Celtix binding to be 
based on the latest CeltixFire code base. CeltixFire repository is already 
available  from apache incubator. 

As Raymond has mentioned, a pluggable databinding framework is under 
construction at the moment. Before this happens, if you are keen to use other 
databindings such as JAXB or xmlbeans, you can do so by implementing your own 
NodeDataReader/NodeDataWriter. Let me know if you need any helps.


> It would be cool if the binding layer was able to dynamically 
> convert a Java
> object to a schema type matching the package name and class 
> name in the
> WSDL.  This is the ultimate non-invasive approach.
> 
> It sounds as if the WS binding layer for both Axis2 and 
> Celtix support only
> SDO as of today.  If this is true, what are the steps to 
> communicate with a
> complex type web service?  My guess is:
> 
> 1.) Generate SDO objects from WSDL using tuscany-sdo-plugin.
> 
> 2.) Create a service component (@Service) that matches the 
> web service's
> method signatures.
> 
> 3.) In the application scdl, import the WSDL into SDO
> ().  Although, I'm not sure exactly what
> this does.
> 
> 4.) In the application scdl, configure the service component with the
> binding.ws.
> 
> 5.) Within the client application, convert local Java objects 
> to SDO object
> using the Factory created in #1.
> 
> 6.) Within the client application, locate the service via 
> Tuscany context
> and invoke web service proxy method passing in the SDO object.
> 
> How does that sound?
> 
> -Chris
> 

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

Re: SCDL extensions to define data types for parameters and return value

[Jim Marino]

On Aug 29, 2006, at 1:55 PM, Raymond Feng wrote:


Hi,

I agree with you that only one databinding will be used for the  
same interface for most cases.


I have a case that we need at least operation-level databinding.  
For SCA reference/service with JCA bindings, we need databindings  
to deal with the native EIS data format (for example, CCI record)  
at "Interaction" level which usually maps to an operation in the  
ServiceContract.
For your reference, there's EMD spec from IBM & BEA @ ftp:// 
www6.software.ibm.com/software/developer/library/j-emd/ 
EnterpriseMetadataDiscoverySpecification.pdf nad it talks about  
DataBinding for SDO<-->EIS transformations.


Can you explain these use cases further?


Thanks,
Jim


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