Hi Luciano, Thanks for taking a look. Comments inline:
Cheers,
On 07/07/06, Luciano Resende [EMAIL PROTECTED] wrote:
Hi Pete
I took sometime to look at the C++ M1 Release candidate and I have the
following feedback...
Please keep in mind that my C++ skills is not one of my biggest
Hi,
Yes, I have looked at using stdcxx, particularly in SDO code, but it applied
to SCA also.
We use stl internally, particularly lists, maps etc, and are currently Geoff
Winn is kindly converting all my antique char* arrays to std:strings. When
this is done, we would want to experiment with just
Jim,
Are you ok for me to start looking at the work manager implementation?
Once I get a better understanding around the requirements of callbacks,
I can try to give some input on that as well.
Ta
Meeraj
-Original Message-
From: Meeraj Kunnumpurath [mailto:[EMAIL PROTECTED]
Sent: 06
Here's the log from the Tuscany weekly chat from yesterday.
The main topic discussed was how to get from the sandbox fork to a single
code stream we can all develop into the M2/1.0 release. The two approaches
on the table are summarized in these two emails:
Hi Pete,
I found one issue.
I used VC6 to attempt to build SDO and I get some problems during the
copyout. I'll raise a JIRA for this.
Linking...
Creating library ..\..\..\runtime\core\Release/tuscany_sdo.lib and object
..\..\..\runtime\core\Release/tuscany_sdo.exp
copyout
1 file(s)
That looks like output from the visual studio build. Did you try the command
line?
Cheers,
On 07/07/06, Geoffrey Winn [EMAIL PROTECTED] wrote:
Hi Pete,
I found one issue.
I used VC6 to attempt to build SDO and I get some problems during the
copyout. I'll raise a JIRA for this.
Linking...
Build fails during copyout - The system cannot find the path specified.
-
Key: TUSCANY-522
URL: http://issues.apache.org/jira/browse/TUSCANY-522
Project: Tuscany
Type: Bug
Components: C++ SDO
Ok, Jeremy.
Ta
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 07 July 2006 14:33
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks
On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote:
Jim,
Are you ok for me to start looking at the work
Not yet, but I will do.
I managed to build successfully in VC6 by leaving sdo_test and Win32 Debug
as the active configuration and doing rebuild all. After that I tried to run
the tests by just pressing the F5 button and although the tests do run
successfully I had to step through a mass of
For what it's worth, I like that approach too. I'm with Pete on this, in
general I dislike IRC, although I can see there are times when it is useful.
I particularly like the idea that the subjects for the regular IRC chat
should be announced in advance as far as possible. I think that will help a
Breakpoints already set in SDO source
-
Key: TUSCANY-523
URL: http://issues.apache.org/jira/browse/TUSCANY-523
Project: Tuscany
Type: Improvement
Components: C++ SDO
Versions: Cpp-M1
Environment: Microsoft Visual C++
I too think that having a work manager implementation that minimizes
dependencies (e.g., Geronimo's)
is a useful thing to have. Wrt using a work manager in the support for
callbacks, we should
just make sure that we are ok with the overall architecture first. At his
point, it looks like the
Ignacio,
I have a couple of questions. Sorry, I may be talking rubbish without
any context.
I think for local callbacks to happen asynchronously a work manager
based approach may be appropriate. However, on other scenarios, wouldn't
the callback implementation be specific to the binding. For
On Jul 7, 2006, at 6:56 AM, Ignacio Silva-Lepe wrote:
I too think that having a work manager implementation that
minimizes dependencies (e.g., Geronimo's)
is a useful thing to have. Wrt using a work manager in the support
for callbacks, we should
just make sure that we are ok with the
On Jul 7, 2006, at 7:13 AM, Meeraj Kunnumpurath wrote:
Also, we may find other use cases for using a work manager for
deferred
executions. Do we have any view on how the runtime can use a work
manager from a managed environment when Tuscany is run in a managed
environment. I think app
On Jul 7, 2006, at 7:37 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Should this go into sca/core. Also, have you got any suggestions on
what
package this should go in?
I would suggest putting the API in o.a.t.spi.services.work and the
impl in o.a.t.core.services.work
Work for you?
--
ok
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 07 July 2006 15:46
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks
On Jul 7, 2006, at 7:37 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Should this go into sca/core. Also, have you got any
[ http://issues.apache.org/jira/browse/TUSCANY-514?page=all ]
Ed Slattery resolved TUSCANY-514:
-
Fix Version: Cpp-current
Resolution: Fixed
Tested on RC1
Various problems building with VC7
--
Key:
JSR-237 was not part of 1.4
True, I don't think it is part of JEE 5 either. Weblogic 9.1 does
provide an implementation though.
I don't think we should provide a full implementation of 237
I have an implementation that supports local work using concurrent
utilities (Doug Lea), I can port it to
ant for building scagen not run on windows
--
Key: TUSCANY-524
URL: http://issues.apache.org/jira/browse/TUSCANY-524
Project: Tuscany
Type: Bug
Reporter: Ed Slattery
Priority: Minor
The windows build script does not
[ http://issues.apache.org/jira/browse/TUSCANY-524?page=all ]
Ed Slattery updated TUSCANY-524:
Component: C++ Build
Version: Cpp-current
ant for building scagen not run on windows
--
Key:
I think the 72 hours is a minimum not an exact amount of time, the vote can
keep running until you've got the necessary number of binding +1s. Its also
not great that a large part of this will be over a weekend so you may end up
needing to wait a bit longer.
I'm far from being a C++ expert so so
yup.. .the vote will run until it stops ;-)
I'll be around on the mailing list but not IRC.
Thanks for looking at it.
Cheers,
On 07/07/06, ant elder [EMAIL PROTECTED] wrote:
I think the 72 hours is a minimum not an exact amount of time, the vote
can
keep running until you've got the
I'll be around on the mailing list but not IRC.
Me too.
Geoff.
Ive downloaded and run the sca , sdo and Calculator sample.
I used first the command line build, then visual studio 6 then visual studio
7 - all ran and produced a working sample.
This gets a +1 from me.
There are two minor issues which I would *not* consider as important enough
for a respin:
I built the SDO release from the command line using build.cmd as it says in
the INSTALL file and that worked without apparent error.
At this point I would like to run the same set of tests that I would
normally run from the Visual Studio build ie the sdo_test project, but I
can't see how to do
INSTALL of calculator doesnt say where the build.cmd is located.
Key: TUSCANY-525
URL: http://issues.apache.org/jira/browse/TUSCANY-525
Project: Tuscany
Type: Bug
Components: C++ Build
warnings in devstudio7
---
Key: TUSCANY-526
URL: http://issues.apache.org/jira/browse/TUSCANY-526
Project: Tuscany
Type: Bug
Components: C++ Build
Environment: windows
Reporter: Ed Slattery
Priority: Minor
Not really a build
Just one quick question... are we going to make the final C++ M1 Release as
a non-debug build ?
- Luciano
On 7/7/06, Edward Slattery [EMAIL PROTECTED] wrote:
Ive downloaded and run the sca , sdo and Calculator sample.
I used first the command line build, then visual studio 6 then visual
Jeremy,
Ok, having a brief look at the JCA work manager API, these are my
thoughts
1. The high-level API are very similar, a manager and optional support
for listeners for callbacks 2. There are subtle differences between the
actual semantics of work allocation. JCA work manager supports both
Pete Robbins wrote:
Hi Martin.
Using stdcxx is certainly on our list of things to investigate. There are 2
ways in which we can use a C++ standard library:
1) Internally withing our own implementation code
2) Exposed on user APIs
We currently use stl within our implementation and the use of
On Jul 7, 2006, at 9:04 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Ok, having a brief look at the JCA work manager API, these are my
thoughts
1. The high-level API are very similar, a manager and optional support
for listeners for callbacks 2. There are subtle differences between
the
actual
That sounds ok.
-Original Message-
From: Jeremy Boynes [mailto:[EMAIL PROTECTED]
Sent: 07 July 2006 17:27
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks
On Jul 7, 2006, at 9:04 AM, Meeraj Kunnumpurath wrote:
Jeremy,
Ok, having a brief look at the JCA work
Edward Slattery wrote:
Hi,
Yes, I have looked at using stdcxx, particularly in SDO code, but it
applied
to SCA also.
We use stl internally, particularly lists, maps etc, and are currently
Geoff
Winn is kindly converting all my antique char* arrays to std:strings. When
this is done, we would
Good point, you should raise a JIRA that the build.cmd doesnt run it
automatically.
The test program is runtime/core/test/Debug/sdo_test.exe, and needs to be
run from the
runtime/core/test directory:
cd runtime/core/test
Debug\sdo_test
There are currently only 108 tests running, although the
On 07/07/06, Luciano Resende [EMAIL PROTECTED] wrote:
Just one quick question... are we going to make the final C++ M1 Release
as
a non-debug build ?
I think we probably should ultimately make the bin release a non-debug
build. For this release I'm not sure. If enough folk think it's
From the source distro on linux you should be able to just run ./sdotest.sh
from the top level folder. We should write a sdotest.cmd to do the same on
win.
On 07/07/06, Edward Slattery [EMAIL PROTECTED] wrote:
Good point, you should raise a JIRA that the build.cmd doesnt run it
automatically.
More comments inline.
Jim Marino wrote:
Comments inline
On Jul 6, 2006, at 6:17 PM, Jean-Sebastien Delfino wrote:
Jeremy,
I won't comment on your attacks at the bottom of this email. I was
hoping for a more constructive technical discussion. I added my
answers and comments on the specific
Kevin,
I think a method such as Command.getGeneratedKey() would be more
appropriate. If named parameters are removed, DAS.GENERATED_KEY
would really be the only possible argument for a getParameter(String)
method. Instead of keeping this method around for this one case, we
may as well simplify
Certainly. Feel free to jump in on anything you would like. Input on
callbacks would be welcome as well.
Jim
On Jul 7, 2006, at 2:45 AM, Meeraj Kunnumpurath wrote:
Jim,
Are you ok for me to start looking at the work manager implementation?
Once I get a better understanding around the
Actually, I am proposing that we get rid of getParameter(String) and
define a special index to allow indexed access to the generated id.
Something like:
public interface Command {
public static final int GENERATED_KEY = Integer.MAX_VALUE;
and then clients could use it like this:
Kevin,
That's fine, but I would still prefer a specific method for
retrieving a generated key in this case. It seems a lot more intuitive
to me.
Brent
On 7/7/06, Kevin Williams [EMAIL PROTECTED] wrote:
Actually, I am proposing that we get rid of getParameter(String) and
define a special
Thanks Jim.
I have had a discussion with Jeremy on this as well. Hopefully I should
have something done by the weekend.
M
-Original Message-
From: Jim Marino [mailto:[EMAIL PROTECTED]
Sent: 07 July 2006 18:09
To: tuscany-dev@ws.apache.org
Subject: Re: Support for callbacks
Certainly.
The attached patch contains the runtime changes as well as changes to
BigBank to remove a workaround for this issue.
Index:
sampleapps/bigbank/account/src/main/java/bigbank/account/services/accountdb/AccountDBInit.java
===
---
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
On 07/07/06, Luciano Resende [EMAIL PROTECTED] wrote:
Just one quick question... are we going to make the final C++ M1
Release
as
a non-debug build ?
I think we probably should ultimately make the bin release a non-debug
build. For this
Splitting into three seperate patch files to help out with eclipse
project patcher weirdness. The content is the same.
On 7/7/06, Brent Daniel [EMAIL PROTECTED] wrote:
The attached patch contains the runtime changes as well as changes to
BigBank to remove a workaround for this issue.
Index:
[ http://issues.apache.org/jira/browse/TUSCANY-154?page=all ]
Kevin Williams closed TUSCANY-154:
--
Resolution: Fixed
Assign To: Brent Daniel
Verified with revision 419660
DAS should create graphs with a dynamic root data object even when
[ http://issues.apache.org/jira/browse/TUSCANY-479?page=all ]
Kevin Williams closed TUSCANY-479:
--
Resolution: Fixed
Assign To: Brent Daniel
Corrected as part of a previous patch. Verified with revision 419660
Definition of Parameter in
I've been doing some hacking on Rick's launcher and it is now capable
of booting both system and application composites.
I've tweaked the eagerinit sample so that it can now be run using the
launcher from a clean distribution. The sandbox build automatically
puts a distribution in your
Pete Robbins wrote:
On 07/07/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:I'm trying the Linux binary distribution
and
running into the following
issues:
- The INSTALL files for both the SDO and SCA distributions just say
Extract the binary tar package to
Jean-Sebastien Delfino wrote:
Pete Robbins wrote:
On 07/07/06, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote:
Jean-Sebastien Delfino wrote:I'm trying the Linux binary
distribution and
running into the following
issues:
- The INSTALL files for both the SDO and SCA distributions just say
It looks like the ws call is getting into the component and that is working
fine. The error is when we are trying to convert the dataobject returned
from the calculator sample to an axiom object before returning it over the
wire. I haven't seen this behaviour before.
Before starting the axis
52 matches
Mail list logo
