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:
interface.wsdl ...
...
tuscany:databinding
xmlns:tuscany=http://tuscany.apache.org/xmlns/1.0-SNAPSHOT; dataType=sdo
!-- default to sdo for the portType --
operation name=getCreditReport dataType=sdo !-- default to
sdo for the operation --
!-- more fine control --
input
part index=0
dataType name=sdo
xmlType={http://customer}Customer/
/part
/input
.
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: tuscany-dev@ws.apache.org
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 and show what is the minimum necessary to get it
working with the
new data binding framework?
...ant
On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
I don't see much difference to define DataTypes for WSDL
portTypes than
java
interfaces.
If we look at the WSDL structure, we can define default
DataType for a
portType, an operation or a part.
portType
operation
input: message
part
output: message
part
fault: message
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]
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=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
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=438000r1=437999r2=438000view=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=438000r1=437999r2=438000view=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
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
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
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
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 wsdl:data 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
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: snip/ 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
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
[ 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
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
[ 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)
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 to Tomcat and will probably instead use the standalone version. This is for a number of reasons: 1. The J2EE deployment model restricts some of the most
Re: [C++] Requirements for a pluggable C++ Tuscany implementation
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
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
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 context-param param-namesystemScdlPath/param-name param-value/META-INF/sca/jsonrpc.system.scdl/param-value /context-param 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]
[jira] Updated: (TUSCANY-605) ImportSDOLoader ignoring schemaLocation parameter
[ 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)
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
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
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]
Re: Fwd: PHP support on incubator.apache.org
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
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
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
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
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: PHP support on incubator.apache.org
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 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
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
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 map.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
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: tuscany-dev@ws.apache.org 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 wsdl:data 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
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); }
[jira] Created: (TUSCANY-673) support scdlLocation attribute on implementation.composite
support scdlLocation attribute on implementation.composite 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 component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... 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
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
[ 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
[ 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=revrevision=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
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 implementation.composite
[ http://issues.apache.org/jira/browse/TUSCANY-673?page=all ] Ignacio Silva-Lepe updated TUSCANY-673: --- Attachment: ImplementationCompositeLoader.patch support scdlLocation attribute on implementation.composite 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 component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... 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 implementation.composite
[ http://issues.apache.org/jira/browse/TUSCANY-673?page=all ] Ignacio Silva-Lepe updated TUSCANY-673: --- Attachment: ImplementationCompositeLoaderAndTest.patch support scdlLocation attribute on implementation.composite 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 component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... 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 implementation.composite
[ http://issues.apache.org/jira/browse/TUSCANY-673?page=all ] Jeremy Boynes closed TUSCANY-673. - Resolution: Fixed Patch applied - thanks support scdlLocation attribute on implementation.composite 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 component name=Foo implementation.composite name=Bar scdlLocation=bar.scdl/ ... 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/
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=438171view=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=438171r1=438170r2=438171view=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 lt;implementation.compositegt; element.
@@ -41,7 +42,7 @@
*/
public class ImplementationCompositeLoader extends
LoaderExtensionCompositeImplementation {
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=438171r1=438170r2=438171view=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;
+
[jira] Updated: (TUSCANY-674) DAS: Modify test framework to facilitate support for new vendors
[ 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]
Build failure
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
IIRC plexus-archiver is hosted at codehaus so you need to add pluginRepository idcodehaus-snapshot/id nameCodehaus Snapshot Repository/name urlhttp://snapshots.repository.codehaus.org/url snapshots enabledtrue/enabled /snapshots /pluginRepository to the pluginRepositories 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]
Introspect WSDL to create WSDLServiceContract
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?
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 (import.sdo.../)? Does it register schema types from a WSDL with SDO? How are the types used later? Thanks. -Chris
Re: Introspect WSDL to create WSDLServiceContract
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
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
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 pluginRepository idcodehaus-snapshot/id nameCodehaus Snapshot Repository/name urlhttp://snapshots.repository.codehaus.org/url snapshots enabledtrue/enabled /snapshots /pluginRepositoryto the pluginRepositories 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-SNAPSHOTTry 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/filePath to dependency:1) org.apache.maven.plugins:maven-jar-plugin:maven-plugin:2.1-20060826.1 62339-62) 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?
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: tuscany-dev@ws.apache.org 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 (import.sdo.../)? 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
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 Licensehttp://www.apache.org/licenses/LICENSE-2.0_. 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 Licensehttp://www.apache.org/licenses/LICENSE-2.0_. 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...more comments inline. Jim On Aug 16, 2006, at 6:34 PM, haleh mahbod wrote: Jim, Thanks for the comments. I took a look at the links and your
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. 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 (import.sdolocation=.../). 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)
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. xs:schema attributeFormDefault=unqualified elementFormDefault=qualified targetNamespace=java:com.bea.proto.webservice xmlns:xs= http://www.w3.org/2001/XMLSchema; xs:complexType name=Patient xs:sequence xs:element minOccurs=1 name=Id nillable=true type=xs:int/ xs:element minOccurs=1 name=Dob nillable=true type=xs:dateTime/ xs:element minOccurs=1 name=FirstName nillable=true type=xs:string/ xs:element minOccurs=1 name=Gender nillable=true type=xs:string/ xs:element minOccurs=1 name=LastName nillable=true type=xs:string/ xs:element minOccurs=1 name=MiddleName nillable=true type=xs:string/ xs:element minOccurs=1 name=Phone nillable=true type=xs:string/ xs:element minOccurs=1 name=Ssn nillable=true type=xs:string/ /xs:sequence /xs:complexType /xs:schema -- 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: r438000
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: tuscany-dev@ws.apache.org
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=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
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=438000r1=437999r2=438000view=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=438000r1=437999r2=438000view=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
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
[ 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)
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
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: tuscany-dev@ws.apache.org
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=438000view=rev
Log:
Make sure the StAX loading only ends upon /component
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=438000r1=437999r2=438000view=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=438000r1=437999r2=438000view=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
Re: Introspect WSDL to create WSDLServiceContract
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: SCDL extensions to define data types for parameters and return value
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]
