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
Hi,
Here is a list of JARs we're building:
axis2-1.0-SNAPSHOT.jar
spring-1.0-SNAPSHOT.jar
celtix-1.0-SNAPSHOT.jar
groovy-1.0-SNAPSHOT.jar
rmi-1.0-SNAPSHOT.jar
api-1.0-SNAPSHOT.jar
core-1.0-SNAPSHOT.jar
spi-1.0-SNAPSHOT.jar
wsdl-1.0-SNAPSHOT.jar
Don't we think the name of the jars are
+1
Rick also suggested this a while back, maybe we should raise a JIRA this
time so its not forgotten.
...ant
On 8/25/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Here is a list of JARs we're building:
axis2-1.0-SNAPSHOT.jar
spring-1.0-SNAPSHOT.jar
celtix-1.0-SNAPSHOT.jar
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
I agree that the names are confusing. Would you like to see more
meaningful names like
tuscany-binding-axis2-1.0-SNAPSHOT.jar
tuscany-sca-api-1.0-SNAPSHOT.jar
tuscany-sca-core-1.0-SNAPSHOT.jar
...
tuscany-idl-wsdl-1.0-SNAPSHOT.jar
etc. ?
On 8/25/06, ant elder [EMAIL PROTECTED] wrote:
Java SCA: A non-blocking asynchronous HTTP transport
Key: TUSCANY-666
URL: http://issues.apache.org/jira/browse/TUSCANY-666
Project: Tuscany
Issue Type: New Feature
Reporter:
[ http://issues.apache.org/jira/browse/TUSCANY-417?page=all ]
ant elder updated TUSCANY-417:
--
Fix Version/s: Java-Mx
(was: Java-M2)
Affects Version/s: Java-Mx
(was: Java-M2)
Interactive
[ http://issues.apache.org/jira/browse/TUSCANY-421?page=all ]
ant elder updated TUSCANY-421:
--
Fix Version/s: Java-Mx
(was: Java-M2)
Affects Version/s: Java-Mx
(was: Java-M2)
Moving to Mx for
[ http://issues.apache.org/jira/browse/TUSCANY-87?page=all ]
ant elder closed TUSCANY-87.
Resolution: Duplicate
This has been superseeded by TUSCANY-541
Support pluggable data binding in the Axis2 WS binding
[ http://issues.apache.org/jira/browse/TUSCANY-61?page=all ]
ant elder closed TUSCANY-61.
Fix Version/s: Java-M2
(was: Java-Mx)
Resolution: Fixed
Assignee: ant elder (was: Raymond Feng)
Works on the new code base
[ http://issues.apache.org/jira/browse/TUSCANY-104?page=all ]
ant elder closed TUSCANY-104.
-
Resolution: Duplicate
Superseeded by TUSCANY-541
Support efficient (de)serilization and streaming with the WS binding
[ http://issues.apache.org/jira/browse/TUSCANY-271?page=all ]
ant elder updated TUSCANY-271:
--
Fix Version/s: Java-M2
(was: Java-Mx)
Affects Version/s: Java-M2
(was: Java-Mx)
Sort out what
[ http://issues.apache.org/jira/browse/TUSCANY-118?page=all ]
ant elder closed TUSCANY-118.
-
Resolution: Fixed
Partly done and the rest will be fixed with TUSCANY-541
Adding Serializer/Deserializer for DataObject using StAX for better Axis2
AXIOM
[
http://issues.apache.org/jira/browse/TUSCANY-541?page=comments#action_12430475
]
ant elder commented on TUSCANY-541:
---
See some old JIRAs: TUSCANY-87, TUSCANY-104, TUSCANY-118
support pluggable databinding and data transformation
[ http://issues.apache.org/jira/browse/TUSCANY-372?page=all ]
ant elder closed TUSCANY-372.
-
Resolution: Fixed
Null pointer for axis2/tomcat example where the service interface/operation
takes no parameters
[ http://issues.apache.org/jira/browse/TUSCANY-76?page=all ]
ant elder updated TUSCANY-76:
-
Fix Version/s: Java-M2
(was: Java-Mx)
Affects Version/s: Java-M2
(was: Java-Mx)
Need a specifcation of
[ http://issues.apache.org/jira/browse/TUSCANY-611?page=all ]
ant elder closed TUSCANY-611.
-
Resolution: Fixed
All these patches applied now, thanks for all the patches Venkat.
I'm going to close this JIRA now and new work can go in new JIRAs
RMI Binding
I've applied all of these now and all seems fine.
Cheers,
On 23/08/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
Pete,
Thanks for that, all the ones with applied patches have been closed. That
leaves four with patches waiting to be applied
490: patch submitted but not yet applied
496: patch
[ http://issues.apache.org/jira/browse/TUSCANY-490?page=all ]
Pete Robbins resolved TUSCANY-490.
--
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
DataObjectPtr::getByte returns incorrect data
[ http://issues.apache.org/jira/browse/TUSCANY-553?page=all ]
Pete Robbins resolved TUSCANY-553.
--
Fix Version/s: Cpp-current
Resolution: Fixed
patch applied
Add a static null SDOString to the SDOString class
I brought it up a few times on the IRC, but it didn't seem anyone was
interested. Once you start working with other projects it becomes a bit of a
pain distinguish them. Especially, our axis binding looks more like it would
belong to axis and not Tuscany.
There is a concern that these names
I'd still prefer to have extensions and system referenced from a different
directory. Does the spec really mandate the file extension; I kind of preferred
scdl myself
Raymond Feng wrote:
Hi,
I understand we endeavor to support isolated classloading for system,
extension, and application.
To help out Yoko, I wrote a quick script that will properly set the svn
properties on all the files in their repository. I've attached it.
Would there be any objection to me running it on all of tuscany/trunk?
(including sdo, spec, das?)
I've noticed there are a LOT of files that don't
Sounds good, so you have my +1
...ant
On 8/25/06, Daniel Kulp [EMAIL PROTECTED] wrote:
To help out Yoko, I wrote a quick script that will properly set the svn
properties on all the files in their repository. I've attached it.
Would there be any objection to me running it on all of
The latest update, that updates a lot of the core/implementation/processors,
seems to be breaking a lot if not all of the sca samples. The way I see this is
by doing a mvn clean and mvn -e from the top, which breaks while running the
tests for the SDO impl, so then I go to sca/core and do mvn
+1 to update DAS
On 8/25/06, ant elder [EMAIL PROTECTED] wrote:
Sounds good, so you have my +1
...ant
On 8/25/06, Daniel Kulp [EMAIL PROTECTED] wrote:
To help out Yoko, I wrote a quick script that will properly set the svn
properties on all the files in their repository. I've
I plan to have DAS contents ready by early next week.
On 8/24/06, David Wheeler [EMAIL PROTECTED] wrote:
Hi everyone,
I think the site layout is probably in good final candidate form, but
there
are a few pages that need to be written that I wouldn't consider myself
qualified to create.
We
Would you like to make that available in the /etc dir where the other
scripts are ?
Thanks
- Luciano
On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote:
I think a couple of people have used this now. Here is an update ...
# Scans files - with a given extension - recursively from the current
Also, as we are planning to change our DAS logging code, we should also
consider performance enhancements on that area. Today, I see various places
where we are doing log like this:
DebugUtil.debugln(getClass(), debug, Adding table/column: + typeName +
/ + propertyName);
And I would
Yes. Good point. I'll put it out there.
Thanks,
--Kevin
Luciano Resende wrote:
Would you like to make that available in the /etc dir where the other
scripts are ?
Thanks
- Luciano
On 8/24/06, Kevin Williams [EMAIL PROTECTED] wrote:
I think a couple of people have used this now. Here
On Aug 24, 2006, at 10:50 PM, Raymond Feng wrote:
Hi,
I understand we endeavor to support isolated classloading for
system, extension, and application. But I think we should be able
to run a SCA application with the runtime and extension jars on its
classpath if the user chooses to do
OK. I'm going to go ahead and do this. It seems to look pretty good and
doesn't break any tests. The main problem seems to be the SDO section with
a lot of files without the proper eol-style property which causes some big
cleanups.
Dan
On Friday August 25 2006 9:35 am, Daniel Kulp
Hi Ignacio,
The build runs fine for me. Did you try mvn clean first? Can you
send a stacktrace if it persists?
Jim
On Aug 25, 2006, at 7:00 AM, Ignacio Silva-Lepe wrote:
The latest update, that updates a lot of the core/implementation/
processors, seems to be breaking a lot if not all of
Yes. I aggree, and this goes to our logging policy and patterns.
Luciano Resende wrote:
Also, as we are planning to change our DAS logging code, we should also
consider performance enhancements on that area. Today, I see various
places
where we are doing log like this:
I just synced SDO and am getting the following when building from /java:
junit.framework.AssertionFailedError: The expected value did not
result when calling toDay after initializing with toDay.
at junit.framework.Assert.fail(Assert.java:47)
at
Actually, I'm seeing a build failure in SDO (test failure), although it's
doing that in a clean view as well.I don't have time to investigate that
right now. Thus, I'm going to wait till monday to do this. I don't want
to make some big changes when I know there is a failure.
Dan
I'm sure the cpp tree could also benefit from this treatment. I will own up
to having Rev, Date in my subversions properties... as that is what Jeremy
told me to do (he's not around so I can blame him ;-) )
Is there a definitive list of property settings to use? This is the list
Jeremy gave me
Dan,
Thanks for doing this.
Can you also contribute the script to /java/etc?
--Kevin
Daniel Kulp wrote:
OK. I'm going to go ahead and do this. It seems to look pretty good and
doesn't break any tests. The main problem seems to be the SDO section with
a lot of files without the proper
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
On Aug 25, 2006, at 9:39 AM, Ignacio Silva-Lepe wrote:
Ok, first, after mvn clean from the top and trying mvn -e from the
top, I get:
Then I do mvn -e from sca/core and from sca/spi and that works.
Then I do mvn -e from samples/sca and I get:
Hi,
I have a simple question about the Message interface.
public interface Message {
/**
* Returns the body of the message, which will be the payload or
parameters associated with the wire
*/
Object getBody();
...
}
Is the return value always an Object[]? If not, can
On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote:
Hi,
It's a bit challenging to run a simple SCA J2SE helloworld sample.
Here's the folder structure you have to deal:
helloworld
--- bin: the launcher.jar, sca-api.jar and host-util.jar
--- boot: core.jar, spi.jar, etc
---
Ok, trying to build the sca tree I get:
Running org.apache.tuscany.binding.axis2.Axis2ServiceTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec
Running org.apache.tuscany.binding.axis2.Axis2ReferenceTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
I'm going to send out a separate mail dealing with how to solve the
issues you are seeing long term as I think we are witnessing the
results of not having the correct level of modularity in the build.
In the meantime, comments below on how to solve this.
On Aug 25, 2006, at 10:30 AM,
Please see more comments below.
Raymond
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, August 25, 2006 10:27 AM
Subject: Re: Avoiding extension and application scdl collisions
On Aug 25, 2006, at 9:32 AM, Raymond Feng wrote:
It seems changing the default SCDL location names so they are unique does not
prevent using classloaders to keep the artifacts from each isolated. Doing this
only allows the flexibility that they COULD more easily coexist in the same
classloader scope. Given we see the core as something that
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
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
[ http://issues.apache.org/jira/browse/TUSCANY-254?page=all ]
Frank Budinsky resolved TUSCANY-254.
Resolution: Fixed
Fixed in revision 431587.
Add -interfaceDataObject codegen option to generate interfaces that extend
SDO DataObject interface
Ok, yes, the recipe is getting more intricate every time, but I got the
samples to run now. Thanks.
- Original Message -
From: Jim Marino [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, August 25, 2006 1:45 PM
Subject: Re: New build break
I'm going to send out a
On Aug 25, 2006, at 10:56 AM, Raymond Feng wrote:
Please see more comments below.
Raymond
- Original Message - From: Jim Marino
[EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Friday, August 25, 2006 10:27 AM
Subject: Re: Avoiding extension and application scdl collisions
Dan,
I disabled the test that was failing. It's a new SDO test, that seems to
work in some time zones and fail in others. Sorry about that, and thanks
for doing this.
Frank.
Daniel Kulp [EMAIL PROTECTED] wrote on 08/25/2006 12:26:34 PM:
Actually, I'm seeing a build failure in SDO (test
Hello Jim,
I attempted this on a variety of time/timezone environments and thought I
had addressed all the possibilities in terms of TimeZones, daylight savings
time, northern and southern hemispheres, etc. Can you tell me what TimeZone
you are in and about what time you ran the test with
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
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
It may be that your remote client has not initialized the SDO/EMF
environment properly and I think that we need some help from the SDO
team. I have copied this to the dev list since not everyone has
registered yet for the user list.
--Kevin
Luciano Resende wrote:
Hi Scott
So, here
Hi Yang,
Comments in line ...
Yang ZHONG wrote:
You may need to serialize the generated SDO metadata. On the other
hand, I
recommend the scenario design to be reconsidered.
Thank Frank for suggesting a SDOUtil helper taking a list of Types for
DAS
to serialize all generated Types along
Hi Brian,
I ran this about 9PST and again at 4.53PST and received:
testConversionsFromDay
(org.apache.tuscany.sdo.test.DateConversionTestCase) Time elapsed:
0.01 sec FAILURE!
[ stacktrace ]
---
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
On Aug 25, 2006, at 11:35 AM, Ignacio Silva-Lepe wrote:
Ok, yes, the recipe is getting more intricate every time, but I got
the samples to run now. Thanks.
Yea unfortunately it is. I've just launched a new thread on how to
fix this by introducing more modularity. Sorry for all the issues.
60 matches
Mail list logo
