I analysed component model object in tuscany.
Here my question is: all the component model object has implemented interface
[org.apache.tuscany.sca.assembly.Visitable]. But in fact the [accept] method
are never invoked. More of it, there is a [Visitor] interface, but nobody
implements it.
My
True, with the approach, DAS can use Metadata API and treat Derby specially
(as
Derby Embedded Driver API returns FALSE, set it to TRUE)
1) If provided in Config - it will be used, no Metadata API check
2) If not provided in Config - Metadata API check - In this for Derby ALWAYS
SET TO TRUE, and
Works fine on all our linuxes including my RHEL... I've removed the
unnecessary qualifier so you should be fine now.
Cheers,
On 25/07/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Trying to build Native/C++ SDO on Linux RHEL5 gives me this error:
if /bin/sh ../../../../../libtool
You're right, binding.ws does currently require a wsdl be provided, this
is something we hope to fix in the next release -
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/SCA+Java+Next+Release+Contents
If the url do provide wsdl and the url of your web service is turning out to
be some
Hi, Raymond:
I also noticed the same problem when testing Tuscany two days ago.
I'm not familiar with WSDL4j. When I looked into the codes, my fist response is
replacing WSDLLocator, as you mentioned. While the ugly thing is that
WSDLLocator return InputSource instead of some sort of
In SCA java component implementation 1.0, most of the spec was telling the
story about interface.java interface=[interface name]. But in fact
implementation.java class=[class name]/ has done every thing.
Dose osoa mean: using interface.java the interface MAY NOT BE an interface of
the
[
https://issues.apache.org/jira/browse/TUSCANY-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515241
]
Kelvin Goodson commented on TUSCANY-1143:
-
adding the missing instrumental word to Fuhwei's comment above
CompositeActivatorImpl::createServiceWire() identifies the target operation
as follows
Operation targetOperation = interfaceContractMapper.map(
targetContract.getInterface(), operation);
This can return null in some circumstances, for example, of you try to
expose a non remoteable interface as
Hi Shaoguang,
shaoguang geng wrote:
In SCA java component implementation 1.0, most of the spec was telling the story about interface.java
interface=[interface name]. But in fact implementation.java class=[class
name]/ has done every thing.
Dose osoa mean: using interface.java the interface
[
https://issues.apache.org/jira/browse/TUSCANY-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515245
]
耿韶光 commented on TUSCANY-1312:
--
I think this error you got, is something correct in Tuscany.
In fact to implement an
Thank you for your guiding explain. You point out there is something great to
me.
Do I understand you right?
I cound use META-INF/sca-contribution.xml at client side
contribution
import namespace= location=[url of the wsdl]/
/contribution
to load the wsdl, instead of place it in
[
https://issues.apache.org/jira/browse/TUSCANY-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515246
]
Kelvin Goodson commented on TUSCANY-1399:
-
To do this we need to add another project to the SDO reactor
Hi,
I'd like the release guide if the steps we follow are a bit different
than what is normally done or if there are some variations to how we
perform some steps. But if we were just about going to rephrase all
of what has already been said somewhere else I'd prefer just about
having a pointer
Maybe we should step back a bit and get more of a common understanding of
what the sca support would look like.
From that suggestion it sounds like there'd be one synapse.xml file holding
all the config (as there is today) and within that would be the xml using
the sca namespace to define the
As an example of how much simpler things could be if we got our maven builds
set up so maven automated everything see:
http://incubator.apache.org/cxf/building.html#Building-Performingarelease
But, I still think a RM should understand whats going on so mvn shouldn't be
a substitute for having
Not quite. In my suggestion if you wanted sca then the synapse.xml
would look like:
composite xmlns=...sca namespace
/composite
But maybe I don't understand the contribution model well enough.
Paul
On 7/25/07, ant elder [EMAIL PROTECTED] wrote:
Maybe we should step back a bit and get more
Jean-Sebastien Delfino wrote:
Trying to build Native/C++ SDO on Linux RHEL5 gives me this error:
if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I. -I../../../../..
-I../../../../../runtime/core/src -I//home/delfinoj/include/libxml2
-g -O0 -MT
[
https://issues.apache.org/jira/browse/TUSCANY-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Robbins resolved TUSCANY-1425.
---
Resolution: Fixed
Fix Version/s: Cpp-Next
Compile error fixed in branch and head
The fix is in the branch as well. Sorry I did not see that Jira.
On 25/07/07, Caroline Maynard [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:
Trying to build Native/C++ SDO on Linux RHEL5 gives me this error:
if /bin/sh ../../../../../libtool --tag=CXX --mode=compile g++
[
https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amita Vadhavkar updated TUSCANY-1353:
-
Attachment: 1353.patch
patch dated Jul 25 based on
Raymond,
How does this relate to the contribution resolution mechanism described
by the SCA specifications?
Yours, Mike.
Raymond Feng wrote:
Hi,
We currently use XmlSchema to load XSDs. To resolve the import/include
directives using our schemes, we provide an implementation of
[
https://issues.apache.org/jira/browse/TUSCANY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin Goodson resolved TUSCANY-1470.
-
Resolution: Fixed
Generated SDO APIs have compilation errors when sub-type has the
Pete Robbins wrote:
Works fine on all our linuxes including my RHEL... I've removed the
unnecessary qualifier so you should be fine now.
Cheers,
Thanks Pete,
I just updated from SVN, I'm flying to Portland today as I'm going to
the OSCON conference, I'll try again from the airport :)
--
The code of method createXSDMetaData(ModelFactoryImpl) is exceeding the 65535
bytes limit
-
Key: TUSCANY-1479
URL: https://issues.apache.org/jira/browse/TUSCANY-1479
Hi,
I uploaded a patch for C++ SDO which fixes its XML serialization to
produce XML valid against schemas with elementFormDefault=true. If
someone could verify and apply it that would be great. This gets the SCA
sample CppBigBank working again.
Thanks,
Michael
Rogue Wave Software, Inc. -
SNIP
Good, I'll wait for your updates to take a further look. Please let me
know when you committ these updates.
Cool - I'll check in and update in a few days.
SNIP
I have no idea of when SDO 3.0 will be available, and we are not sure
that we will have all the necessary APIs you think is
Paul,
Great to hear from you! Some thoughts inline.
Paul Fremantle wrote:
I recently read Dan's blog entry on the SCA assembly model:
http://netzooid.com/blog/2007/07/22/sca-assembly-vs-spring-cxf/
That and some other discussions I've had made me think about maybe
offering the SCA assembly
I'm looking at it right now!
On 25/07/07, Michael Yoder [EMAIL PROTECTED] wrote:
Hi,
I uploaded a patch for C++ SDO which fixes its XML serialization to
produce XML valid against schemas with elementFormDefault=true. If
someone could verify and apply it that would be great. This gets the SCA
[
https://issues.apache.org/jira/browse/TUSCANY-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Robbins resolved TUSCANY-1478.
---
Resolution: Fixed
Fix Version/s: Cpp-Next
Patch applied to HEAD and the
[
https://issues.apache.org/jira/browse/TUSCANY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515341
]
Raymond Feng commented on TUSCANY-1477:
---
Hi,
Can you elaborate a bit more on the problem? For example,
[
https://issues.apache.org/jira/browse/TUSCANY-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515348
]
Luciano Resende commented on TUSCANY-1477:
--
One of the issues here is that there is no implementation for
Hi,
If I understand the SCA assembly spec correctly, the SCA resolution
mechanism will be used when the schemaLocation is not present. For
example, let's assume a.xsd has an import statement as follows:
import namespace=http://ns1/
We're going to use the namespace (http://ns1) as the key to
Calling EmbeddedSCADomain.activateDomain() after adding a contribution renders
services from previous contribution unusable
Key: TUSCANY-1480
[
https://issues.apache.org/jira/browse/TUSCANY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brady Johnson updated TUSCANY-1438:
---
Attachment: tuscany_patch_update5_jira1438
Uploading patch update 5 which includes:
-
[
https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-1353:
-
Affects Version/s: Java-DAS-Next
Exception attempting to insert rows using DAS
Let me come up with some initial document over the weekend, and we
could start providing feedback on top of that, also we could check if
there is going to be any value on that or not.
On 7/25/07, ant elder [EMAIL PROTECTED] wrote:
As an example of how much simpler things could be if we got our
TuscanyServlet looks for servlets using path info and not the whole path
-
Key: TUSCANY-1481
URL: https://issues.apache.org/jira/browse/TUSCANY-1481
Project: Tuscany
If I remove o.a.tuscany/sca from my local maven repository, and then
try to build SCA, I'm having all weired issues around missing
dependencies from artifacts that are supposed to get built during the
build I'm executing. I also noticed that maven is resolving some other
artifacts to its
Hi, Raymond,
We encountered the same problem when implementing SDO's XSDHelper. Where we
used EMF's xsd tool package for resolve xsd. Wherein we just implemented our
own XSDSchemaLocator and added it to the resource's adapters, then we can do
everything in locating the import/include xsd.
I ran into problems where the plugin requests for one version of the
artifact but gets back a different version of the artifact. Something
like...
Searching for commonj/sdo- api-r2.1/1.0-incubating-SNAPSHOT/jar at
http://people.apache.org/repo/m2-incubating-repository
Downloading
This might be something related to new versions of some maven plugins
as I was able to find an old version of the repository, and I was able
to build from that ok. So, maybe it's not a good idea to clean your
repo or use a mvn -U right now.
On 7/25/07, Luciano Resende [EMAIL PROTECTED] wrote:
I think the problem is that when you set many=true then the attribute
becomes a list rather than a bare type (otherwise there is no way to add
multiple attributes). You need to do:
Listint custNum = new ArrayList();
custNum.add(1000);
createdDO.setList(custNum, custNum);
I didn't see the
Hi,
This email thread has stopped, but I'll revive it...comments here.
WRT the tables on the wiki, everything looks good except:
-Table 2, row 1, I think the binding should be binding.sca. I don't think
the spec is clear on this and thus there will be disagreement.
-Table 2, row2, I think there
[
https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende updated TUSCANY-1353:
-
Fix Version/s: Java-DAS-Next
Patch Info: [Patch Available]
Exception
Please review and vote to release the 1.0-incubating distribution of Tuscany
SDO for Java
The release candidate RC3 for Tuscany Java SDO archive distribution files
are posted at [1]
The release audit tool (rat) files and associated exceptions are posted at
[1] also
The maven repository artifacts
[
https://issues.apache.org/jira/browse/TUSCANY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luciano Resende resolved TUSCANY-1353.
--
Resolution: Fixed
Patch applied under revision #559580. Thanks Amita.
Exception
CompositeProcessor does not write out Property objects completely
-
Key: TUSCANY-1482
URL: https://issues.apache.org/jira/browse/TUSCANY-1482
Project: Tuscany
Issue Type: Bug
Hi,
For those who are interested in the JMS binding, I just checked in a set of
interfaces for the model defined by the SCA JMS Binding Spec 1.0.
Feedback and help are appreciated.
Thanks,
Raymond
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday,
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
Works fine on all our linuxes including my RHEL... I've removed the
unnecessary qualifier so you should be fine now.
Cheers,
Thanks Pete,
I just updated from SVN, I'm flying to Portland today as I'm going to
the OSCON conference, I'll try
Hi All,
Tuscany SDO version: Tuscany SDO 1.0 beta1.
I'm trying to dynamically create and use types without the use of an XSD
file. What i want to do is something a little different to what is described
in the samples provided. I want to have elements within each nested type. i
also want to to
Hi All,
Tuscany SDO version: Tuscany SDO 1.0 beta1.
I'm trying to dynamically create and use types without the use of an XSD
file. What i want to do is something a little different to what is described
in the samples provided. I want to have elements within each nested type. i
also want to to
51 matches
Mail list logo
